servidor web apache não responde com status do servidor, mostrando todos os processos filhos aguardando conexão [fechado]


10

Minha configuração: tenho três máquinas de servidor da web quase idênticas, que atendem ao mesmo site dinâmico carregado com um simples balanceamento de carga sobre o DNS. O serviço trabalha há mais de dois anos com a mesma configuração do apache: apache2, php5, ubuntu 8.04 linux 2.6.24-29-server.

Meu problema: há cerca de duas semanas, estou tendo problemas com esta configuração. Quase todos os dias, tenho um pequeno momento por cerca de 5 minutos, no qual o site é inacessível. Ainda consigo fazer login nos servidores pelo ssh. Se eu correr htop, vejo a máquina simplesmente não fazendo nada. Eu tenho cerca de 1000 processos apache em execução, mas nenhuma atividade da CPU.

Eu usei o apache mod_status para depurar essa situação. O placar do processo é assim:

_C.___K_______________________R._______.__K_K____K___C_______.__
_______C__________.___________________________________.________C
_.____K__________K___K_WK_____._K_____________________________._
W______K__________K________.____________________._______C_______
_C_.__K__K____.._.._____________________________________C_______
_R___________K___.______C________.C_________.______._____C______
____________KKC____K_____K__WC_________________C_____.__.____.__
_____________________C_________K______.____C______._____________
_.___C____.___.___________________________.K______.____K________
W__.___________________C.__.____K________K_______R_._.__._______
__C__C_.__________C__C_______._____W______________C_.___C_______
____.______C_____________C________.____C____________.________._K
__.__________.K_____________K_________._____C____.K__________KW_
__K.W________R_________._______.___W___________.____.__K_____W__
W___.___..________W____K

Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"C" Closing connection, "L" Logging, "G" Gracefully finishing,
"I" Idle cleanup of worker, "." Open slot with no current process

Portanto, a maioria dos processos está apenas aguardando conexão. Após cerca de 5 minutos, a situação voltará ao normal: eu tenho muito menos processos em todas as máquinas, a maioria dos trabalhadores tem o status "." (porque eles estão abertos para processar uma solicitação) e, é claro, o site é acessível!

Então, eu estou tentando encontrar algo nos logs, mas simplesmente não há nada ... o log de acesso do apache fica em silêncio por cerca de 4 minutos, o mesmo é para o log de erros. Eu também não consigo descobrir nada de errado em outros logs do sistema.

a situação é a mesma em todos os três servidores da web (todos eles têm esse pico de carga e condição sem resposta ao mesmo tempo), então não acho que isso esteja relacionado ao hardware. mas acho que isso pode estar relacionado a algum problema de rede (tcp).

alguma ideia?

EDIT: mais algumas informações, que acabei de descobrir:

Acabou de acontecer novamente e pude verificar que também não consigo conectar localmente quando esse problema ocorre.

Fiz algumas estatísticas de conexão com o seguinte comando depois que aconteceu: netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

  • 109 CLOSE_WAIT
  • 2652 ESTABELECIDO
  • 2 FIN_WAIT1
  • 11 LAST_ACK
  • 12 OUVIR
  • 91 SYN_RECV
  • 1 SYN_SENT
  • 16 TIME_WAIT

Se eu executar o mesmo comando algum tempo depois, tenho algo parecido com isto:

  • 4 ENCERRAMENTO
  • 108 ESTABELECIDO
  • 18 FIN_WAIT1
  • 182 FIN_WAIT2
  • 37 LAST_ACK
  • 12 OUVIR
  • 50 SYN_RECV
  • 11276 TIME_WAIT

Portanto, na situação normal, tenho apenas 100-200 conexões abertas de clientes sendo manipuladas pelo apache neste momento. Quando tenho esse "travamento", tenho muito mais conexões. Qual é a melhor maneira de analisar isso?

EDIT2: as linhas importantes no apache2.conf são:

KeepAlive On
MaxKeepAliveRequests 20
KeepAliveTimeout 1
<IfModule mpm_prefork_module>
ServerLimit           920
StartServers          30
MinSpareServers       80
MaxSpareServers      120
MaxClients          920
MaxRequestsPerChild   700
</IfModule>

É um prefork do apache2 com php_mod.

O servidor possui 8 GB de RAM e uma partição de swap de 4 GB.


O site mostra os mesmos sintomas quando você executa um wget ou enrola do host local ou entre servidores (se estiverem na mesma rede)?
Alex Forbes

Talvez um dump de tráfego ( tcpdump) o ajude a chegar à raiz do problema ... entre as políticas de firewall e uso de memória?
drcelus

@ al4 a última vez que isso aconteceu, consegui me conectar à página de status do servidor a partir do host local, enquanto não consegui me conectar à página da Web de fora. não tenho muita certeza, pois também pode ser uma coisa aleatória, enquanto alguns dos trabalhadores se tornam disponíveis. testarei isso mais na próxima vez que o problema ocorrer. qual seria sua sugestão, se eu pudesse confirmar alguma diferença entre conexões externas e locais?
Jeff

Se você pode confirmar que funciona localmente, mas não de fora, reforça o argumento de que a rede é o problema - o que significa que você deve testar com tcpdumps e wireshark nas duas extremidades para ver o que está passando, em vez de rastrear os processos apache. Eu também testaria de um host na mesma LAN, se possível. E verifique o dmesg para ver se há alguma mensagem que possa estar relacionada, mas parece que você já fez isso.
Alex Forbes

acabou de acontecer novamente. e pude verificar que também não consigo conectar localmente quando esse problema ocorre. Eu também fiz algumas estatísticas de conexão com o netstat: veja o texto da pergunta
Jeff

Respostas:



1

Primeiro: verifique seu Max open fileslimite no processo. Uma conexão de soquete ativa conta como um arquivo aberto. cat /proc/###/limitsé uma boa maneira de verificar o valor efetivo de outro processo. Você pode obter uma lista de arquivos abertos com lsof -p ###onde ### é o ID do processo do seu servidor da web. Você pode comparar lsof -p ### | wc -lpara ver o quão perto está do limite. Você também deve ver mensagens no error_log do apache se estiver atingindo o limite.

Você precisa de um identificador de arquivo para cada conexão de soquete e também para cada script cgi ou referência de arquivo de dados. Para o 920 MaxClients, você deve configurar pelo menos 4.000 arquivos para o processo httpd. Você pode aumentar o número de arquivos adicionando um arquivo em /etc/security/limits.d/ com o seguinte conteúdo. Verifique se o nome do usuário corresponde ao que você está usando para o servidor da web.

apache soft nofile 10000
apache hard nofile 10000

Segundo: se a exaustão da porta for o seu problema, você poderá ajustar algumas configurações de ip no /etc/sysctl.conf. (Começando com net.ipv4.tcp_fin_timeout). Isso geralmente é um problema apenas com muitas conexões muito pequenas. Muitos soquetes TIME_WAIT são um indicador disso, mas isso indica exaustão da porta somente quando acompanhada de erros no syslog sobre possible SYN floodinge Sending cookies. Você também deve garantir que seu servidor esteja protegido por um firewall que possa impedir ataques SYN maliciosos.


0

Além disso, lembre-se de que no MPM pré-fork, cada processo terá PHP em seu espaço de memória (qual é a sua configuração de limite de memória?). Você pode tentar mudar para o MPM de trabalho, o que pode exigir um módulo PHP ligeiramente diferente.

Também vale a pena usar brinco remoto para aparar sua configuração do Apache de módulos estranhos

Na minha experiência, essas coisas são acionadas por coisas como um rastreador de mecanismo de pesquisa ou por conflitos de ARP. Ou níveis de tráfego em alguma parte relacionada da rede.

Você pode achar 'sar' útil ... não o mais amigável, mas certamente útil.

Possivelmente também relacionado a io. Sar pode lhe dizer (se você configurá-lo para registrar a atividade do disco), qual é o tempo médio de espera de io. Você também pode observar o tempo de espera de entrada / saída no topo (que é uma porcentagem, leia o que realmente significa). Isso pode ser significativo se você estiver usando uma SAN ou ambiente virtual.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.