Problema de tempo limite do PHP-FPM todos os dias

Question

Estou executando um servidor dedicado com nginx, PHP-FPM, MySQL e tenho alguns sites em execução, mas estou tendo um problema de tempo limite todos os dias, praticamente a cada 24 horas a partir do site que está executando o WordPress.

Erro no PHP-FPM:

[14-Jan-2012 04:00:48] WARNING: [pool www] child 2759, script '/home/fez/www/index.php' (request: "GET /index.php") execution timed out (73.614398 sec), terminating
[14-Jan-2012 04:00:48] WARNING: [pool www] child 2759 exited on signal 15 (SIGTERM) after 114278.396462 seconds from start 

erro nginx:

2012/01/14 04:00:48 [error] 1629#0: *859825 upstream timed out (110: Connection timed out) while reading upstream, client: 82.130.40.76, server: www.flesheatingzipper.com, request: "GET /gaming/2011/11/skyrim-guide-dragon-shout-rune-locations-youre-welcome/ HTTP/1.1", upstream: "fastcgi://unix:/tmp/php5-fpm.sock:", host: "www.flesheatingzipper.com"

WordPress crons:

• jetpack_clean_nonces - De hora em hora
• akismet_scheduled_delete - Diariamente @ 3:00 am
• wp_version_check - Duas vezes por dia (10h-10h)
• wp_update_plugins - Duas vezes por dia (10h-10h)
• wp_update_themes - Duas vezes por dia (10h-22h)
• wp_scheduled_delete - Daily @ 10am

Aqui está minha configuração do PHP-FPM: link

    

Answer 1

Parece que está relacionado ao plugin Wassup. Eu habilito os logs lentos do PHP e recebo o erro abaixo depois que o site falhou novamente, mas durante o dia. Depois que eu desativei o plug-in, o site ficou instantaneamente mais rápido e não tive lentidão nem travou como antes.

[25-Jan-2012 15:09:20]  [pool www] pid 3593
script_filename = /home/fez/www/index.php
[0x00007f353cb75890] mysql_query() /home/fez/www/wp-includes/wp-db.php:1091
[0x00007f353cb75670] query() /home/fez/www/wp-includes/wp-db.php:1375
[0x00007f353cb753d8] get_results() /home/fez/www/wp-content/plugins/wassup/lib/wassup.class.php:553
[0x00007f353cb75278] getMySQLsetting() /home/fez/www/wp-content/plugins/wassup/lib/wassup.class.php:180
[0x00007f353cb750c0] defaultSettings() /home/fez/www/wp-content/plugins/wassup/lib/wassup.class.php:232
[0x00007f353cb74fc0] getSettings() /home/fez/www/wp-content/plugins/wassup/lib/wassup.class.php:212
[0x00007f353cb74ef8] loadSettings() /home/fez/www/wp-content/plugins/wassup/lib/wassup.class.php:90
[0x00007f353cb74b10] wassupoptions() /home/fez/www/wp-content/plugins/wassup/wassup.php:1822
[0x00007f353cb749d0] wassupPrepend() /home/fez/www/wp-content/plugins/wassup/wassup.php:326
[0x00007fff788d6280] wassup_init() unknown:0
[0x00007f353cb747a8] call_user_func_array() /home/fez/www/wp-includes/plugin.php:405
[0x00007f353cb74410] do_action() /home/fez/www/wp-settings.php:304
[0x00007f353cb74320] +++ dump failed

    

Answer 2

O WordPress faz coisas estranhas com trabalhos agendados. Ele tem um arquivo wp-cron.php que é incluído / executado nas solicitações da página. Isso é usado para simular um crontab para pessoas que não têm acesso a um crontab real.

Eu suspeito que você tenha configurado uma tarefa cron diária em seu centro de administração do WordPress que faz algo que leva mais de 73 segundos. A primeira solicitação de página, 24 horas após a última execução, acionará novamente a tarefa cron e causará outro tempo limite.

Por que, eventualmente, é bem-sucedida, só posso adivinhar que está fazendo parte do trabalho durante cada execução e salvando seu progresso ou que o sistema operacional está armazenando em cache cada vez mais os arquivos em que está tocando até que possa faça todo o cron funcionar mais rápido que o timeout.

Algumas pessoas trabalharam no fazendo com que trabalhos agendados do WordPress funcionem por meio de um crontab normal .

A tarefa akismet_scheduled_delete - Daily @ 3:00am cron parece ser o culpado mais provável. Ou há uma diferença entre as visões do servidor e do PHP do fuso horário atual, o que significa que a tarefa 3am realmente é executada às 4h ou o trabalho leva mais de uma hora para ser executado.

    

Answer 3

Você nunca deu sua configuração nginx. No entanto, SIGTERM (15) em crianças PHP-FPM pode ser um destes:

• Abra os descritores de arquivos muito baixos (edite o /etc/security/limits.conf e crie uma entrada para o seu usuário da web e defina 'nofiles' para algo maior). Também configure rlimit_files para algo maior em sua configuração do PHP-FPM se você usar isso

• Você está usando fastcgi_keep_conn em sua configuração do nginx. Isso tem resultados desastrosos com o php-fpm com configurações 'sob demanda' e 'dinâmicas', pois o php-fpm destrói e cria novos filhos php-fpm, mas o nginx não sabe como se reconectar, então seu site irá cair.

Answer 4

Eu estou supondo que você tem um despejo de banco de dados ou backup em execução e algumas tabelas estão ficando bloqueadas no processo de que, sempre faz alguns tempos limite agradáveis. Tente ativar o log de consultas lentas do mysql e verifique se há consultas lentas por volta das 4h.