Come posso monitorare la lunghezza della coda di accettazione?

Ho un'ipotesi: a volte le connessioni TCP arrivano più velocemente di quanto il mio server possa accept()farle. Si mettono in coda fino a quando la coda non trabocca e quindi non ci sono problemi.

Come posso confermare che ciò sta accadendo?

Posso monitorare la lunghezza della coda di accettazione o il numero di overflow? C'è un bancone esposto da qualche parte?

linux networking monitoring

— Phil Frost
fonte

Stai cercando netstat.

— Satō Katsura,

Per quanto ne so, netstatmostra solo le lunghezze della coda di invio e ricezione, che non coincidono con la coda di accettazione.

— Phil Frost,

Sì, non è mostrato per impostazione predefinita. man netstat | less +/Flags

— Satō Katsura,

Non sono sicuro di come questi flag mi diano la lunghezza della coda di accettazione - in realtà netstatnon sembra mostrare Flagsaffatto per le connessioni TCP. Da un po 'di test, sembra che le connessioni siano mostrate come ESTABLISHEDin netstat, anche se provo ad aprire le connessioni a un processo che funziona, listen()ma mai accept().

— Phil Frost,

Bene, guardando le fonti sembra che quelle bandiere siano per socket UNIX. Per TCP puoi SYN_RECVcomunque contare . Non c'è altra coda oltre quella. Suppongo che al kernel possa essere detto in qualche modo di registrare i pacchetti rilasciati a causa di troppe connessioni semiaperte, ma sono passati più di 10 anni da quando ho guardato alla rete con Linux, quindi non ho idea di come farlo. Nota a margine: non stai aspettando accept()di fare il suo lavoro, stai aspettando l' ACKarrivo di s dagli host di connessione per completare le connessioni.

— Satō Katsura,

Risposte:

Per verificare se la coda trabocca, utilizzare netstat o nstat

[centos ~]$ nstat -az | grep -i listen
TcpExtListenOverflows           3518352            0.0
TcpExtListenDrops               3518388            0.0
TcpExtTCPFastOpenListenOverflow 0  0.0

[centos ~]$ netstat -s | grep -i LISTEN
    3518352 times the listen queue of a socket overflowed
    3518388 SYNs to LISTEN sockets dropped

Riferimento: https://perfchron.com/2015/12/26/investigating-linux-network-issues-with-netstat-and-nstat/

Per monitorare le dimensioni della coda, utilizzare il comando ss e cercare i socket SYN-RECV.

$ ss -n state syn-recv sport = :80 | wc -l
119

Riferimento: https://blog.cloudflare.com/syn-packet-handling-in-the-wild/

— lfmunoz
fonte

Sysdig fornirà alcune di queste informazioni alla fine di ogni acceptsyscall, come queuelenargomento. Mostra anche la lunghezza della coda come queuemax.

7598971 21:05:30.322229280 1 gunicorn (6451) < accept fd=13(<4t>127.0.0.1:45882->127.0.0.1:8003) tuple=127.0.0.1:45882->127.0.0.1:8003 queuepct=0 queuelen=0 queuemax=10

Per quanto ne so, non fornisce alcun meccanismo per sapere esattamente quando o quante volte la coda è traboccata. E sarebbe ingombrante integrarlo con un monitoraggio periodico collectdo simile.

— Phil Frost
fonte

Quello che stai cercando è la voce nell'output del comando sysctl -a come tale :::

net.ipv4.tcp_max_sync_backlog = 4096

Nel caso di esempio sopra, l'arretrato di connessioni di stato SYN è massimo 4096. È possibile aumentarlo in base alla quantità di RAM presente nel server. Ritengo che il backlog a 32 KB sia un buon inizio per la messa a punto di server Web carichi di molto.

Assicurarsi inoltre che NON sia impostato su One (1) ::

net.ipv4.tcp_abort_on_overflow = 0

Altrimenti eliminerà sicuramente i pacchetti in caso di overflow del backlog.

Puoi facilmente controllare tramite

"sysctl -a | egrep backlog"

"sysctl -a | egrep overflow"

Inoltre, puoi trovare l'etichetta "rilasciata" sotto

"ifconfig -a"

output del comando. Ciò mostra quanti pacchetti sono stati eliminati per ciascuna interfaccia insieme ad altri dati, errori, ecc.

Per la registrazione dei pacchetti rilasciati c'è un articolo paywall su RHEL 7 ::

https://access.redhat.com/solutions/1191593

Per ulteriori ricerche puoi leggere:

http://veithen.io/2014/01/01/how-tcp-backlog-works-in-linux.html

Indica qui come da TCP / IP illustrato Steven's Book:

"Il limite di coda si applica alla somma di [...] il numero di voci sulla coda di connessione incompleta [...] e [...] il numero di voci sulla coda di connessione completata [...]."

Quindi afferma anche che:

"La coda di connessione completata è quasi sempre vuota perché quando viene inserita una voce su questa coda, la chiamata del server per accettare ritorna e il server toglie la connessione completata dalla coda."

La coda di accettazione può quindi sembrare completamente vuota e dovrai ottimizzare il tuo server Web Apache (possibilmente in questo caso) per accettare più velocemente le connessioni inserite nella coda "totale aggregato".

— mkzia
fonte

Mentre qui sembrano esserci alcune informazioni utili, non sono sicuro che risponda alla domanda. Se chiedo: "Qual è il maggior numero di persone che siano mai state in questo auditorium in una sola volta?", E indichi un cartello sul muro che offre la massima capacità, non hai risposto alla domanda.

— Scott,

In effetti sto cercando la lunghezza corrente della coda, non la lunghezza massima della coda.

— Phil Frost,

Dovrebbe essere tcp_max_syn_backlog, non tcp_max_SYNC_backlog come nella tua risposta

— DevilaN

Sì ... e StackOverflow ti dà un messaggio di errore ritardato quando provi a cambiarlo: "Le modifiche devono contenere almeno 6 caratteri; c'è qualcos'altro da migliorare in questo post?"

— Aaron C. de Bruyn,