Vernice a corto di porte aperte, molte connessioni SYN_SENT

Di recente abbiamo riscontrato problemi con la nostra configurazione Varnish (3x) -> Apache (3x), che ha provocato un enorme picco nelle SYN_SENTconnessioni.

Il picco stesso è dovuto alla quantità di nuovo traffico che colpisce il sito (non un DDOS di alcun tipo) e sembra che le nostre macchine Varnish stiano avendo problemi a inoltrare il traffico ai server back-end (il calo del traffico Apache è correlato a picchi sulle vernici ), congestionando il pool di porte disponibili con SYN_SENT.

I keep-alive sono abilitati su Apache (15 secondi).

Da che parte sta la colpa? La quantità di traffico è significativa, ma non dovrebbe in alcun modo causare un arresto di tale installazione (3 macchine frontend Varnish, 3 server Apache backend).

Per favore aiuto.

Lo screenshot di Munin per le connessioni tramite firewall è qui .

Vernice ~$ netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

      9 CLOSE_WAIT
     12 CLOSING
    718 ESTABLISHED
     39 FIN_WAIT1
   1714 FIN_WAIT2
     76 LAST_ACK
     12 LISTEN
    256 SYN_RECV
   6124 TIME_WAIT

/etc/sysctl.conf (Vernice)

net.ipv4.netfilter.ip_conntrack_max = 262144
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60
net.ipv4.ip_local_port_range = 1024 65536
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_fin_timeout = 30

Apache netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

     11 CLOSE_WAIT
    286 ESTABLISHED
     38 FIN_WAIT2
     14 LISTEN
   7220 TIME_WAIT

/etc/sysctl.conf (Apache)

vm.swappiness=10
net.core.wmem_max = 524288
net.core.wmem_default = 262144
net.core.rmem_default = 262144
net.core.rmem_max = 524288
net.ipv4.tcp_rmem = 4096 262144 524288
net.ipv4.tcp_wmem = 4096 262144 524288
net.ipv4.tcp_mem = 4096 262144 524288

net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_max_syn_backlog = 16384
net.ipv4.tcp_keepalive_time = 30

net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.core.somaxconn = 2048


net.ipv4.conf.lo.arp_ignore=8
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2

vm.swappiness = 0

kernel.sysrq=1
kernel.panic = 30

Il tuo problema è probabilmente con il sysctl sui server Apache.

Alcuni presupposti: Tipicamente Varnish è molto più veloce nell'elaborare ogni connessione rispetto a un server web (a meno che forse i tuoi server Varnish non abbiano molto meno CPU, e i tuoi server Apache stiano servendo solo file statici memorizzati nella cache). in vernice di Apache.

Pertanto, le risorse sui server Apache potrebbero essere ampie, ma le richieste dovranno essere messe in coda da qualche parte, anche se solo per un breve periodo. In questo momento non fanno la fila in modo sano dove alla fine vengono elaborati.

Sembra che le tue richieste vengano bloccate in Varnish e non vengano inviate ai server Apache.

Ci sono alcune prove per questo:

Si noti nel grafico di Munin, prima che venga eseguito il backup dei SYN_SENT, le richieste in TIME_WAIT aumentano, quindi dopo un punto iniziano a accumularsi come SYN_SENTS. Ciò indica che le richieste stanno iniziando a rispondere più lentamente, quindi il backup della coda e le richieste non ricevono alcuna risposta.

Questo mi indica che il tuo server Apache non accetta abbastanza connessioni (dove possono quindi sedersi e fare la coda affinché Apache possa elaborarle).

Vedo diversi possibili limiti nel tuo file di configurazione:

Quando hai un picco, hai circa 30000 connessioni nello stato SYN_SENT sul tuo server Varnish.

Tuttavia, sul server Apache il tuo max_syn_backlog è solo 16384. Il tuo somaxconn è solo 2048.

Notare anche che la dimensione dei buffer di memoria di rete sui server Apache è molto bassa. Li hai adattati sul server Varnish a 16 MB. Ma sul server Apache il tuo net.ipv4.tcp_rmem è solo 524 KB per abbinare il tuo net.core.rmem_max.

Consiglio di aumentare tutti questi parametri sul server Apache.

Avrai bisogno di concentrarti maggiormente sulla diagnostica sul server Apache per scoprire esattamente cosa sta succedendo, ma potrebbe non essere necessario se aumenti questi valori.

Probabilmente non dovresti modificare net.ipv4.tcp_mem. Si noti che l'unità per questo parametro è in pagine, non in byte, quindi copiare lo stesso valore da net.ipv4.tcp_rmem o net.ipv4.tcp_wmem (entrambi in byte) non ha alcun senso. È sintonizzato automaticamente da Linux in base alla tua quantità di memoria, quindi raramente ha bisogno di modifiche. In realtà questo potrebbe essere il tuo problema, limitando arbitrariamente la memoria disponibile per l'accodamento generale delle connessioni.

Vedi: http://russ.garrett.co.uk/2009/01/01/linux-kernel-tuning/

Si noti inoltre che "vm.swappiness = 0" è impostato due volte, una volta come 10 e di nuovo in fondo come 0, che è il valore effettivo.

Sul server Varnish, prova a modificare questi 2 parametri:

net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 1

tw_reuse consentirà di riutilizzare le connessioni in TIME_WAIT.

tw_recycle potrebbe causare problemi con i sistemi di bilanciamento del carico, ecc.