Тайм-аут PHP-FPM каждый день выходит
Похоже, это было связано с плагином Wassup. Я включаю медленные журналы PHP и получаю сообщение об ошибке ниже после того, как сайт снова упал, но в течение дня. После того, как я отключил плагин, сайт мгновенно стал быстрее, и у него не было и не было замедлений и сбоев, как раньше.
[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
WordPress делает странные вещи с заданиями cron. У него есть файл wp-cron.php , который включается / выполняется при запросах страниц. Это используется для имитации crontab для людей, у которых нет доступа к настоящему crontab.
Я подозреваю, что вы настроили ежедневное задание cron в центре администрирования WordPress, которое делает что-то, что занимает более 73 секунд. Запрос первой страницы через 24 часа после последнего запуска снова запустит это задание cron и вызовет еще один тайм-аут.
Что касается того, почему он в конечном итоге завершается успешно, я могу только догадываться, что он либо выполняет часть задания во время каждого запуска. и сохраняя свой прогресс, или что ОС кэширует все больше и больше файлов, к которым она прикасается, пока не сможет выполнить всю работу cron быстрее, чем тайм-аут.
Некоторые люди работали над , чтобы заставить cron-задания WordPress работать через обычный crontab .
akismet_scheduled_delete - Daily @ 3:00 am cron job выглядит наиболее вероятным виновником. Либо существует разница между представлениями сервера и PHP текущего часового пояса, что означает, что задание в 3 часа ночи на самом деле выполняется в 4 часа ночи, либо выполнение задания занимает более часа.
Я предполагаю, что у вас запущен дамп базы данных или резервное копирование, и некоторые таблицы блокируются в процессе, что всегда создает хорошие таймауты. Попробуйте включить журнал медленных запросов mysql и проверьте, нет ли медленных запросов около 4 часов утра.
Вы никогда не указывали конфигурацию nginx. Однако SIGTERM (15) на дочерних элементах PHP-FPM может быть одним из следующих:
Открытые файловые дескрипторы слишком малы (отредактируйте /etc/security/limits.conf, создайте запись для своего веб-пользователя и установите для чего-нибудь «nofiles» выше). Также установите для rlimit_files значение выше в конфигурации PHP-FPM, если вы используете это
. Вы используете fastcgi_keep_conn в конфигурации nginx. Это имеет катастрофические результаты с php-fpm с конфигурациями ondemand и dynamic, поскольку php-fpm срывается и создает новые дочерние элементы php-fpm, но nginx не знает, как повторно подключиться, поэтому ваш сайт упадет.