Реверс Apache проксирует сервер JAVA-приложения соединения 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", таким образом, я полагал, что все соединения будут очищены в неактивной системе. Разве сервер приложений не вносит свой вклад к очистке соединения?
Я столкнулся с подобной проблемой и ищу аргументы в отношении Apache. Подозреваю, что это предварительный форк Apache.
Что касается решения, я использовал Nginx, который решил проблему с CLOSE_WAIT. Однако число TIME_WAIT (около 20 000) показывает, что что-то не так с тем, как приложение (я) Java обрабатывает соединения. С сервером Nginx и приложением работает намного лучше.
Я надеюсь, что кто-нибудь сможет улучшить этот ответ, добавив техническую глубину.
Эти соединения CLOSE_WAIT мертвы, это просто сервер хранит их в стеке tcp на случай, если к ним попадут другие пакеты. В «старые добрые времена» на серверах Solaris заканчивались файловые дескрипторы, если они были слишком большими, и система вываливалась из строя. Нам пришлось увеличить общее количество файловых дескрипторов, разрешенных в ядре, и уменьшить интервал очистки соединений CLOSE_WAIT.
В наши дни количество файловых дескрипторов по умолчанию обычно достаточно велико, чтобы это игнорировать. Но конфигурация очистки может быть уменьшена, поэтому количество подключений CLOSE_WAIT будет уменьшено.
По самой своей природе (Glassfish, Tomcat, JBoss, ...) использовать «большое» количество подключений и не используйте их повторно. В большинстве случаев вы можете спокойно игнорировать.
Это известная проблема с mod_proxy с 2011 года.
ttl должен быть короче, чем keepalive приложения, так что apache всегда первым отправляет FIN.
Другая трудность заключается в том, что не определено, в какой момент соединение будет фактически закрыто.
ttl - Время жизни для неактивных соединений и связанных записей пула соединений, в секундах. После достижения этого предела соединение больше не будет использоваться; он будет закрыт в несколько позже .