Tonnenweise TCP-Verbindungen im Status TIME_WAIT unter Windows 2008 - ausgeführt auf Amazon AWS

Betriebssystem: Windows Server 2008, SP2 (läuft unter EC2 Amazon).

Wenn Sie eine Webanwendung mit Apache httpd & tomcat server 6.02 und einem Webserver ausführen, gelten Keep-Alive-Einstellungen.

Es gibt ungefähr 69.250 (http Port 80) + 15000 (außer Port 80) TCP-Verbindungen im TIME_WAIT-Status (verwendet von netstat & tcpview). Diese Verbindungen scheinen auch nach dem Stoppen des Webservers nicht geschlossen zu werden (24 Stunden gewartet)

Leistungsindikatoren:

• Aktive TCPv4-Verbindungen: 145 KB
• Passive TCPv4-Verbindungen: 475 KB
• TCPv4-Fehlerverbindungen: 16 KB
• Zurücksetzen der TCPv4-Verbindungen: 23 KB

HKEY_LOCAL_MACHINE\System \CurrentControlSet\Services\Tcpip\Parameters hat keinen TcpTimedWaitDelay-Schlüssel, daher sollte der Wert der Standardwert sein (2 * MSL, 4 Minuten)

Auch wenn Tausende von Verbindungsanfragen gleichzeitig eingehen, warum kann das Windows-Betriebssystem sie letztendlich nicht bereinigen?
Was könnten die Gründe für diese Situation sein?
Gibt es eine Möglichkeit, alle diese TIME_WAIT-Verbindungen zu schließen, ohne das Windows-Betriebssystem neu zu starten?

Nach ein paar Tagen nimmt die App keine neuen Verbindungen mehr auf.

Wir haben uns auch mit diesem Problem befasst. Es sieht so aus, als hätte Amazon die Ursache gefunden und behoben. Hier sind die Informationen, die sie mir gegeben haben.

Hallo, ich füge unten eine Erklärung ein, was dieses Problem verursacht hat. Die gute Nachricht ist, dass dies vor kurzem von unserem Engineering-Team behoben wurde. Um dieses Problem zu beheben, müssen Sie lediglich die Windows Server 2008-Instanzen, bei denen dieses Problem auftritt, STOPPEN / STARTEN. Auch hier spreche ich nicht von REBOOT, was anders ist. STOP / START bewirkt, dass die Instanz auf einen anderen (fehlerfreien) Host verschoben wird. Wenn diese Instanzen erneut gestartet werden, werden sie auf Hosts ausgeführt, auf denen der Fix installiert ist, sodass sie dieses Problem nicht erneut haben. Im Folgenden finden Sie die technische Erklärung zu diesem Problem. Nach einer eingehenden Untersuchung haben wir festgestellt, dass bei der Ausführung von Windows 2008 x64 auf den meisten verfügbaren Instanztypen Es wurde ein Problem festgestellt, das dazu führen kann, dass TCP-Verbindungen übermäßig lange in TIME_WAIT / CLOSE_WAIT verbleiben (in einigen Fällen unbegrenzt in diesem Zustand). In diesen Zuständen bleiben die jeweiligen Socket-Paare unbrauchbar und führen bei ausreichender Akkumulation zu einer Erschöpfung der Ports für die betreffenden Ports. In diesem Fall besteht die einzige Lösung zum Löschen der betreffenden Socket-Paare darin, die betreffende Instanz neu zu starten. Als Ursache haben wir die Werte ermittelt, die von einer Timer-Funktion in der Windows 2008-Kernel-API erzeugt wurden, die auf vielen unserer 64-Bit-Plattformen gelegentlich einen Wert abruft, der in der Zukunft extrem weit fortgeschritten ist. Dies wirkt sich auf den TCP-Stack aus, da die Zeitstempel auf den TCP-Socket-Paaren in Zukunft erheblich gestempelt werden. Laut Microsoft gibt es einen gespeicherten kumulativen Leistungsindikator, der nur aktualisiert wird, wenn der durch diesen API-Aufruf erzeugte Wert größer als der kumulative Wert ist. Das ultimative Ergebnis ist, dass Sockets, die nach diesem Zeitpunkt erstellt wurden, in Zukunft alle zu weit gestempelt werden, bis diese zukünftige Zeit erreicht ist. In einigen Fällen haben wir diesen Wert mehrere hundert Tage in der Zukunft gesehen, so dass die Sockelpaare für immer festzustecken scheinen.

Ryans Antwort ist ein guter allgemeiner Rat, außer dass er nicht für den Zustand gilt, den Ravi in ​​EC2 hat. Auch wir haben dieses Problem gesehen und aus irgendeinem Grund ignoriert Windows das TcpTimedWaitDelay vollständig und gibt den Socket niemals aus seinem TIMED_WAIT-Status frei.

Warten hilft nicht ... Neustarten der App hilft nicht ... Die einzige Lösung, die wir gefunden haben, ist ein Neustart des Betriebssystems. Echt hässlich.

Ich habe diesen Thread völlig zufällig gefunden, als ich nach einem separaten Problem gesucht habe, aber dies ist ein wenig aufgegriffenes, aber bekanntes Problem mit Windows unter EC2. Wir verwenden Premium - Support haben, und sprachen darüber mit ihnen in einer nicht-öffentlichen Sitzung über diesen Kanal, aber dies ist ein verwandtes Problem , das wir haben in den öffentlichen Foren zu diskutieren .

Wie andere bereits erwähnt haben, müssen Sie Windows Server ab Werk optimieren. Auf die gleiche Weise, wie StopWatch im obigen Thread nicht funktioniert, verwendet der TCP / IP-Stapel den QueryPerformanceCounterAufruf jedoch auch, um genau zu bestimmen, wann der Zeitraum TCP_TIME_WAIT dauern soll. Das Problem ist, dass sie auf EC2 auf ein Problem gestoßen sind und es kennen, bei dem QueryPerformanceCounteralles schief geht und das möglicherweise zu Zeiten weit zurückkehrt, die weit in die Zukunft reichen. Es ist nicht so, dass Ihr TIME_WAIT-Status ignoriert wird, sondern dass die Ablaufzeit von TIME_WAIT möglicherweise Jahre in der Zukunft liegt. Wenn Sie mit einer httpd-Einstellung arbeiten, können Sie sehen, wie schnell Sie diese Zombie-Sockets ansammeln, sobald der Status festgestellt wird (wir sehen im Allgemeinen, dass dies ein diskretes Ereignis ist, nicht, dass Sie langsam Zombies ansammeln).

Wir führen im Hintergrund einen Dienst aus, der die Anzahl der Sockets im Status TIME_WAIT abfragt. Sobald dieser Wert einen bestimmten Schwellenwert überschreitet, werden Maßnahmen ergriffen (der Server wird neu gestartet). Irgendwie hat in den letzten 45 Sekunden jemand darauf hingewiesen, dass Sie den Server anhalten / starten können, um das Problem zu beheben. Ich schlage vor, Sie koppeln diese beiden Ansätze.

Die Standardeinstellungen für den TCP-Stack in Windows sind gelinde gesagt für Systeme, die einen HTTP-Server hosten, nicht optimal.

Um das Beste aus Ihrem Windows-Computer herauszuholen, wenn Sie ihn als HTTP-Server verwenden, gibt es einige Parameter, die Sie normalerweise anpassen würden, z

Ich hatte mir vor ein paar Jahren eine Notiz darüber geschrieben , für den Fall, dass ich zuerst ein paar schnelle Standardeinstellungen brauche. Fühlen Sie sich frei, die Parameter zu verstehen und sie dann zu optimieren.

Unabhängig von AWS ist dieses Problem aufgetreten. Dies scheint auf den folgenden KB-Artikel zurückzuführen zu sein:

http://support.microsoft.com/kb/2553549/en-us

Grundsätzlich tritt es in Kraft, wenn ein System länger als 497 Tage in Betrieb ist und der Hotfix nicht angewendet wurde. Ein Neustart hat das Problem natürlich behoben - vielleicht wissen wir erst in den nächsten 16 Monaten, ob der Hotfix funktioniert hat, aber dies kann jedem helfen, der Server mit langer Verfügbarkeit zur Verfügung hat.

Ich habe mit Windows Server 2008 R2 x64 mit SP1 auf einer Reihe von Boxen fast dasselbe erlebt, hauptsächlich mit CLOSE_WAIT (was sich etwas von TIME_WAIT unterscheidet). Ich bin auf diese Antwort gestoßen , die sich auf eine KB bei Microsoft und einen Hotfix bezog, wenn die Server hinter einem Load Balancer liefen (welcher meiner ist). Nach der Installation des Hotfixes und dem Neustart wurden alle CLOSE_WAIT-Probleme behoben.