У меня есть настройка Apache в качестве обратного прокси для сервера приложений Java (GlassFish), и я заметил, что около 100 подключений в состоянии CLOSE_WAIT даже в простаивающей системе разработки:
sudo netstat -n -e -p -a -t | grep httpd | grep CLOSE_WAIT | wc -l
Я использую следующие настройки прокси-сервера HTTP:
ProxyPass /myapp http://localhost:8080/myapp ttl=20 max=1 smax=0
ProxyPassReverse /myapp http://localhost:8080/myapp
Почему все эти связи торчат? Я установил "ttl = 20 max = 1 smax = 0", поэтому я решил, что все соединения будут очищены в неактивной системе. Сервер приложений не выполняет свою часть работы по очистке соединений?
Это известная проблема с mod_proxy, с 2011 года.
Ttl должен быть короче, чем keepalive приложения, чтобы apache всегда первым отправлял FIN.
Другая трудность заключается в том, что не определено, в какой момент соединение будет закрыто.
ttl - время жизни для неактивных соединений и связанных записей пула соединений в секундах. При достижении этого предела соединение больше не будет использоваться; он будет закрыт в немного позже.
Эти соединения CLOSE_WAIT мертвы, это просто сервер хранит их в стеке tcp на случай, если к ним попадут другие пакеты. В «старые добрые времена» на серверах Solaris заканчивались файловые дескрипторы, если они были слишком большими, и система вываливалась из строя. Нам пришлось увеличить общее количество файловых дескрипторов, разрешенных в ядре, и уменьшить интервал очистки соединений CLOSE_WAIT.
В наши дни количество файловых дескрипторов по умолчанию обычно достаточно велико, чтобы это игнорировать. Но конфигурацию очистки можно уменьшить, так что количество подключений CLOSE_WAIT будет уменьшено.
По самой своей природе (Glassfish, Tomcat, JBoss, ...) использовать «большое» количество подключений и не использовать их повторно. В большинстве случаев вы можете спокойно игнорировать.
Я столкнулся с подобной проблемой, и я ищу аргументы в отношении Apache. Подозреваю, что это предварительная вилка Apache.
Что касается решения, я использовал Nginx, который решил проблему CLOSE_WAIT. Однако число TIME_WAIT (около 20 000) показывает, что что-то не так с тем, как приложение (я) Java обрабатывает соединения. С сервером Nginx и приложением работает намного лучше.
Я надеюсь, что кто-нибудь сможет улучшить этот ответ с технической глубиной.