Servidor lento ou com perda de pacotes? Aprenda a diagnosticar com mtr, traceroute e iperf3, interpretar o resultado e o que enviar no ticket.

Para que serve

"O servidor está lento" pode ser rede, disco, CPU ou a própria aplicação. Este artigo ajuda você a separar um problema de rede dos demais, medir latência, perda de pacotes e banda com ferramentas padrão, e montar um ticket com as evidências que permitem ao suporte agir rápido.

Pré-requisitos

  • Acesso root ao servidor (ou administrador no Windows).
  • Uma segunda máquina para comparar: o computador de quem reclama da lentidão, outro servidor ou uma VM em outro provedor.
  • Ferramentas no Debian/Ubuntu/Proxmox: apt install mtr-tiny iperf3 ethtool traceroute

Como diagnosticar perda de pacotes e lentidão passo a passo

1. Descarte causas locais

Antes de culpar a rede, verifique o próprio servidor (veja também o artigo «Servidor Linux lento? Comandos essenciais de diagnóstico (top, htop, iotop, vmstat, ss, free, dmesg)»):

uptime                      # carga alta?
top                         # CPU em 100% ou alto %wa (espera de disco)?
free -h                     # falta de memória / uso de swap?
ip -s link show eno1        # erros, drops e overruns na interface
ethtool eno1 | grep -E 'Speed|Duplex|Link detected'

O esperado é Speed: 1000Mb/s, Duplex: Full e contadores de erro (errors, dropped) zerados ou parados. Rode o ip -s link duas vezes com alguns minutos de intervalo: o que importa é se os números estão crescendo. Em um host Proxmox, faça a verificação no host e não só dentro da VM.

Se você usa todo o uplink de 1 Gbps (backup, réplica, download grande), a lentidão em outros serviços pode ser só saturação. Confira o tráfego em tempo real com apt install nload e nload eno1.

2. Meça o caminho com mtr

O mtr combina ping e traceroute e mostra perda e latência em cada salto. Rode nos dois sentidos: do servidor para o cliente e do cliente para o servidor, pois a rota de ida e a de volta costumam ser diferentes.

# do servidor para o destino (IP do cliente, por exemplo), 100 ciclos, modo relatório
mtr -rwbz -c 100 IP_DO_DESTINO

# mesmo teste usando TCP na porta 443 (útil quando ICMP é filtrado no caminho)
mtr -rwbz -c 100 -T -P 443 IP_DO_DESTINO

# IPv6
mtr -6 -rwbz -c 100 IPV6_DO_DESTINO

Opções: -r relatório, -w nomes completos, -b mostra IP e nome, -z mostra o sistema autônomo (AS) de cada salto, -c quantidade de ciclos.

No Windows, o equivalente nativo é o pathping IP_DO_DESTINO (demora alguns minutos) ou o WinMTR.

3. Interprete o resultado do mtr

  • Olhe primeiro o último salto. Se o destino final tem 0% de perda, não há perda real, mesmo que saltos intermediários mostrem 30% ou 50%. Muitos roteadores limitam respostas ICMP destinadas a eles próprios, mas encaminham o tráfego normalmente.
  • Perda real começa em um salto e continua em todos os seguintes até o destino.
  • Latência que sobe em um salto e se mantém alta nos seguintes indica o trecho do problema. Um pico isolado em um salto intermediário, que não se repete adiante, geralmente não importa.
  • Compare a coluna Avg com a StDev: desvio alto significa jitter, que afeta VoIP, RDP e jogos mais do que a latência média.
  • Perda a partir do primeiro salto, nos dois sentidos, com a interface do servidor sem erros, é um bom indício de problema na entrada da rede. Inclua isso no ticket.

4. Meça a banda com iperf3

O iperf3 mede a vazão real entre duas máquinas suas. Ele precisa de um lado servidor e um lado cliente.

Atenção: o teste consome toda a banda disponível enquanto roda e afeta os serviços em produção. Faça em horário de menor uso, por no máximo 30 segundos, e feche a porta 5201 ao terminar.
# no seu servidor dedicado (lado servidor), libere a porta 5201/TCP temporariamente
iperf3 -s

# na outra máquina (lado cliente)
iperf3 -c IP_DO_SERVIDOR -t 30            # cliente envia (upload até o servidor)
iperf3 -c IP_DO_SERVIDOR -t 30 -R         # servidor envia (download do servidor)
iperf3 -c IP_DO_SERVIDOR -t 30 -P 4       # 4 fluxos paralelos
iperf3 -c IP_DO_SERVIDOR -t 30 --bidir    # os dois sentidos ao mesmo tempo

Encerre o servidor com Ctrl+C depois do teste.

Como ler: em um uplink de 1 Gbps, o máximo prático em TCP fica perto de 940 Mbit/s, por causa do overhead dos cabeçalhos. O resultado depende também da conexão da outra ponta: testar a partir de uma internet residencial de 300 Mbit/s nunca vai passar de 300 Mbit/s. Se um fluxo único fica bem abaixo, mas -P 4 chega perto do máximo, a limitação está na latência e na janela TCP de cada conexão (comum em distâncias longas), não na capacidade do link. Na saída, a coluna Retr (retransmissões) alta indica perda no caminho.

5. Teste a aplicação, não só a rede

Se mtr e iperf3 estão bons e a lentidão continua, o gargalo provavelmente está no servidor ou na aplicação. Meça o tempo de resposta de um site separado por etapa:

curl -o /dev/null -s -w 'dns:%{time_namelookup} conexao:%{time_connect} tls:%{time_appconnect} primeiro_byte:%{time_starttransfer} total:%{time_total}\n' https://seu-site.com.br/

Conexão rápida com primeiro_byte alto indica demora no processamento (PHP, banco de dados, disco), não na rede.

Como saber se funcionou

  • Você consegue dizer em qual camada está o problema: servidor (CPU, memória, disco), interface (erros), caminho de rede (mtr) ou banda (iperf3).
  • Os resultados são reproduzíveis: rodar o mesmo teste de novo, no mesmo horário, mostra o mesmo padrão.

O que enviar no ticket

Um ticket com evidências é resolvido muito mais rápido. Inclua:

  1. IP do servidor afetado e, se for uma VM, se o problema também ocorre no host.
  2. IP público de onde o problema é percebido (cliente, filial, escritório) e a operadora de internet dessa ponta.
  3. Data, hora e duração do problema. É contínuo ou em horários específicos?
  4. Saída completa do mtr -rwbz -c 100 nos dois sentidos, colada como texto, não como print.
  5. Resultado do iperf3, informando de onde para onde e com quais opções.
  6. Saída de ip -s link show e ethtool da interface.
  7. O que já foi testado e descartado.

Problemas comuns

  • mtr mostra só ??? em vários saltos: esses roteadores não respondem ICMP. Não é problema se o destino responde. Tente o modo TCP (-T -P 443).
  • iperf3: error - unable to connect to server: a porta 5201 está fechada no firewall do servidor ou do Proxmox.
  • Velocidade boa no host e ruim na VM: confira se a placa de rede da VM é VirtIO e não um modelo emulado (e1000, rtl8139), e se a VM tem CPU suficiente.
  • Interface negociando 100Mb/s: abra um ticket com a saída do ethtool; pode ser cabo ou porta.

Perguntas frequentes

Perda de pacotes em um salto intermediário do mtr é problema?

Normalmente não. Se o destino final mostra 0% de perda, o roteador do meio só está limitando respostas ICMP para ele mesmo. Perda real começa em um salto e continua até o destino.

Qual a velocidade máxima esperada em um link de 1 Gbps?

Em TCP, perto de 940 Mbit/s no iperf3, por causa do overhead dos cabeçalhos. O resultado também depende da conexão da outra ponta.

Qual a diferença entre latência e jitter?

Latência é o tempo médio de ida e volta; jitter é a variação desse tempo (coluna StDev do mtr). Jitter alto atrapalha VoIP e RDP mesmo com latência média boa. Veja também o artigo «Latência, largura de banda e tráfego: qual a diferença e como medir».

Como testar perda de pacotes no Windows?

Use o pathping, que vem no Windows, ou o WinMTR. Rode o teste também no sentido contrário, do servidor para a sua máquina.

O que enviar no ticket sobre lentidão de rede?

IP do servidor, IP e operadora de onde o problema é percebido, data e hora, saída do mtr nos dois sentidos em texto, resultado do iperf3 e o que já foi descartado.

Precisa de ajuda?

Juntou as evidências e o problema aponta para a rede? Abra um ticket com os itens da lista acima.

Esta resposta lhe foi útil? 0 Usuários acharam útil (0 Votos)

Leia também