Por que a perda de pacotes APÓS o tcpdump registrou o pacote?

Question

Nós encontramos uma estranha perda de pacotes e queremos saber o motivo disso.

Temos um servidor de imagens e um servidor para enfatizar o servidor de imagens. Ambos estão localizados no mesmo datacenter

Primeiro, executamos um teste de carga como este (comando encurtado para legibilidade):

ab -n 50 -c 5 http://testserver/img/de.png

A imagem tem apenas cerca de 300 bytes. Os resultados são respostas muito rápidas:

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       0
Processing:     1    3   0.7      3       4
Waiting:        1    3   0.7      3       3
Total:          1    3   0.7      3       4

Quando aumentamos a simultaneidade, vemos alguns atrasos (comando reduzido para legibilidade):

sudo ab -n 500 -c 50 http://testserver/img/de.png

Resultados com simultaneidade 50:

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0       1
Processing:     2   35 101.6     12     614
Waiting:        2   35 101.6     12     614
Total:          3   36 101.7     12     615

Assim, vemos que a maioria dos pedidos é bastante rápida, alguns deles são muito lentos.

Nós despejamos todo o tráfego de rede com o tcpdump e vimos algumas retransmissões estranhas.

texto alternativo http://vygen.de/screenshot1.png

esse dump foi tirado no servidor de imagens!

para que você veja que o pacote inicial (No. 306) contendo o pedido GET está chegando no imageserver, mas parece que o pacote se perdeu depois que o tcpdump o registrou. Parece-me que este pacote não chega ao servidor de imagens do tomcat.

a retransmissão é acionada pelo servidor solicitante 200ms depois e tudo corre bem depois.

Você conhece alguma razão pela qual um pacote pode se perder depois de ser recebido?

Nossas máquinas são ambas:

• CPU Intel (R) Core (TM) i7 920 @ 2,67GHz
• 8 GB de RAM
• Controlador Ethernet: Realtek Semiconductor Co., Ltd. Controlador Ethernet Gigabit PCI Express RTL8111 / 8168B (rev 02)
• Debian versão 5.0.5

Portanto, não temos problemas com relação à memória ou à carga da CPU.

Tivemos alguns problemas com o nosso controlador nic há algum tempo atrás. Nós lidamos com isso usando um driver diferente, estamos usando agora r8168 ao invés de r8169

Mas tivemos os mesmos problemas de pacotes perdidos com um Intel NIC  - Controlador Ethernet: Intel Corporation 82541PI Controlador Gigabit Ethernet (rev. 05)

Assim, vemos o mesmo problema com máquinas iguais, mas placas Ethernet diferentes.

Até agora eu pensava que a perda de pacotes só aconteceria entre os servidores na linha, quando o pacote fosse corrompido ou algo assim.

Nós realmente queremos saber quais razões podem existir para a perda de pacotes após o tcpdump registrá-las.

Sua ajuda é muito apreciada.

    

Answer 1

encontramos a causa raiz disso. Tivemos um acceptCount de 25 no nosso tomcat server.xml.

acceptCount é documentado assim:

acceptCount

The maximum queue length for incoming connection requests when all possible request processing threads are in use. Any requests received when the queue is full will be refused. The default value is 100.

Mas esta não é a história completa sobre o acceptCount. Short: acceptCount é o parâmetro do backlog ao abrir o socket. Portanto, esse valor é importante para o backlog de escuta, mesmo que nem todos os threads estejam ocupados. É importante que a solicitação seja mais rápida, em seguida, o tomcat pode aceitá-la e delegá-la a threads em espera. O acceptCount padrão é 100. Esse ainda é um valor pequeno para alimentar um pico repentino nas solicitações.

Verificamos a mesma coisa com apache e nginx e tivemos a mesma perda estranha de pacotes, mas com valores de concorrência mais altos. O valor correspondente no apache é ListenBacklog, cujo padrão é 511.

MAS, com o debian (e outro sistema operacional baseado em linux), o valor máximo padrão para o parâmetro de backlog é 128.

$ sysctl -a | grep somaxc
net.core.somaxconn = 128

Assim, o que você digitar em acceptCount ou ListenBacklog não será mais de 128 até que você altere net.core.somaxconn

Para um servidor web muito ocupado, 128 não é suficiente. Você deve alterá-lo para algo como 500, 1000 ou 3000, dependendo de suas necessidades.

Depois de definir acceptCount como 1000 e net.core.somaxconn como 1000, não mais tivemos esses pacotes descartados. (Agora temos um gargalo em outro lugar, mas isso é outra história ..)

    

Answer 2

200ms é o tempo limite de retransmissão TCP padrão (RTO; descrito em RFC2988 , embora não com esse valor mínimo definido).

Então ... algo está sendo atrasado ou perdido de tal forma que o RTO está sendo atingido. Talvez o pacote tenha sido atrasado de tal forma que o RTO foi acionado, mas o wireshark suavizou durante a dissecação / renderização de pacotes? Você deve investigar o rastreamento em mais detalhes.

Você pode fornecer uma imagem maior da sua captura de pacotes?