Como você diagnostica a perda de pacotes?

Question

Eu percebo que isso é muito subjetivo e dependente de várias variáveis, mas eu estou querendo saber a quais passos a maioria das pessoas passa quando precisam diagnosticar a perda de pacotes em um determinado sistema?

    

Answer 1

Eu sou engenheiro de rede, então vou descrever isso da minha perspectiva.

Para mim, diagnosticar a perda de pacotes geralmente começa com "não está funcionando muito bem". De lá, eu normalmente tento encontrar o kit o mais próximo possível de ambas as extremidades da comunicação (normalmente, uma estação de trabalho em um escritório e um servidor em algum lugar) e pingar o mais próximo possível da outra extremidade (idealmente o "ponto final remoto", mas às vezes existem firewalls para os quais não consigo enviar pings, então terão que se contentar com uma interface de LAN em um roteador) e ver se consigo ver alguma perda.

Se eu puder ver a perda, geralmente é um caso de "largura de banda insuficiente" ou "link com problemas" em algum ponto intermediário, para encontrar a rota pela rede e começar do meio, que geralmente dá um fim a você o outro.

Se eu não conseguir ver a perda, os próximos dois passos tendem a ser "enviar mais pings" ou "enviar pings maiores". Se isso não der uma indicação de qual é o problema, é hora de começar a examinar as políticas de QoS e as estatísticas da interface por todo o caminho entre os pontos finais.

Se isso não encontrar nada, é hora de começar a questionar suas suposições, você está realmente sofrendo de perda de pacotes. A única maneira segura de descobrir isso é fazer capturas simultâneas em ambas as extremidades, seja usando WireShark (ou equivalente) nos hosts ou conectando máquinas sniffer (provavelmente usando WireShark ou similar) através de taps de rede. Depois vem a diversão de comparar as duas capturas de pacotes ...

Às vezes, o que é atribuído como "perda de pacotes" é simplesmente algo do lado do servidor sendo visivelmente mais lento (como, por exemplo, movendo o banco de dados de "na mesma LAN" para "20 ms de distância" e usando consultas que exigem uma um monte de idas e vindas entre o front-end e o banco de dados).

    

Answer 2

Do ponto de vista de um sistema Linux, primeiro procurarei a perda de pacotes na interface de rede com ethtool -S ethX .

Na maioria das vezes, aumentar o buffer de anel com ethtool -G ethX rx VALUE resolve isso.

Algumas vezes as interrupções não estão sendo balanceadas porque o sistema está perdendo o serviço irqbalance, então procure em chkconfig (EL) ou update-rc (Debuntu) para ver se este serviço está rodando. Você pode dizer se as interrupções não estão balanceando porque /proc/interrupts mostrará somente o Core 0 atendendo a todos os canais IRQ.

Se isso falhar, talvez seja necessário aumentar net.core.netdev_max_backlog se o sistema estiver passando mais que alguns gigabits de tráfego e talvez net.core.netdev_budget .

Se isso não funcionar, você pode ajustar os valores de coalescência de interrupção com ethtool -C .

Se não houver nenhum pacote descartado na interface de rede, procure em netstat -s e veja se há quedas nos buffers de soquete, que serão reportados com estatísticas como " pruned from receive queue " e " dropped from out-of-order queue ". / p>

Você pode tentar aumentar os buffers de soquete padrão e máximo para o protocolo apropriado (por exemplo: net.ipv4.tcp_rmem para TCP).

Se o aplicativo definir seu próprio tamanho de buffer de soquete, o aplicativo poderá precisar de alterações de configuração. Se o seu aplicativo tiver tamanhos de buffer de soquete codificados, reclame com o fornecedor do aplicativo.

Pessoalmente, eu não gosto de descarregar protocolos em NICs (soma de verificação, offload de segmentação, offload de grande porte), pois parece causar mais problemas do que vale a pena. Brincar com essas configurações usando ethtool -K pode valer a pena.

Veja as opções do módulo para sua NIC ( modinfo <drivername> ), pois você pode precisar alterar alguns recursos. Para dar um exemplo que eu encontrei, usando o Diretor de Fluxo da Intel em um sistema que lida com um grande fluxo TCP provavelmente prejudicará a eficiência desse fluxo, então desligue o FDir.

Além disso, você está ajustando manualmente esse sistema específico para sua carga de trabalho específica, o que, acredito, está além do escopo da sua pergunta.

    

Answer 3

Vou começar usando ferramentas de captura de pacotes como: wireshark (no Windows) e tcpdump (no terminal do Linux).

Também verificarei a configuração do firewall (firewall do host e firewall de rede).

    

Answer 4

Isole e elimine.

Encontre o menor subconjunto de caminhos com o problema. Faça isso testando diferentes combinações e / ou elaborando relatórios de usuários. Não esqueça de fatorar o tempo na equação. Talvez seja apenas perda de pacotes em todo o tráfego para uma rede específica, ou talvez apenas os clientes sem fio estejam sofrendo. Tome diferentes tipos de tráfego em conta (limite de taxa em pings). Encontre a maneira mais confiável e de fácil repetição para testá-lo.

Em seguida, elimine as possíveis causas. Reduza o tráfego nos links (temporariamente), remova as fontes de interferência do espectro, desconecte certos clientes. Eventualmente, você encontrará a fonte do problema.

Você pode, às vezes, tomar atalhos, observando os dumps de pacotes ou adivinhando (é sempre bittorrent). Além disso, diga ao seu professor que falha no servidor é impressionante.