Vraag Tal van TCP-verbindingen in TIME_WAIT staat op Windows 2008 - draait op Amazon AWS


Besturingssysteem: Windows Server 2008, SP2 (draait op EC2 Amazon).

Het uitvoeren van een web-app met behulp van Apache httpd & tomcat-server 6.02 en de webserver heeft instellingen voor het in leven houden.

Er zijn ongeveer 69.250 (http-poort 80) + 15000 (anders dan poort 80) TCP-verbindingen in TIME_WAIT-status (gebruikt netstat & tcpview). Deze verbindingen lijken niet te sluiten, zelfs niet na het stoppen van de webserver (24 uur gewacht)

Prestatiemonitor-tellers:

  • TCPv4 Actieve verbindingen: 145K
  • TCPv4-passieve verbindingen: 475K
  • TCPv4-mislukkingsverbindingen: 16K
  • TCPv4-verbindingen Reset: 23K

HKEY_LOCAL_MACHINE\System \CurrentControlSet\Services\Tcpip\Parameters heeft geen TcpTimedWaitDelay-sleutel, dus waarde moet de standaardwaarde zijn (2 * MSL, 4 mins)

Zelfs als er duizenden verbindingsverzoeken tegelijkertijd komen, waarom kan Windows OS ze uiteindelijk niet opruimen?
Wat kunnen de redenen zijn voor deze situatie?
Is er een manier om al deze TIME_WAIT-verbindingen met geweld te sluiten zonder Windows OS opnieuw te starten?

Na een paar dagen stopt de app met het nemen van nieuwe verbindingen.


17
2018-03-18 14:26


oorsprong




antwoorden:


We hebben ook met dit probleem te maken gehad. Het lijkt erop dat Amazon de oorzaak heeft gevonden en gecorrigeerd. Hier is de info die ze me gaven.

Hallo, ik plak hieronder een uitleg   van wat dit probleem veroorzaakte. Goed   nieuws is dat dit erg is opgelost   onlangs door ons technisch team. Naar   Oplossing, alles wat je hoeft te doen is   STOP / START de Windows Server 2008   gevallen waarin u dit ziet   kwestie. Nogmaals, ik heb het hier niet over   REBOOT dat anders is. STOP / START   zorgt ervoor dat de instantie naar a verplaatst   verschillende (gezonde) gastheer. Wanneer deze   instanties worden opnieuw gelanceerd, dat zullen ze zijn   draaien op hosts die de oplossing hebben   plaats zodat ze dit probleem niet hebben   nog een keer. Hieronder is de engineering   uitleg van dit probleem. Na een   diepgaand onderzoek hebben we gevonden   dat bij het uitvoeren van Windows 2008 x64 op   de meeste beschikbare instantietypen, dat hebben we gedaan   heeft een probleem geïdentificeerd dat kan optreden   in TCP-verbindingen die blijven   TIME_WAIT / CLOSE_WAIT voor overmatig   lange perioden (in sommige gevallen   voor onbepaalde tijd in deze toestand blijven).   Terwijl in deze staten, het bijzondere   socketparen blijven onbruikbaar en indien   voldoende accumulatie, zal resulteren in een poort   uitputting van de havens in kwestie.   Als deze bijzondere omstandigheid   treedt op, de enige oplossing om de   socketparen in kwestie is om opnieuw op te starten   het betreffende exemplaar. Wij hebben   bepaald de oorzaak als de waarden   geproduceerd door een timerfunctie in   Windows 2008 kernel API die op veel   van onze 64-bit platforms, zal   haal af en toe een waarde op die dat wel is   extreem ver in de toekomst. Deze   beïnvloedt de TCP-stack door de   tijdstempels op de TCP-socket paren aan   aanzienlijk ver weg gestempeld worden in de   toekomst. Volgens Microsoft daar   is een opgeslagen cumulatieve teller die   zal niet worden bijgewerkt, tenzij de waarde   geproduceerd door deze API-aanroep groter is   dan de cumulatieve waarde. De   het uiteindelijke resultaat is dat stopcontacten   gemaakt na dit punt zal alles zijn   te veel gestempeld in de toekomst tot   die toekomstige tijd is bereikt. In bepaalde   gevallen hebben we deze waarde verschillende gezien   honderd dagen in de toekomst, dus de   socketparen lijken vast te zitten   voor altijd.


14
2018-04-04 17:48



Deze thread is als twee weken oud en op de een of andere manier heb je hun reactie geplaatst seconden voor mij. Geweldig nieuws! Ze geven ons nu al maanden de ommekeer. - Marc Bollinger
@MarcBollinger: zojuist gevonden Uw antwoord via het AWS-team antwoord op de draad die u noemde (System.Diagnostics.Stopwatch werkt niet) - die thread is nog steeds onbeantwoord, maar uw opmerking hier lijkt aan te geven dat deze misschien al is aangepakt volgens de info @GregB die is geciteerd? Of kon het QueryPerformanceCounter probleem met rootoorzaken nog steeds aanwezig zijn en alleen het TCP-probleem bij de hand is verholpen? Bedankt voor uw inzicht! - Steffen Opel


Ryan's antwoord is goed algemeen advies, behalve dat het niet van toepassing is op de toestand die Ravi ervaart in EC2. Ook wij hebben dit probleem gezien en om welke reden dan ook negeert Windows de TcpTimedWaitDelay volledig en laat de socket nooit los van zijn TIMED_WAIT-status.

Wachten helpt niet ... opnieuw opstarten van de app helpt niet ... de enige remedie die we hebben gevonden is om het OS opnieuw te starten. Echt lelijk.


4
2018-03-22 23:07





Ik heb deze draad helemaal willekeurig gevonden terwijl ik een afzonderlijk probleem probeerde te debuggen, maar dit is een weinig-verhoogd, maar bekend probleem met Windows op EC2. We hadden eersteklasondersteuning en bespraken dit met hen in een niet-openbare omgeving via dat kanaal, maar dit is een gerelateerd probleem dat wij deed bespreken in de openbare forums.

Zoals anderen al hebben gezegd, moet u Windows Servers uit de doos afstemmen. Op dezelfde manier als StopWatch niet werkt in de bovenstaande thread, gebruikt de TCP / IP-stack ook de QueryPerformanceCounter aanroep om precies te bepalen wanneer de TCP_TIME_WAIT-periode moet duren. Het probleem is dat ze op EC2 een probleem hebben aangetroffen en hiervan op de hoogte zijn QueryPerformanceCounter gaat in de war en kan tot ver in de toekomst tijden terugbrengen; het is niet dat je TIME_WAIT-status genegeerd wordt, het is dat de vervaltijd van TIME_WAIT mogelijk jaren in de toekomst is. Als je in een httpd-instelling werkt, kun je zien hoe je deze zombie-sockets snel verzamelt zodra de toestand is aangetroffen (we zien over het algemeen dat dit een discrete gebeurtenis is, niet dat je langzaam zombies verzamelt).

Wat we doen, is een service uitvoeren op de achtergrond die het aantal sockets in de TIME_WAIT-status bevraagt, en wanneer deze over een bepaalde drempel zweeft, ondernemen we actie (de server opnieuw opstarten). Een of andere manier in de afgelopen 45 seconden, iemand heeft erop gewezen dat je de server kunt stoppen / starten om het probleem op te lossen - ik stel voor dat je deze twee benaderingen koppelt.


3
2018-04-04 17:53





De standaardinstellingen voor de TCP-stack in Windows zijn op zijn zachtst gezegd niet optimaal voor systemen die een HTTP-server gaan hosten.

Om het beste uit uw Windows-machine te halen bij gebruik als een HTTP-server, zijn er enkele parameters die u normaal zou aanpassen zoals MaxUserPort TcpTimedWaitDelay, TcpAckFrequency, EnableDynamicBacklog, KeepAliveInterval enz.

Ik had een geschreven notitie voor mezelf hierover een paar jaar geleden, voor het geval dat ik een paar snelle standaardinstellingen nodig heb om mee te beginnen. Voel je vrij om de parameters te begrijpen en vervolgens aan te passen.


2
2018-03-22 03:44





Niet gerelateerd aan AWS, we zijn dit probleem net tegengekomen, het lijkt een resultaat van dit KB-artikel:

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

Kortom, het begint als een systeem> 497 dagen in gebruik is en de hotfix niet is toegepast. Een herstart heeft het natuurlijk gewist - misschien weten we de volgende 16 maanden niet of de hotfix heeft gewerkt, maar dit kan iedereen helpen met lang beschikbare servers.


2
2017-07-25 11:24



Wat een vreemd aantal dagen. We werden er ook door gebeten - 500 dagen 12 uur bedrijfstijd. Tijd om deze doos toch te decommeren. - Josh Smeaton


Ik ervoer bijna hetzelfde op een aantal vakken met Windows Server 2008 R2 x64 met SP1, meestal met CLOSE_WAIT (wat enigszins verschilt van TIME_WAIT). ik stootte tegen dit antwoord waarnaar wordt verwezen a KB bij Microsoft en een hotfix als de servers achter een load-balancer aan het rennen waren (die van mij). Na het installeren van de hotfix en het opnieuw opstarten, zijn alle items van CLOSE_WAIT opgelost.


0
2017-08-28 20:03