Estranhas latências de conexão tcp de 3 segundos (Linux, HTTP)

Question

Nossos servidores Web com conteúdo estático estão experimentando latências estranhas de 3 segundos ocasionalmente. Normalmente, uma execução do ApacheBench (> 10000 solicitações, simultaneidade 1 ou 40, sem diferença, mas sem atividade) é assim:

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2   10 152.8      3    3015
Processing:     2    8  34.7      3     663
Waiting:        2    8  34.7      3     663
Total:          4   19 157.2      6    3222

Percentage of the requests served within a certain time (ms)
  50%      6
  66%      7
  75%      7
  80%      7
  90%      9
  95%     11
  98%    223
  99%    225
 100%   3222 (longest request)

Eu tentei muitas coisas: - Apache2 2.2.9 com MPM worker ou prefork, sem diferença (com KeepAliveTimeout 10-15) - Nginx 0,6.32 - vários parâmetros tcp (net.core.somaxconn = 3000, net.ipv4.tcp_sack = 0, net.ipv4.tcp_dsack = 0) - colocando os arquivos / DocumentRoot no tmpfs - shorewall ligado ou desligado (ou seja, iptables vazias ou não) - AllowOverride None está ativado para /, portanto, nenhuma verificação de .htaccess (verificada com strace) - o problema persiste se os servidores web são acessados diretamente ou através de um balanceador de carga Foundry

O kernel é 2.6.32 (backports do Debian Lenny), mas também ocorreu com o 2.6.26. O IPv6 está ativado, mas não usado.

O problema parece familiar para alguém? Ajuda / sugestões são muito apreciadas. Soa um pouco como um pacote SYN, ACK sendo perdido ou ignorado.

    

Answer 1

Capture este evento com o tcpdump / Wireshark / tshark. Em seguida, abra a captura no Wireshark, vá para Estatísticas- > gráfico de fluxo TCP- > Gráfico de seqüência temporal (Stevens).

Isso faz com que você tenha um gráfico de números sequenciais x tempo. Se você tem uma lacuna de 3 segundos nas suas conexões, você deve ser capaz de identificá-lo, já que não deve haver pontos para os 3 segundos no eixo x entre dois densos agrupamentos de pontos. Clique no último ponto no lado esquerdo da lacuna. Isso leva você ao quadro antes que a lacuna ocorra. Geralmente esse é o único pacote contendo o problema. Você pode ver o pacote de janela zero, pacote faltando, entrega fora de ordem, dups, etc ...

    

Answer 2

Verifique se o seu servidor DNS está lento e defina seus arquivos de log do Apache para que eles registrem por IP e não pelo nome de domínio. Se você não alterar a configuração do arquivo de log padrão, toda vez que receber uma solicitação, o agente de log precisará fazer uma pesquisa de DNS.

    

Answer 3

Isso pode ser causado por bloqueios de E / S de muitas maneiras interessantes. Para começar, tente isolar o problema. O problema é o servidor / rede, ou é o serviço? Você pode replicar o problema com ping / tcpping?

Se é um problema em que todo o servidor trava por alguns segundos.

1. Os discos rígidos estão definidos para reduzir a inatividade? Se você receber uma falha de página em um HD que esteja desativado, o sistema poderá levar segundos para ser recuperado. De qualquer forma, considere se livrar do swap.

2. Pode ser um problema de baixo nível com a rede. Eu tenho visto um comportamento semelhante com conexões raras e lentas quando um Switch ficou sem espaço na tabela de endereços MAC. Faça alguns rastreios de pacotes e veja se consegue ver algo mais que pareça relacionado na rede.

3. Também pode ser um problema de hardware com o servidor, como um barramento que é bloqueado e recuperado após alguns segundos. Verifique seus registros.

Se parece ser apenas o Apache:

1. As pesquisas de DNS seriam um culpado comum, mas você parece ter essa cobertura.

2. Tente implantar um servidor completamente diferente (como lighttp) e veja se isso ajuda a resolver o problema. Então você pode começar a suspeitar de algo em sua configuração do Apache.

Answer 4

Soa como um problema com o estabelecimento da conexão TCP, ou seja, um SYN perdido, ACK, exatamente como você sugere.

3 segundos é o primeiro tempo limite padrão para TCP SYN, ACK no Linux. É improvável que seja um aplicativo (servidor da Web) relacionado, pois o estabelecimento da conexão é tratado pelo kernel.

Como afeta menos de 1% das conexões, algumas coisas podem ser:

• perda de pacotes se em uma WAN (1% de perda de pacotes não é ouvida em alguns tipos de WAN),
• NIC configurada incorretamente (use o ethtool para investigar e confirmar duplexing, autoneg, etc),
• uma falha no cabo (não faz mal tentar trocar o cabo),
• um bug do kernel (que você parece ter eliminado).

Eu tive isso recentemente em um servidor e acabou sendo o segundo acima: NIC configurada incorretamente, que tinha sido forçada para as configurações erradas de velocidade e duplex. Eu reconfigurei para negociar automaticamente com ethtool e não olhei para trás.