Como posso monitorar o comprimento da fila de aceitação?

Eu tenho uma hipótese: às vezes as conexões TCP chegam mais rapidamente do que o meu servidor pode accept(). Eles ficam na fila até a fila exceder e, em seguida, há problemas.

Como posso confirmar que isso está acontecendo?

Posso monitorar o comprimento da fila de aceitação ou o número de estouros? Existe um balcão exposto em algum lugar?

linux networking monitoring

— Phil Frost
fonte

Você está procurando netstat.

— Satō Katsura

Pelo que sei, netstatmostra apenas os comprimentos da fila de envio e recebimento, que não são iguais à fila de aceitação.

— Phil Frost

Sim, não é mostrado por padrão. man netstat | less +/Flags

— Satō Katsura

Não tenho certeza de como esses sinalizadores me dizem o tamanho da fila de aceitação - de fato netstat, parece não aparecer Flagspara as conexões TCP. A partir de um pequeno teste, parece que as conexões são mostradas como ESTABLISHEDem netstat, mesmo que eu tente abrir conexões para um processo que ocorre, listen()mas nunca accept().

— Phil Geada

Certo, olhando as fontes, parece que esses sinalizadores são para soquetes UNIX. Para o TCP, você pode apenas contar SYN_RECV. Não há outra fila além disso. Suponho que o kernel possa ser instruído de alguma forma a registrar pacotes descartados por causa de muitas conexões semi-abertas, mas há mais de 10 anos desde que eu olhei para a rede com Linux, então não tenho idéia de como fazer isso. Em uma nota lateral: você não está esperando para accept()fazer o trabalho, está esperando ACKs chegarem dos hosts de conexão para concluir as conexões.

— Satō Katsura

Respostas:

Para verificar se sua fila está transbordando, use netstat ou 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

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

Para monitorar seus tamanhos de fila, use o comando ss e procure os soquetes SYN-RECV.

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

Referência: https://blog.cloudflare.com/syn-packet-handling-in-the-wild/

— lfmunoz
fonte

O Sysdig fornecerá algumas dessas informações no final de cada acceptsyscall, como queuelenargumento. Também mostra o comprimento da fila como 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

Tanto quanto sei, ele não fornece um mecanismo para saber exatamente quando ou quantas vezes a fila transbordou. E seria complicado integrar isso ao monitoramento periódico collectdou similar.

— Phil Frost
fonte

O que você está procurando é a entrada na saída do comando sysctl -a como tal :::

net.ipv4.tcp_max_sync_backlog = 4096

No exemplo de exemplo acima, a lista de pendências de conexões de estado SYN é no máximo 4096. Você pode aumentar isso com base na quantidade de RAM existente no servidor. Considero que o backlog de 32K é um bom começo para o ajuste de servidores da Web com muita carga.

Verifique também se o seguinte NÃO está definido como Um (1):

net.ipv4.tcp_abort_on_overflow = 0

Caso contrário, ele descartará definitivamente os pacotes se houver um estouro de lista de pendências.

Você pode verificar facilmente via

"sysctl -a | lista pendente do egrep"

"sysctl -a | egrep overflow"

Além disso, você pode encontrar o rótulo "descartado" sob o

"ifconfig -a"

saída do comando. Isso mostra quantos pacotes foram descartados para cada interface, juntamente com outros dados e erros, etc.

Para registrar pacotes descartados, há um artigo de paywall no RHEL 7:

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

Para mais pesquisas, você pode ler:

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

Indica aqui de acordo com o TCP / IP ilustrado do livro de Steven:

"O limite da fila se aplica à soma do […] número de entradas na fila de conexão incompleta […] e […] do número de entradas na fila de conexão concluída […]."

Daí também afirma que:

"A fila de conexão concluída quase sempre está vazia porque, quando uma entrada é colocada nessa fila, a chamada do servidor para aceitar retorna e o servidor retira a conexão concluída da fila."

A fila de aceitação pode parecer completamente vazia e você precisará ajustar seu servidor Web Apache (possivelmente neste caso) para aceitar mais rapidamente as conexões colocadas na fila "total agregado".

— mkzia
fonte

Embora pareça haver alguma informação útil aqui, não tenho certeza de que responda à pergunta. Se eu perguntar: “Qual é o maior número de pessoas que já esteve neste auditório de uma vez?”, E você aponta para uma placa na parede que oferece a capacidade máxima, você não respondeu à pergunta.

— Scott

Na verdade, estou procurando o comprimento atual da fila, não o comprimento máximo da fila.

— Phil Frost

Deve ser tcp_max_syn_backlog, não tcp_max_SYNC_backlog como em sua resposta

— DevilaN 30/01

Sim ... e o StackOverflow fornece uma mensagem de erro retardada quando você tenta alterá-la: "As edições devem ter pelo menos 6 caracteres; há mais alguma coisa para melhorar nesta postagem?"

— Aaron C. de Bruyn