☰

Apache Reverse Proxy Java Application Server CLOSE_WAIT соединения

tag-icon • tag-icon apache-2.2 mod-proxy glassfish
Apache Reverse Proxy Java Application Server CLOSE_WAIT соединения

Я настроил 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", поэтому я решил, что все соединения будут очищены в неактивной системе. Сервер приложений не выполняет свою часть работы по очистке соединений?

решение1

Этоизвестная проблема с mod_proxy, с 2011 года.

Значение ttl должно быть короче значения keepalive приложения, чтобы Apache всегда первым отправлял FIN.

Еще одна сложность заключается в том, что не определено, в какой момент соединение будет фактически закрыто.

ttl - Время жизни неактивных соединений и связанных с ними записей пула соединений в секундах. После достижения этого предела соединение больше не будет использоваться; оно будет закрыто внекоторое время спустя.

решение2

Я столкнулся с похожей проблемой и ищу обоснование в отношении Apache. Я подозреваю, что Apache prefork.

Что касается решения, я использовал Nginx, который решил проблему CLOSE_WAIT. Однако число TIME_WAIT (примерно 20 000) показывает, что что-то не так с тем, как Java-приложения обрабатывают соединения. С Nginx сервер и приложение работают намного лучше.

Надеюсь, кто-нибудь сможет улучшить этот ответ, добавив в него техническую глубину.

решение3

Эти соединения CLOSE_WAIT мертвы, просто сервер хранит их в стеке tcp на случай, если к ним попадут новые пакеты. В "старые добрые времена" серверы Solaris исчерпывали файловые дескрипторы, если они были слишком большими, и система выходила из строя. Нам пришлось увеличить общее количество файловых дескрипторов, разрешенных в ядре, и уменьшить интервал очистки соединений CLOSE_WAIT.

В наши дни число дескрипторов файлов по умолчанию обычно достаточно велико, чтобы игнорировать это. Но конфигурацию очистки можно уменьшить, поэтому число соединений CLOSE_WAIT уменьшится.

По своей природе они (Glassfish, Tomcat, JBoss, ...) используют "большое" количество соединений и не используют их повторно. В большинстве случаев вы можете спокойно игнорировать.

Связанный контент