Errore di networking con 65k di connessioni TIME_WAIT

Abbiamo avuto problemi con uno dei nostri server di image la settimana scorsa e abbiamo bisogno di aiuto. Vedi il nostro grafico di monitoraggio munin:

immettere qui la descrizione dell'immagine

Stiamo eseguendo compressioni di debian e abbiamo molte richieste perché questo è uno dei nostri server di image. Non usiamo il mantenimento vivo (forse dovremmo, ma è un altro argomento)

Questi numbers sono i conteggi di richiesta al minuto dai nostri file di log:

  • 17:19: 66516
  • 17:20: 64627
  • 17:21: 123365
  • 17:22: 111207
  • 17:23: 58257
  • 17:24: 17710
  • … e così via

Quindi vedi, abbiamo molte richieste al minuto, ma come la maggior parte delle richieste sono servite in 0-1ms, tutto va bene in genere.

Ora, come si vede nel munin grafico munin non è riuscito a connettersi a questo server sulla port munin e chiedere i numbers pertinenti. La connessione è semplicemente fallita. Poiché il server non è sovraccarico con qualsiasi mezzo (CPU, memory, networking). deve avere qualcosa a che fare con il nostro stack firewall / tcp. Al momento il plugin munin non è riuscito a connettersi abbiamo avuto solo 17MBit di traffico in entrata e in output su una connessione 100MBit.

sei spesso qui un limite di 65k di connessioni TCP, ma questo è normalmente fuorviante in quanto si riferisce all'intestazione tcp 16bit e appartiene a 65k per combinazione ip / port.

il timeout timeout è impostato su

net.ipv4.tcp_fin_timeout = 60 

potremmo abbassare questo per abbandonare più connessioni TIME_WAIT prima, ma prima voglio sapere quanto limita la networking da essere raggiungibile.

stiamo utilizzando iptables con module di stato. Ma abbiamo già sollevato il parametro max_conntrack.

  net.ipv4.netfilter.ip_conntrack_max = 524288 

qualcuno sa quali parametri del kernel guardare o come diagnosticare questo problema la prossima settimana quando abbiamo la nostra prossima visione?

  • Evitare le connessioni TIME_WAIT
  • perché linux riutilizza la port 'time_wait'?
  • Problema di connessione Redis
  • È ansible ripristinare una connessione TIME_WAIT?
  • Alto numero di prese in stato TIME-WAIT, server che non risponde al carico
  • Come proiettare / misurare l'host fisico attendere con gli ospiti multi-core in ESXi
  • 2 Solutions collect form web for “Errore di networking con 65k di connessioni TIME_WAIT”

    FIN_WAIT (timeout per la richiesta di riconoscimento FIN) non è la stessa di TIME_WAIT (tempo per garantire che la presa non sia più utilizzata). E sì, con le porte 65k in stato TIME_WAIT, si esaurirà solo le porte TCP se si utilizza un singolo richiedente IP – come potrebbe essere il caso se tutti i client sono dietro un dispositivo NAT. Potresti anche gestire risorse a causa di una tabella di blocchi di controllo di trasmissione troppo popolata – vedere questa eccellente carta, anche se carta datata, per le possibili implicazioni di performance.

    Se sei veramente preoccupato per le tue prese in stato TIME_WAIT e non hai firewall di stato tra i tuoi clienti e il tuo server, puoi considerare l'impostazione / proc / sys / net / ipv4 / tcp_tw_recycle, ma tu sacrificere la conformità RFC e potrebbe avere un lato interessante – Effetti in futuro a causa di tale materia.

    Ok, ho trovato la risposta da solo. Il plugin munin funziona abbastanza lentamente e sta colpendo il proprio valore di timeout. se la tabella conntrack è piena lettura da / proc / net / ip_conntrack diventa molto molto lenta. il server sembra essere sensibile mentre il plugin munin non lo è.

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