Precisa de mais explicações sobre TIME_WAIT

3

Oi Unix / Linux Gurus lá fora!

Eu preciso de uma prova sólida de que TIME_WAIT (na verdade, muito) é o verdadeiro culpado na desaceleração em um de nossos servidores. O servidor está hospedado na virtualização Paralels Baremetal, e o servidor real é uma VM: CentOS5 com CPU dupla e 2 GB de RAM.

Uma semana atrás, começamos a notar que era muito lento que até fazer um 'ls' em um diretório com apenas alguns arquivos (cerca de 20) precisaria de cerca de 1,5 segundos para exibir os resultados.

Eu tentei fazer vmstat , mas não parece estar usando a troca. Nenhum gargalo na rede. Mas executando top , você veria o java basicamente sobrecarregando o recurso. Java é necessário, uma vez que esta VM é o nosso servidor hudson.

Um dos meus colegas tentou verificar as conexões via

$ vmstat -vatpno

E notamos que há muitas conexões em TIME_WAIT ... por volta de 300 +. Por isso, tentamos aplicar algumas das recomendações em esta página , particularmente as de TCP_FIN_TIMEOUT, TCP_KEEPALIVE_INTERVAL & TCP_KEEPALIVE_PROBES. As conexões em TIME_WAIT diminuíram, mas ainda oscilam entre 220 e 280 (talvez devido ao fato de que uma nova conexão é adicionada de tempos em tempos e outras conexões em TIME_WAIT ainda não são "expiradas"). Talvez pudéssemos tentar adicionar TCP_TW_RECYCLE & TCP_TW_REUSE mais tarde, quando não vemos qualquer melhoria.

Agora voltando à minha pergunta principal: há uma evidência sólida de que muitas conexões TIME_WAIT'ed consomem muita RAM?

Obrigado antecipadamente.

    
por icasimpan 26.01.2011 / 07:53

1 resposta

3

Uma conexão no estado TIME_WAIT está simplesmente esperando para ver se algum último pacote de dados disperso atravessa a rede do outro lado, para que eles não se misturem com os pacotes de outra conexão. Não faz qualquer nada com esses pacotes. Então, se alguma coisa, uma conexão TIME_WAIT usa menos recursos do que uma conexão aberta.

Um servidor web bem provisionado nos dias de hoje pode lidar com mais de 10.000 conexões simultâneas (note que isso foi escrito em 2003, e A lei de Moore continua em marcha). Como, no mínimo, uma conexão no estado TIME_WAIT usará menos memória do que uma conexão aberta, 300 conexões em TIME_WAIT não devem ser nada.

Para mais informações sobre TIME_WAIT, consulte link e link .

Enquanto isso, fico imaginando como seu uso de E / S de disco parece. E / S de disco pesado pode desacelerar o kernel do Linux muito mais facilmente do que o uso pesado da CPU, na minha experiência. Talvez você queira pesquisar as ferramentas iostat e dstat e ver o que elas informam.

    
por 01.02.2011 / 07:39

Tags