Rastreamento de erros de “redefinição de conexão” no Linux

Question

Estou lidando com um grande número de downloads simultâneos (aprox. 500 por servidor) usando Java.

Todos os arquivos estão sendo baixados do Amazon S3, e o servidor de download é uma instância do EC2 m1.large.

Ocasionalmente, 2 ou mais streams serão simultaneamente quebrados, resultando em um java.net.SocketException. Ocasionalmente, até 10 dos fluxos podem ser quebrados simultaneamente.

Estou obtendo os mesmos resultados do download dos servidores Amazon S3 e Akamai. Isso só acontece quando a carga começa a ser bastante alta (200 ou mais downloads simultâneos).

Estou bem dentro da CPU normal, carga de rede e limites de memória.

Suspeito que o problema esteja no meu servidor, e não no S3 e no Akamai. Como eu poderia depurar isso e rastrear a causa?

    

Answer 1

Você poderia capturar o tráfego com tcpdump e verificar isso após a quebra das conexões. O Wireshark, por exemplo, possui uma opção "follow TCP stream" que permite isolar facilmente um arquivo quebrado quando você localizar o último pacote.

Pode ainda ser um monte de dados para passar, mas como você está dizendo que isso só acontece quando a carga é bastante alta, eu não acho que haja uma maneira de contornar isso.

Como um começo, você pode dar uma olhada nos erros reportados pela interface de rede (através de ifconfig ) e ver se esse número aumenta significativamente quando as conexões são descartadas.

    

Answer 2

Existe um firewall / NAT no caminho entre você e o S3?

Você poderia simular captura simultânea ( tcpdump -w file -s 0 ) do tráfego em 2 pontos - entre o seu servidor e o firewall, e entre o firewall e o S3, então comparar os dumps? Antes de iniciar o tcpdump, certifique-se de que o relógio seja precisamente sincronizado usando o NTP nos hosts de captura.

Em seguida, compare as duas capturas de rede no momento em que a conexão foi interrompida.

Eu tive um problema indescritível semelhante, e comparando os despejos de tráfego de rede, descobri que era devido ao fato de o SACK estar ativo no meu servidor Linux, mas sendo indevidamente interpretado pelo firewall Cisco ASA que manipulava o tráfego proveniente da Internet. .

Tive que desativar o SACK usando sysctl ( net.ipv4.tcp_sack ).