Erro de rede com 65k de conexões TIME_WAIT

Question

Tivemos alguns problemas com um dos nossos servidores de imagem na semana passada e precisamos de ajuda. Veja nosso gráfico de monitoramento munin:

Estamos executando o debian squeeze e temos muitas solicitações porque esse é um dos nossos servidores de imagem. Nós não usamos keep-alive (talvez devêssemos, mas isso é outro tópico)

Esses números são contagens de solicitações por minuto de nossos arquivos de registro:

• 17:19: 66516
• 17:20: 64627
• 17:21: 123365
• 17:22: 111207
• 17:23: 58257
• 17:24: 17710
• ... e assim por diante

Como você vê, temos muitas solicitações por minuto, mas como a maioria das solicitações é veiculada em 0 a 1 ms, tudo funciona normalmente.

Agora, como você vê no nosso munin graphic, o munin não conseguiu se conectar a este servidor na porta munin e perguntar os números relevantes. A conexão simplesmente falhou. Como o servidor não está sobrecarregado por qualquer meio (cpu, memória, rede). deve ter algo a ver com nossa pilha de firewall / tcp. No momento em que o plug-in do Munin falhou ao conectar, tínhamos apenas 17MBit de tráfego de entrada e saída em uma conexão de 100MBit.

muitas vezes você tem aqui um limite de 65k de conexões tcp, mas isso normalmente é enganoso, já que se refere ao cabeçalho tcp de 16bit e pertence a 65k por combinação ip / port.

nosso tempo limite de time_wait está definido como

 net.ipv4.tcp_fin_timeout = 60

poderíamos diminuir isso para derrubar mais conexões TIME_WAIT antes, mas primeiro eu quero saber o que limita a rede de estar acessível.

estamos usando o iptables com o módulo de estado. Mas nós já levantamos o parâmetro max_conntrack.

 net.ipv4.netfilter.ip_conntrack_max = 524288

alguém sabe quais parâmetros do kernel analisar ou como diagnosticar esse problema na próxima semana quando tivermos a próxima espiada?

    

Answer 1

Ok, eu encontrei a resposta por mim mesmo. O plugin munin está sendo executado muito lentamente e está atingindo seu próprio valor de tempo limite. se a tabela conntrack estiver com leitura completa de / proc / net / ip_conntrack fica muito lenta. o servidor parece estar responsivo enquanto o plugin munin não é.

    

Answer 2

FIN_WAIT (tempo limite para o reconhecimento da solicitação FIN) não é o mesmo que TIME_WAIT (tempo para garantir que o soquete não seja mais usado). E sim, com 65k portas no estado TIME_WAIT, você só estará ficando sem portas TCP se estiver usando um único IP solicitante - como pode ser o caso se todos os seus clientes estiverem atrás de um dispositivo NAT. Você também pode estar executando recursos devido a uma tabela de blocos de controle de transmissão excessivamente povoada - veja este excelente mesmo que seja um pouco documento datado para possíveis implicações de desempenho.

Se você estiver realmente preocupado com seus soquetes no estado TIME_WAIT e não tiver firewalls com informações de estado entre seus clientes e seu servidor, considere configurar / proc / sys / net / ipv4 / tcp_tw_recycle, mas você sacrificará a conformidade com RFC e poderá tem efeitos colaterais interessantes no futuro devido a esse assunto.