Mnóstwo połączeń TCP w stanie TIME_WAIT w systemie Windows 2008 - działa na Amazon AWS

System operacyjny: Windows Server 2008, SP2 (działający na EC2 Amazon).

Uruchamianie aplikacji internetowej przy użyciu serwera Apache httpd i tomcat server 6.02 oraz serwera WWW ma ustawienia podtrzymania aktywności.

Istnieje około 69 250 (HTTP port 80) + 15000 (innych niż port 80) połączeń TCP w stanie TIME_WAIT (używane netstat i tcpview). Połączenia te wydają się nie zamykać nawet po zatrzymaniu serwera WWW (oczekiwane 24 godziny)

Liczniki monitorów wydajności:

• Aktywne połączenia TCPv4: 145 KB
• Połączenia pasywne TCPv4: 475 K.
• Połączenia awaryjne TCPv4: 16 KB
• Resetuj połączenia TCPv4: 23 tys

HKEY_LOCAL_MACHINE\System \CurrentControlSet\Services\Tcpip\Parameters nie ma klucza TcpTimedWaitDelay, więc wartość powinna być wartością domyślną (2 * MSL, 4 minuty)

Nawet jeśli jednocześnie przychodzą tysiące żądań połączenia, dlaczego system operacyjny Windows nie jest w stanie ich ostatecznie wyczyścić?
Jakie mogą być przyczyny tej sytuacji?
Czy istnieje sposób na wymuszenie zamknięcia wszystkich tych połączeń TIME_WAIT bez ponownego uruchamiania systemu operacyjnego Windows?

Po kilku dniach aplikacja przestaje przyjmować nowe połączenia.

Zajmowaliśmy się także tym problemem. Wygląda na to, że Amazon znalazł podstawową przyczynę i poprawił ją. Oto informacje, które mi dali.

Cześć, wklejam poniżej wyjaśnienie przyczyny tego problemu. Dobra wiadomość jest taka, że ​​zostało to naprawione bardzo niedawno przez nasz zespół inżynierów. Aby uzyskać poprawkę, wszystko, co musisz zrobić, to ZATRZYMAĆ / URUCHOMIĆ wystąpienia systemu Windows Server 2008, w których występuje ten problem. Ponownie nie mówię o REBOOT, który jest inny. STOP / START powoduje przeniesienie instancji do innego (zdrowego) hosta. Gdy te instancje uruchomią się ponownie, będą działały na hostach, które mają poprawkę, więc nie będą miały tego problemu ponownie. Poniżej znajduje się techniczne wyjaśnienie tego problemu. Po dogłębnym badaniu stwierdziliśmy, że podczas uruchamiania systemu Windows 2008 x64 na większości dostępnych typów wystąpień „ Wykryliśmy problem, który może powodować, że połączenia TCP pozostają w TIME_WAIT / CLOSE_WAIT przez zbyt długi czas (w niektórych przypadkach pozostają w tym stanie przez czas nieokreślony). Podczas gdy w tych stanach poszczególne pary gniazd pozostają bezużyteczne, a ich wystarczająca akumulacja spowoduje wyczerpanie portów dla danych portów. Jeśli wystąpi ta szczególna okoliczność, jedynym rozwiązaniem, aby usunąć pary gniazd, o których mowa, jest ponowne uruchomienie danej instancji. Ustaliliśmy, że przyczyną są wartości generowane przez funkcję timera w interfejsie API jądra systemu Windows 2008, który na wielu naszych 64-bitowych platformach czasami pobiera wartość, która jest bardzo daleko w przyszłości. Wpływa to na stos TCP, powodując znaczące znaczniki znaczników czasu na parach gniazd TCP w przyszłości. Według Microsoft istnieje przechowywany licznik skumulowany, który nie zostanie zaktualizowany, chyba że wartość wygenerowana przez to wywołanie interfejsu API będzie większa niż wartość skumulowana. Ostatecznym rezultatem jest to, że gniazda utworzone po tym punkcie będą w przyszłości wybite zbyt daleko, aż ten czas nadejdzie. W niektórych przypadkach widzieliśmy tę wartość kilkaset dni w przyszłość, dlatego pary gniazd wydają się utknąć na zawsze.

Odpowiedź Ryana jest dobrą ogólną radą, z tą różnicą, że nie dotyczy stanu Ravi w EC2. My także widzieliśmy ten problem iz jakiegokolwiek powodu Windows całkowicie ignoruje TcpTimedWaitDelay i nigdy nie zwalnia gniazda z jego stanu TIMED_WAIT.

Oczekiwanie nie pomaga ... ponowne uruchomienie aplikacji nie pomaga ... jedynym rozwiązaniem, które znaleźliśmy, jest ponowne uruchomienie systemu operacyjnego. Naprawdę brzydka.

Zupełnie losowo znalazłem ten wątek, próbując debugować osobny problem, ale jest to nieco poruszony, ale dobrze znany problem z Windows na EC2. Kiedyś mieliśmy wsparcia premium, i to z nich omówiono w otoczeniu niepublicznej poprzez ten kanał, ale jest to związane problem, że nie dyskutować na forach publicznych .

Jak wspomnieli inni, musisz dostroić serwery Windows po wyjęciu z pudełka. Jednak w ten sam sposób, w jaki StopWatch nie działa w powyższym wątku, stos TCP / IP również używa QueryPerformanceCounterwywołania, aby dokładnie określić, kiedy powinien trwać okres TCP_TIME_WAIT. Problem polega na tym, że na EC2 napotkali i wiedzą o problemie, w którym QueryPerformanceCounterszaleje i może powrócić w odległych czasach; to nie jest tak, że twój stan TIME_WAIT jest ignorowany, lecz to, że czas wygaśnięcia TIME_WAIT to potencjalnie lata. Podczas pracy w ustawieniach httpd możesz zobaczyć, jak szybko gromadzisz te gniazda zombie po napotkaniu stanu (generalnie widzimy, że jest to dyskretne wydarzenie, a nie, że powoli gromadzisz zombie).

To, co robimy, to uruchamianie usługi w tle, która sprawdza liczbę gniazd w stanie TIME_WAIT, a gdy wskaźnik znajdzie się powyżej pewnego progu, podejmujemy działanie (ponownie uruchamiamy serwer). W ciągu ostatnich 45 sekund ktoś wskazał, że możesz zatrzymać / uruchomić serwer, aby rozwiązać problem - sugeruję połączenie tych dwóch metod.

Domyślne ustawienia stosu TCP w systemie Windows nie są co najmniej optymalne dla systemów, które będą obsługiwać serwer HTTP.

Aby w pełni wykorzystać możliwości komputera z systemem Windows, gdy jest używany jako serwer HTTP, istnieje kilka parametrów, które normalnie poprawiasz, takich jak MaxUserPort TcpTimedWaitDelay, TcpAckFrequency, EnableDynamicBacklog, KeepAliveInterval itp.

Kilka lat temu napisałem do siebie notatkę , na wszelki wypadek, gdybym potrzebował szybkich ustawień domyślnych na początek. Zapoznaj się z parametrami, a następnie popraw je.

Niepowiązany z AWS, właśnie natrafiliśmy na ten problem, wydaje się, że jest wynikiem tego artykułu z KB:

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

Zasadniczo uruchamia się, jeśli system działa przez> 497 dni, a poprawka nie została zastosowana. Ponowne uruchomienie oczywiście oczyściło go - przez 16 miesięcy możemy nie wiedzieć, czy poprawka zadziałała, ale może to pomóc każdemu, kto ma długie serwery.

Doświadczyłem prawie tego samego na wielu urządzeniach z Windows Server 2008 R2 x64 z SP1, głównie z CLOSE_WAIT (który jest nieco inny niż TIME_WAIT). Natknąłem się na tę odpowiedź, która odwoływała się do KB w Microsoft i poprawki, jeśli serwery działały za modułem równoważenia obciążenia (które są moje). Po zainstalowaniu poprawki i ponownym uruchomieniu komputera wszystkie rzeczy CLOSE_WAIT zostały rozwiązane.