Wie bekomme ich NICHT so viele Apache CLOSE_WAIT-Verbindungen?

netstat zeigt an, dass 153 Verbindungen im Status CLOSE_WAIT sind. Die Verbindungen werden nie geschlossen. Überstunden Der Server ist also mit diesen Verbindungen gefüllt, die den RAM füllen, und jetzt werden die Websites nicht geladen.

netstat zeigt viele wie die folgenden:

tcp      160      0 my_server_name:http         my_server_name:51584        CLOSE_WAIT
tcp      160      0 my_server_name:http         my_server_name:51586        CLOSE_WAIT
tcp        0      0 my_server_name:http         my_server_name:50827        CLOSE_WAIT
tcp        0      0 my_server_name:http         my_server_name:50830        CLOSE_WAIT
tcp      312      0 my_server_ip.static.:http rate-limited-proxy-72:61249 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:58663 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:34655 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:56681 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:40829 CLOSE_WAIT
tcp      576      0 my_server_ip.static.:http b3090792.crawl.yahoo.:38278 CLOSE_WAIT
tcp       47      0 my_server_ip.static.:http 203.200.5.143.ill-bgl:49379 CLOSE_WAIT

Wenn ich mir das appache error_log ansehe, gibt es vor der CLOSE_WAIT-Situation Zeilen wie die folgenden

[warn] child process 15670 still did not exit, sending a SIGTERM
[error] child process 15670 still did not exit, sending a SIGKILL
[notice] child pid 3511 exit signal Segmentation fault (11)

Mein Setup Apache 2.2.3 RAM 1024 MB (Burst 2048 MB) CentOS Release 5.3 (Final) mit 2 WPMU 2.9.2-Installationen

Hintergrund

Socket wechselt in den Status CLOSE_WAIT, wenn das Remote-Ende die Verbindung beendet und ein Paket mit gesetztem FIN-Flag sendet. In diesem Status wartet es dann auf die lokale Anwendung für close()den Socket, sendet dann seine eigene FIN an den Client und versetzt den Socket in den Status LAST_ACK. Siehe auch das TCP-Statusübergangsdiagramm und RFC 793 .

Beachten Sie auch, dass CLOSE_WAIT nichts mit dem berüchtigten TIME_WAIT zu tun hat, da ersteres im passiven Schließzweig auftritt (entferntes Ende wird zuerst geschlossen), während letzteres im aktiven Schließzweig (lokales Ende schließt zuerst).

Problembeschreibung

Normalerweise wechseln Verbindungen ziemlich schnell von CLOSE_WAIT zu LAST_ASK. Wenn sich die Remote-Adresse und der Port ständig ändern, kann eine angemessene Anzahl von Verbindungen im Status CLOSE_WAIT einfach die Folge einer sehr großen Anzahl von Verbindungen sein, die geöffnet, verwendet und geschlossen werden. Die Systemleistung sollte geprüft werden, dies ist jedoch an und für sich kein Problem.

Wenn sich die Remote-Adresse und der Port langsam ändern, bedeutet dies, dass die Anwendungsprozesse auf die CPU warten müssen. In diesem Fall bestätigen Durchschnittswerte mit hoher Last dies.

Wenn andererseits die Remoteadresse und der Port konstant bleiben und die Anzahl der Verbindungen im Status CLOSE_WAIT weiter zunimmt, weist dies höchstwahrscheinlich auf ein Problem mit der Anwendung hin. Dies ist ein Sonderfall des Ressourcenleckage-Fehlers: Die Anwendung leckt offene Sockets, anstatt sie rechtzeitig zu schließen. Dies verbraucht Kernelspeicher und führt schließlich zum Fehlschlagen der Anwendung, sobald die maximale Anzahl geöffneter Dateideskriptoren erreicht ist.

Beachten Sie jedoch, dass das Tempo der Leckage langsam sein kann. Es ist häufig der Fall, dass solche Fehler auf ein Versagen zurückzuführen sind, eine Ausnahme mitten in einer Anforderung zu behandeln, wodurch der Ausführungsfluss in einem Arbeitsthread unterbrochen wird, wodurch möglicherweise eine Bereinigung verhindert wird (einschließlich des Schließens des Sockets). Die störende Ausnahme kann selten auftreten.

Vorübergehende Lösung

Eine vorübergehende Lösung des Problems besteht darin, die Grenzwerte für offene Dateideskriptoren zu erhöhen und die Anwendung regelmäßig neu zu starten, wenn (vorzugsweise vorher) das Problem die Leistung beeinträchtigt. Beachten Sie, dass dies versehentlich Auswirkungen auf aktuell geöffnete Verbindungen haben kann. Das Vorhandensein redundanter Server und der Lastenausgleich können dazu beitragen, das Problem vor den Benutzern zu verbergen.

Permanente Lösung

Eine dauerhafte Lösung des Problems besteht darin, die Version der Anwendung ohne den Fehler bereitzustellen. Das Ausmaß, in dem die temporäre Lösung den Benutzern und dem Unternehmen schadet, die Bereitschaft der gepatchten Version und der Status der letzten Arbeitsversion helfen bei der Entscheidung, ob ein Rollback auf die letzte Arbeitsversion der Anwendung durchgeführt oder auf die Korrektur gewartet werden soll.