Como diagnosticar um grande número de conexões TIME_WAIT

Question

Temos um problema de produção com apenas um de nossos servidores e correlacionamos desempenho lento a uma abundância de soquetes no estado TIME_WAIT . Sem desenhar essa questão em um enorme backstory, nós basicamente sabemos que toda vez que o servidor está lento, cerca de 80% dos soquetes do servidor estão nesse estado TIME_WAIT , o que obviamente vemos rodando um netstat ). Especificamente, como TIME_WAIT expira e desaparece, quando nosso servidor está lento, vemos esses TIME_WAIT s aparecerem com muita frequência (cerca de 5 a 10 minutos).

Eu explodi um pouco e vi que TIME_WAIT s ocorre quando o servidor fecha uma conexão ativa, mas a mantém no caso de qualquer pacote atrasado passar. Eventualmente TIME_WAIT expira.

De qualquer forma, para ver exatamente por que um soquete individual entrou no estado TIME_WAIT para começar? Este é o CentOS 5 - o Linux registra esta informação em var/logs em qualquer lugar, ou existe alguma maneira de fazer um tcpdump e procurar um padrão específico que leve a um TIME_WAIT ? Agradecemos antecipadamente.

    

Answer 1

Resposta curta - é devido a um aplicativo. O aplicativo cria soquetes por um curto período de tempo, fecha-os e, em seguida, ele precisa abrir imediatamente outro soquete. A lentidão está relacionada com o (s) processo (s) ficando sem soquetes para usar.

Ao criar um soquete, há opções - SO_REUSEADDR abnd SO_REUSEPORT. Eles têm funções parecidas, mas eu suspeito que no Centos 5 SO_REUSEPORT não esteja disponível. De qualquer forma, a configuração opcional em uma chamada de soquete permite que a porta seja imediatamente reutilizada.

Portanto, uma correção comumente usada é recodificar. É provavelmente um aplicativo de rede que se conecta por alguns segundos e termina a sessão.

    

Answer 2

Define propriedades para o socket, então elas são permitidas / aplicadas pelo kernel.

1. SO_REUSEADDR é uma opção compatível com POSIX ao criar um soquete.

link

2. resposta curta - sim e sim. Portanto, se você estiver fazendo conexões muito lentas com um escritório remoto solitário na DSL lenta, pode haver um problema com os pacotes "tardios". Mas se estas são conexões em sua LAN, provavelmente não.

3. Um dos seus aplicativos precisa estar abrindo soquetes por atacado e depois fechando-os. lsof mostrará o que pid tem um soquete aberto. De lá você pode derivar usuário e o que está sendo executado. Pode ser algo tão simples quanto um script de shell bash abusando do netcat, por exemplo.

Linha de fundo: É um abuso de recursos de rede ou um problema de código. E você tem um aplicativo de rede - este está comendo seu sistema. Minha definição de aplicativo líquido significa 'usando soquetes TCP / UDP'. Não necessariamente um servidor da Web.