Que vhost está sendo SIGKILL'ed no Apache 2.2 / PHP 5.3.3?

Question

Eu tenho um servidor Linux com 16GB de RAM e 8 núcleos. Ele nunca entra em swap e o uso da CPU nunca excede ~ 1.5. Eu acredito que é seguro dizer que há muita capacidade.

Ocasionalmente obtenho alguns [warn] mod_fcgid: process 28341 graceful kill fail, sending SIGKILL .

No Apache / 2.2.15 (CentOS 6.3) mod_fcgid / 2.3.7, todas as configurações de mod_fcgid abaixo não estão presentes, portanto padrão:

FcgidMinProcessesPerClass
FcgidMaxProcessesPerClass
FcgidMaxProcesses
FcgidIdleTimeout
FcgidProcessLifeTime
FcgidIdleScanInterval
FcgidOutputBufferSize

Eu quero identificar em qual vhost os processos estão recebendo o SIGKILLed. Então eu carreguei mod_status e transformou ExtendedStatus ON. Eu defino log_server_status para ser executado a cada minuto, pois não posso recarregar manualmente o / servidor -status / page e ao mesmo tempo, fique de olho nos logs, o dia todo, esperando que um SIGKILL aconteça.

Mas a saída de log_server_status não é muito útil. Isso é tudo que vejo nos logs criados pelo script:

180131::::
all the way to
235501::::
235601::::
235701::::
235801::::
235901::::

Eu quero rastrear os vhosts responsáveis pelo SIGKILL. Como faço para isso? Estou fazendo algo errado com relação ao log_server_status? A saída parece inútil ...

    

Answer 1

Eu tive que vasculhar manualmente os logs de erro do apache, diariamente, para as entradas que ocorreram ao mesmo tempo em que as mensagens SIGKILL estavam sendo registradas no syslog. Isso permitiu que os processos dos vhosts estivessem sendo SIGKILLED. Comecei a monitorar (manualmente) quais arquivos estavam sendo acessados nos timestamps nesses vhosts e depois de alguns dias eu tinha dados suficientes para rastrear quais arquivos php estavam gerando erros.

O problema está resolvido e não recebo mais avisos SIGKILL.

Como uma nota secundária, que se aplica somente ao meu caso específico: os avisos vieram de entradas do cron do magento que não puderam terminar dentro do tempo máximo permitido para a execução do script. Então eu aumentei o tempo de execução para 180 (por alguns dias) e essas tarefas do cron começaram a terminar com sucesso. Eu reduzi o tempo máximo permitido e agora eles podem terminar em menos de 60 segundos. O longo tempo de execução foi porque alguns trabalhos não eram executados há muito tempo e eles tinham uma carga maior do que o normal para lidar.

    

Answer 2

Você parece estar executando o PHP através de mod_fcgid . Desde que o mesmo wrapper seja usado para iniciar o interpretador PHP para todos os vhosts, os processos gerados por mod_fcgid são usados como você parece não ter diretivas específicas de vhost para o fcgid. Eles permanecem em execução após a inicialização e são reutilizados para executar qualquer código PHP que é passado para eles para processamento (que é o próprio sal de mod_fcgid BTW). Consulte a mod_fcgid documentação para detalhes.

Existe um bug documentado quebrando esse comportamento e levando a uma situação em que processos PHP podem ser gerado para cada vhost desconsiderando quaisquer limites definidos por classe sob certas condições, mas este bug só se aplica à versão antiga do módulo 2.3.6, é um comportamento indesejado e foi corrigido no 2.3.7.

Além disso, os avisos de log que você está vendo não são devidos ao esgotamento de recursos, isso é atividade normal de mod_fcgid . mod_fcgid encerra os processos em execução periodicamente (seja após um tempo limite ocioso, uma determinada duração ou após um determinado número de solicitações). A terminação acontece enviando um SIGTERM ao processo. Se o processo não for capaz de lidar com o SIGTERM a tempo por algum motivo (pode estar muito ocupado, mas também pode estar apenas capturando e ignorando solicitações SIGTERM), ele é encerrado à força por um SIGKILL - é sobre isso que o aviso se refere.

Se você não estiver satisfeito com o tempo de término do processo, basta ajustar os respectivos parâmetros com o FcgidIdleTimeout , FcgidProcessLifetime e FcgidMaxRequestsPerProcess .