Tonnellate di connessioni TCP nello stato TIME_WAIT su Windows 2008 - in esecuzione su Amazon AWS

Sistema operativo: Windows Server 2008, SP2 (in esecuzione su Amazon EC2).

L'esecuzione di un'app Web tramite Apache httpd e tomcat server 6.02 e il server Web ha impostazioni keep-alive.

Ci sono circa 69.250 (porta http 80) + 15000 (oltre alla porta 80) connessioni TCP nello stato TIME_WAIT (usato netstat & tcpview). Queste connessioni non sembrano chiudersi anche dopo l'arresto del server Web (atteso 24 ore)

Contatori monitor delle prestazioni:

• Connessioni attive TCPv4: 145 KB
• Connessioni passive TCPv4: 475K
• Connessioni errore TCPv4: 16 KB
• Ripristino connessioni TCPv4: 23K

HKEY_LOCAL_MACHINE\System \CurrentControlSet\Services\Tcpip\Parameters non ha la chiave TcpTimedWaitDelay, quindi il valore dovrebbe essere predefinito (2 * MSL, 4 minuti)

Anche se ci sono migliaia di richieste di connessione in arrivo contemporaneamente, perché il sistema operativo Windows non è in grado di pulirle alla fine?
Quali potrebbero essere i motivi alla base di questa situazione?
C'è un modo per chiudere forzatamente tutte queste connessioni TIME_WAIT senza riavviare il sistema operativo Windows?

Dopo pochi giorni l'app smette di prendere nuove connessioni.

Abbiamo affrontato anche questo problema. Sembra che Amazon abbia trovato la causa principale e l'abbia corretta. Ecco le informazioni che mi hanno dato.

Ciao, sto incollando di seguito una spiegazione di ciò che stava causando questo problema. La buona notizia è che questo è stato corretto molto recentemente dal nostro team di ingegneri. Per ottenere la correzione, tutto ciò che dovrai fare è FERMARE / AVVIARE le istanze di Windows Server 2008 in cui riscontri questo problema. Ancora una volta, non sto parlando di REBOOT che è diverso. STOP / START fa spostare l'istanza su un host diverso (integro). Quando queste istanze vengono riavviate, saranno in esecuzione su host che hanno la correzione in atto, quindi non avranno più questo problema. Ora di seguito è la spiegazione tecnica di questo problema. Dopo un'indagine approfondita, abbiamo scoperto che durante l'esecuzione di Windows 2008 x64 sulla maggior parte dei tipi di istanza disponibili, ho identificato un problema che potrebbe comportare connessioni TCP che rimangono in TIME_WAIT / CLOSE_WAIT per periodi eccessivamente lunghi (in alcuni casi, rimanendo in questo stato indefinitamente). Mentre in questi stati, le particolari coppie di socket rimangono inutilizzabili e, se si accumulano abbastanza, si tradurrà in esaurimento delle porte per le porte in questione. Se si verifica questa particolare circostanza, l'unica soluzione per cancellare le coppie di socket in questione è riavviare l'istanza in questione. Abbiamo determinato che la causa sono i valori prodotti da una funzione timer nell'API del kernel di Windows 2008 che, su molte delle nostre piattaforme a 64 bit, a volte recupererà un valore estremamente lontano in futuro. Ciò influisce sullo stack TCP causando che i timestamp sulle coppie di socket TCP vengano timbrati in modo significativo in futuro. Secondo Microsoft, esiste un contatore cumulativo memorizzato che non verrà aggiornato a meno che il valore prodotto da questa chiamata API sia maggiore del valore cumulativo. Il risultato finale è che i socket creati dopo questo punto saranno tutti timbrati troppo in futuro fino al raggiungimento di quel momento futuro. In alcuni casi, abbiamo visto questo valore diverse centinaia di giorni nel futuro, quindi le coppie di socket sembrano essere bloccate per sempre.

La risposta di Ryan è un buon consiglio generale, tranne per il fatto che non si applica alla condizione che Ravi sta riscontrando in EC2. Anche noi abbiamo visto questo problema e per qualsiasi motivo Windows ignora completamente TcpTimedWaitDelay e non rilascia mai il socket dal suo stato TIMED_WAIT.

L'attesa non aiuta ... riavviare l'app non aiuta ... l'unico rimedio che abbiamo trovato è riavviare il sistema operativo. Davvero brutto.

Ho trovato questo thread completamente casualmente mentre cercavo di eseguire il debug di un problema separato, ma questo è un problema poco educato, ma ben noto con Windows su EC2. Abbiamo usato per avere supporto premium, e discusso con loro in un ambiente non-pubblico attraverso quel canale, ma questo è un problema correlato che abbiamo fatto discutere nei forum pubblici .

Come altri hanno già detto, è necessario ottimizzare immediatamente i server Windows. Tuttavia, allo stesso modo in cui StopWatch non funziona nel thread sopra, lo stack TCP / IP utilizza anche la QueryPerformanceCounterchiamata per determinare esattamente quando dovrebbe durare il periodo TCP_TIME_WAIT. Il problema è che su EC2 hanno riscontrato, e conoscono, un problema in cui QueryPerformanceCounterva in tilt e può tornare a tempi molto, molto nel futuro; non è che il tuo stato TIME_WAIT viene ignorato, è che il tempo di scadenza di TIME_WAIT è potenzialmente anni nel futuro. Quando si esegue in un'impostazione httpd, è possibile vedere come si accumulano rapidamente questi socket di zombi una volta rilevato lo stato (generalmente vediamo che si tratta di un evento discreto, non che accumuli lentamente zombi).

Ciò che facciamo è eseguire un servizio in background che interroga il numero di socket nello stato TIME_WAIT e, una volta superato questo limite, prendiamo provvedimenti (riavvia il server). In qualche modo negli ultimi 45 secondi , qualcuno ha sottolineato che è possibile arrestare / avviare il server per risolvere il problema - ti suggerisco di abbinare questi due approcci.

Le impostazioni predefinite per lo stack TCP in Windows, per non dire altro, non sono ottimali per i sistemi che ospiteranno un server HTTP.

Per ottenere il meglio dal tuo computer Windows quando usato come server HTTP, ci sono alcuni parametri che normalmente dovresti modificare come MaxUserPort TcpTimedWaitDelay, TcpAckFrequency, EnableDynamicBacklog, KeepAliveInterval ecc

Avevo scritto un appunto su questo alcuni anni fa, nel caso avessi bisogno di alcune impostazioni predefinite veloci per iniziare. Sentiti libero di capire i parametri e poi modificarli.

Non correlato ad AWS, ci siamo appena imbattuti in questo problema, sembra come risultato di questo articolo KB:

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

Fondamentalmente, si avvia se un sistema è attivo per> 497 giorni e l'aggiornamento rapido non è stato applicato. Un riavvio, ovviamente, lo ha cancellato - potremmo non sapere per i prossimi 16 mesi se l'aggiornamento rapido ha funzionato, ma questo potrebbe aiutare chiunque abbia server di lunga durata.

Stavo sperimentando la stessa identica cosa su un numero di scatole con Windows Server 2008 R2 x64 con SP1, principalmente con CLOSE_WAIT (che è in qualche modo diverso da TIME_WAIT). Mi sono imbattuto in questa risposta che faceva riferimento a un KB di Microsoft e un aggiornamento rapido se i server erano in esecuzione dietro un bilanciamento del carico (che il mio è). Dopo aver installato l'aggiornamento rapido e riavviato, tutte le cose CLOSE_WAIT sono state risolte.