Le connessioni TIME_WAIT non vengono ripulite dopo il periodo di timeout che scade

Sto testando lo stress con uno dei miei server, colpendolo con un stream costante di nuove connessioni di networking, il tcp_fin_timeout è impostato su 60, quindi se invio un stream costante di qualcosa di 100 richieste al secondo, mi aspetto di vedere una media media di 6000 (60 * 100) connessioni in uno stato TIME_WAIT , questo sta accadendo, ma guardando a netstat (utilizzando -o) per vedere i timer, vedo le connessioni come:

 TIME_WAIT timewait (0.00/0/0) 

where il loro timeout è scaduto, ma la connessione è ancora in giro, poi alla fine esaurisco le connessioni. Qualcuno sa perché questi collegamenti non vengono ripuliti? Se interromperei la creazione di nuovi collegamenti, infine, scompaiono, ma mentre creo costantemente nuove connessioni, non sembra che il kernel non abbia la possibilità di pulirle? Esistono altre opzioni di configuration che devo impostare per rimuovere le connessioni non appena sono scadute?

  • OpenSSH SFTP con Chroot, come modificare la password
  • Rimozione di un nuovo messaggio di rilevamento delle impronte digitali da nmap
  • Hardlinks di un file
  • nginx - linux permessi argomento interessante
  • Utilizzo di APT come posso installare phpMyAdmin senza 'apache2' e tutti gli altri gumpf?
  • Massimizzazione della performance e del throughput dei rsync - server gigabit connessi direttamente
  • Il server sta eseguendo Ubuntu e il mio server web è nginx. Inoltre ha iptables con tracking di connessione, non sicuro se ciò avrebbe causato queste connessioni TIME_WAIT a vivere.

    Grazie a Mark.

  • Come provare l'integrità di un database di Exchange?
  • sudoers non funzionano per il command tar
  • consumatore kworker + 90% IO e scrittura disco zero
  • snmpd per abilitare BRIDGE-MIB o Q-BRIDGE-MIB
  • Come dare permessi di scrittura utilizzando setfacl mantenendo le autorizzazioni esistenti?
  • Backup / Ripristino di SharePoint senza stsadm
  • 3 Solutions collect form web for “Le connessioni TIME_WAIT non vengono ripulite dopo il periodo di timeout che scade”

    Questo problema è stato interessante come mi sono spesso domandato. Ho fatto un test di coppia e ho trovato alcuni risultati interessanti. Se apri una connessione a un server e aspettiamo 60 secondi, è sempre stata pulita (non è mai arrivata a 0.00 / 0/0). Se ho aperto 100 connessioni, anche loro sono state ripulite dopo 60 secondi. Se avessi aperto 101 connessioni vorrei iniziare a vedere le connessioni nello stato che hai menutato (che ho visto anche prima). E sembrano durare circa 120s o 2xMSL (che è 60) indipendentemente da quale fin_timeout è impostato su. Ho fatto qualche scavo nel codice sorgente del kernel e ho trovato quello che credo sia la "ragione". Sembra che ci sia un codice che tenta di limitare la quantità di socket che raccoglie quello che succede per 'ciclo'. La frequenza del ciclo stesso è impostata su una scala basata su HZ:

     linux-source-2.6.38/include/net/inet_timewait_sock.h: 35 #define INET_TWDR_RECYCLE_SLOTS_LOG 5 36 #define INET_TWDR_RECYCLE_SLOTS (1 << INET_TWDR_RECYCLE_SLOTS_LOG) 37 38 /* 39 * If time > 4sec, it is "slow" path, no recycling is required, 40 * so that we select tick to get range about 4 seconds. 41 */ 42 #if HZ <= 16 || HZ > 4096 43 # error Unsupported: HZ <= 16 or HZ > 4096 44 #elif HZ <= 32 45 # define INET_TWDR_RECYCLE_TICK (5 + 2 - INET_TWDR_RECYCLE_SLOTS_LOG) 46 #elif HZ <= 64 47 # define INET_TWDR_RECYCLE_TICK (6 + 2 - INET_TWDR_RECYCLE_SLOTS_LOG) 48 #elif HZ <= 128 49 # define INET_TWDR_RECYCLE_TICK (7 + 2 - INET_TWDR_RECYCLE_SLOTS_LOG) 50 #elif HZ <= 256 51 # define INET_TWDR_RECYCLE_TICK (8 + 2 - INET_TWDR_RECYCLE_SLOTS_LOG) 52 #elif HZ <= 512 53 # define INET_TWDR_RECYCLE_TICK (9 + 2 - INET_TWDR_RECYCLE_SLOTS_LOG) 54 #elif HZ <= 1024 55 # define INET_TWDR_RECYCLE_TICK (10 + 2 - INET_TWDR_RECYCLE_SLOTS_LOG) 56 #elif HZ <= 2048 57 # define INET_TWDR_RECYCLE_TICK (11 + 2 - INET_TWDR_RECYCLE_SLOTS_LOG) 58 #else 59 # define INET_TWDR_RECYCLE_TICK (12 + 2 - INET_TWDR_RECYCLE_SLOTS_LOG) 60 #endif 61 62 /* TIME_WAIT reaping mechanism. */ 63 #define INET_TWDR_TWKILL_SLOTS 8 /* Please keep this a power of 2. */ The number of slots is also set here: 65 #define INET_TWDR_TWKILL_QUOTA 100 

    Nel codice attuale di timewait puoi vedere where utilizza il preventsvo per smettere di uccidere le connessioni TIME_WAIT se ha già fatto troppi:

     linux-source-2.6.38/net/ipv4/inet_timewait_sock.c: 213 static int inet_twdr_do_twkill_work(struct inet_timewait_death_row *twdr, 214 const int slot) 215 { ... 240 if (killed > INET_TWDR_TWKILL_QUOTA) { 241 ret = 1; 242 break; 243 } 

    Qui troverai ulteriori informazioni sul perché HZ è impostato su ciò che è: http://kerneltrap.org/node/5411 Ma non è raro aumentarlo. Penso tuttavia che sia di solito più comune per consentire a tw_reuse / recycling di aggirare questo meccanismo di benna / quota (che mi sembra confuso ora che ho letto su di esso, aumentando HZ sarebbe una soluzione molto più sicura e più pulita). Ho postato questa risposta come risposta ma penso che ci potrebbe essere più discussione qui su quale sia il modo giusto per risolvere il problema. Grazie per la domanda interessante!

    Invece di utilizzare tcp_tw_recycle = 1 utilizzare quanto segue:

     tcp_tw_reuse = 1 

    Rapporti Recyle per essere rotti e in alcuni casi non funziona quando si utilizza NAT o il bilanciamento del carico.

    il valore net.ipv4.tcp_fin_timeout è impostato a 60s. Non mi è mai stato chiaro perché le prese tendono a rimanere in TIME_WAIT più a lungo di questo limite.

    la tcp_tw_recycle è rotta, non so come io non lo uso. Probabilmente hai bisogno di impostare tcp_tw_reuse su 1 ma presumibilmente questo causerà problemi con NAT.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.