Ich habe Apache als Reverse-Proxy für einen Java-Anwendungsserver (GlassFish) eingerichtet und mir ist aufgefallen, dass selbst auf einem inaktiven Entwicklungssystem etwa 100 Verbindungen im Status CLOSE_WAIT vorhanden sind:
sudo netstat -n -e -p -a -t | grep httpd | grep CLOSE_WAIT | wc -l
Ich verwende die folgenden HTTP-Proxy-Einstellungen:
ProxyPass /myapp http://localhost:8080/myapp ttl=20 max=1 smax=0
ProxyPassReverse /myapp http://localhost:8080/myapp
Warum bleiben all diese Verbindungen hängen? Ich habe „ttl=20 max=1 smax=0“ eingestellt, also ging ich davon aus, dass alle Verbindungen auf einem inaktiven System bereinigt würden. Trägt der Anwendungsserver nicht seinen Teil dazu bei, die Verbindungen zu bereinigen?
Antwort1
Das ist einbekanntes Problem mit mod_proxy, seit 2011.
Die TTL muss kürzer sein als das Keepalive der Anwendung, damit Apache immer zuerst ein FIN sendet.
Eine weitere Schwierigkeit besteht darin, dass nicht definiert ist, an welchem Punkt die Verbindung tatsächlich geschlossen wird.
ttl - Lebensdauer für inaktive Verbindungen und zugehörige Verbindungspooleinträge in Sekunden. Sobald dieses Limit erreicht ist, wird eine Verbindung nicht mehr verwendet; sie wird geschlossen beiirgendwann später.
Antwort2
Ich bin auf ein ähnliches Problem gestoßen und suche nach einer Begründung in Bezug auf Apache. Ich vermute, dass es sich um Apaches Prefork handelt.
Als Lösung habe ich Nginx verwendet, das das CLOSE_WAIT-Problem gelöst hat. Die Anzahl der TIME_WAIT (ca. 20.000) zeigt jedoch, dass mit der Art und Weise, wie die Java-Anwendung(en) Verbindungen handhaben, etwas nicht stimmt. Mit Nginx funktionieren Server und Anwendung viel besser.
Ich hoffe, dass jemand diese Antwort mit technischen Details verbessern kann.
Antwort3
Diese CLOSE_WAIT-Verbindungen sind tot, der Server hält sie nur im TCP-Stack, falls weitere Pakete sie erreichen. In der „guten alten Zeit“ gingen Solaris-Servern die Dateideskriptoren aus, wenn dieser zu groß war, und das System stürzte ab. Wir mussten die Anzahl der insgesamt im Kernel zulässigen Dateideskriptoren erhöhen und das Bereinigungsintervall der CLOSE_WAIT-Verbindungen verkürzen.
Heutzutage ist die Standardanzahl der Dateideskriptoren normalerweise groß genug, um dies zu ignorieren. Die Bereinigungskonfiguration kann jedoch reduziert werden, sodass die Anzahl der CLOSE_WAIT-Verbindungen reduziert wird.
Es liegt in der Natur dieser Systeme (Glassfish, Tomcat, JBoss, ...), eine „große“ Anzahl von Verbindungen zu verwenden und diese nicht wiederzuverwenden. In den meisten Fällen können Sie dies getrost ignorieren.