Como NÃO obter tantas conexões apache CLOSE_WAIT?

O netstat mostra que há 153 conexões no status CLOSE_WAIT. As conexões nunca são fechadas. Então, horas extras, o servidor é preenchido com essas conexões que preenchem a RAM e agora os sites não estão carregando.

O netstat mostra muitos como os seguintes:

tcp      160      0 my_server_name:http         my_server_name:51584        CLOSE_WAIT
tcp      160      0 my_server_name:http         my_server_name:51586        CLOSE_WAIT
tcp        0      0 my_server_name:http         my_server_name:50827        CLOSE_WAIT
tcp        0      0 my_server_name:http         my_server_name:50830        CLOSE_WAIT
tcp      312      0 my_server_ip.static.:http rate-limited-proxy-72:61249 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:58663 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:34655 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:56681 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:40829 CLOSE_WAIT
tcp      576      0 my_server_ip.static.:http b3090792.crawl.yahoo.:38278 CLOSE_WAIT
tcp       47      0 my_server_ip.static.:http 203.200.5.143.ill-bgl:49379 CLOSE_WAIT

Se eu olhar o appache error_log, antes que a situação CLOSE_WAIT chegue, existem linhas como as seguintes

[warn] child process 15670 still did not exit, sending a SIGTERM
[error] child process 15670 still did not exit, sending a SIGKILL
[notice] child pid 3511 exit signal Segmentation fault (11)

Minha configuração Apache 2.2.3 RAM 1024 MB (burst 2048 MB) CentOS release 5.3 (Final) executando 2 instalações WPMU 2.9.2

fundo

O soquete entra no estado CLOSE_WAIT quando a extremidade remota termina a conexão enviando um pacote com o sinalizador FIN definido. Em seguida, ele espera nesse estado o aplicativo local para close()o soquete e, em seguida, envia seu próprio FIN ao cliente e faz a transição do soquete para o estado LAST_ACK. Veja também o diagrama de transição de estado TCP e o RFC 793 .

Observe também que CLOSE_WAIT não tem relação com o infame TIME_WAIT, pois o primeiro ocorre na ramificação de fechamento passiva (a extremidade remota fecha primeiro) enquanto o último na ramificação de fechamento ativa (a extremidade local fecha primeiro).

Descrição do Problema

Normalmente, as conexões passam de CLOSE_WAIT para LAST_ASK rapidamente. Se o endereço remoto e a porta continuarem mudando rapidamente, um número razoável de conexões no estado CLOSE_WAIT pode ser simplesmente a conseqüência de um número muito grande de conexões abertas, usadas e fechadas. O desempenho do sistema deve ser examinado, mas por si só isso não constitui um problema.

Se o endereço remoto e a porta mudarem lentamente, isso indica que os processos do aplicativo precisam aguardar a CPU. Nesse caso, as altas médias de carga confirmarão isso.

Se, por outro lado, o endereço e a porta remotos permanecerem constantes e o número de conexões no estado CLOSE_WAIT continuar aumentando, provavelmente indica um problema com o aplicativo. Este é um caso especial do bug de vazamento de recursos: o aplicativo vaza soquetes abertos em vez de fechá-los oportunamente. Isso consome memória do kernel e, eventualmente, fará com que o aplicativo falhe quando atingir o número máximo de descritores de arquivos abertos.

Observe, porém, que o ritmo do vazamento pode ser lento. Geralmente, erros como esse resultam de uma falha no tratamento de uma exceção no meio de uma solicitação, interrompendo o fluxo de execução em um encadeamento de trabalho que pode subsequentemente impedir a limpeza (incluindo o fechamento do soquete). A exceção incorreta pode ocorrer raramente.

Solução temporária

A solução temporária para o problema é aumentar os limites dos descritores de arquivos abertos e reiniciar periodicamente o aplicativo quando (de preferência antes) o problema começa a afetar o desempenho. Observe que isso pode afetar inadvertidamente as conexões abertas no momento. A existência de servidores redundantes e o balanceamento de carga podem ajudar a esconder o problema dos usuários.

Solução permanente

A solução permanente para o problema é implantar a versão do aplicativo sem o bug. O grau em que a solução temporária prejudica os usuários e os negócios, a prontidão da versão corrigida e o estado da última versão de trabalho ajudam a decidir se devem reverter para a última versão de trabalho do aplicativo ou aguardar a correção.