Já experimentou outro otimizador ou tentou usar o apc.filter? Isso realmente soa como um problema relacionado ao APC porque a estabilidade do APC sempre depende do código usado e da configuração do apc.
Estou executando o Drupal 6 com Nginx 1.5.1 e PHP-FPM (PHP 5.3.26) em um VPS de 1 GB de um único núcleo com 3 GB de espaço de troca no armazenamento SSD. Acabei de mudar de hospedagem compartilhada para este VPS não gerenciado porque meu site estava ficando pesado demais, então ainda estou aprendendo as coisas. Eu tenho tráfego moderadamente alto, eu realmente não monito de perto, mas o Google Adsense geralmente registra perto de 30 mil page views / dia. Eu normalmente tenho 50 a 80 usuários autenticados conectados e algumas centenas de usuários anônimos acessando o cache HTML estático do Boost a qualquer momento.
O problema que estou tendo é que o PHP-FPM freqüentemente para de responder, resultando em erros Nginx 502 ou 504. Eu juro que li todas as páginas na internet sobre esse problema, o que parece bastante comum, e eu tentei combinações infinitas de configurações, e não consigo encontrar uma boa solução. Depois de reiniciar o Nginx e o PHP-FPM, o site é executado muito rápido por um tempo e, em seguida, sem aviso, ele simplesmente pára de responder. Eu recebo uma tela branca enquanto o navegador aguarda no servidor, e depois de cerca de 30 segundos a um minuto, ele gera um erro Nginx 502 ou 504. Às vezes funciona bem por 2 minutos, às vezes 5 minutos, às vezes 5 horas, mas sempre acaba pendendo. Quando encontro o servidor neste estado, ainda há bastante memória livre (> 500MB ou mais) e não há grande uso de CPU, os processos de controle e de trabalho do PHP-FPM ainda estão presentes, e o servidor ainda pode ser usado SSH. Um recarregamento do PHP-FPM através do script init revive-o novamente. Os bloqueios não parecem corresponder à quantidade de tráfego, porque observei esse comportamento consistentemente quando estava testando essa configuração em um VPS de desenvolvimento sem nenhum tráfego.
Eu tenho modificado constantemente as configurações, mas não posso eliminar definitivamente o problema. Eu configurei os trabalhadores do Nginx para apenas 1. Na configuração do PHP-FPM, eu tentei todos os três gerenciadores de processo. "Dinâmico" é definitivamente o menos confiável, desligando consistentemente depois de apenas alguns minutos. "Static" também não foi confiável e imprevisível. O menos buggy foi "ondemand", mas mesmo isso está falhando comigo, às vezes depois de 12 a 24 horas. Mas não posso deixar o servidor desacompanhado porque o PHP-FPM morre e nunca volta sozinho. Eu tentei ajustar o valor de pm.max_children de tão baixo quanto 3 para 50, não faz muita diferença, mas atualmente eu tenho isso em 10. Mesma coisa para os valores de servidores de reserva. Eu também defini pm.max_requests em qualquer lugar de 30 a ilimitado, e isso não parece fazer diferença.
Eu também tenho usado o armazenamento em cache do APC e do Redis para tirar parte da carga do banco de dados, mas o problema do PHP-FPM existe com e sem esses mecanismos ativados.
De acordo com os logs, os processos PHP-FPM não estão saindo com SIGSEGV ou SIGBUS, mas sim com SIGTERM. Eu recebo muitas linhas como:
WARNING: [pool www] child 3739, script '/var/www/drupal6/index.php' (request: "GET /index.php") execution timed out (38.739494 sec), terminating
e:
WARNING: [pool www] child 3738 exited on signal 15 (SIGTERM) after 50.004380 seconds from start
Na verdade, eu encontrei vários artigos que recomendam fazer um recarregamento do PHP-FPM através do cron a cada poucos minutos ou horas para contornar esse problema. Então foi o que eu fiz, "/etc/init.d/php-fpm reload" a cada 5 minutos. Até agora, está mantendo as luzes acesas. Mas parece um horrível hack. O PHP-FPM é realmente tão pouco confiável? Há algo mais que eu possa fazer? Muito obrigado!
Veio aqui pesquisando no Google, compartilhando alguma experiência.
Tive o mesmo problema, mas no Drupal 7! (desculpe @michael Hampton ;-) O Drupal 6 está rodando bem no mesmo VPS (2048 MB, 2 × 2.4Ghz@60%, NGINX, APC). Drupal 7 ficar preso depois de ~ 4 horas, como um engarrafamento ou algo assim ;-) Por duas semanas eu estou tentando e procurando diferentes opções.
Parece que, finalmente, a desativação da APC resolveu o problema. Antes (APC on), CRON no Drupal deu um erro no slowlog. Sem o APC, o site parece um pouco mais rápido.