Проблема: PHP случайным образом перестаёт реагировать на внешние запросы.
Сайт работает на WordPress (с WP SuperCache), web-сервером стоит nginx, php-fpm с 40 дочерними процессами висит в режиме FastCGI. Довольно-таки стандартная конфигурация.
Иногда (периодичность не ясна) сайт падает. В том плане, что nginx выдаёт ошибку 502 Bad Gateway
. При этом в логах отображается примерно такое:
Лечится только перезапуском php-fpm
.
Ошибка очень интересная и нестандартная: один и тот же PHP обслуживает двух разных пользователей, соответственно, имеется два пула дочерних процессов. При этом висит только один пул. Следовательно, это не должна быть ошибка в FPM, иначе бы висело всё.
К счастью, php-fpm имеет один замечательный инструмент отладки: лог запросов к скриптам, выполняющихся дольше определённого времени с backtrace вызовов функций (нечто типа debug_backtrace()
в PHP).
Оставил всё это дело на ночь, а наутро в логах получилась примерно такая картина (я оставил только уникальные backtrace):
script_filename = /index.php
[0x00007fff494c81e0] sem_acquire() /wp-content/plugins/wp-super-cache/wp-cache-phase2.php:137
[0x00007fff494ca6e0] wp_cache_writers_entry() /wp-content/plugins/wp-super-cache/wp-cache-phase2.php:198
[0x00007fff494ca7e0] wp_cache_ob_callback() unknown:0
[0x00007fff494cc280] ob_end_flush() /wp-content/plugins/wp-super-cache/wp-cache-phase2.php:515
[0x00007fff494cc380] wp_cache_shutdown_callback() unknown:0
Mar 22 18:32:29.859417 pid 3748 (pool XXX)
script_filename = /wp-cron.php
[0x00007fff494c7f00] sem_acquire() /wp-content/plugins/wp-super-cache/wp-cache-phase2.php:137
[0x00007fff494c8a80] wp_cache_writers_entry() /wp-content/plugins/wp-super-cache/wp-cache-phase2.php:427
[0x00007fff494c8ea0] wp_cache_phase2_clean_expired() /wp-content/plugins/wp-super-cache/wp-cache-phase2.php:673
[0x00007fff494c8fa0] wp_cache_gc_cron() unknown:0
[0x00007fff494c99d0] call_user_func_array() /wp-includes/plugin.php:414
[0x00007fff494ca380] do_action_ref_array() /wp-cron.php:54
Запросов первого типа было очень много, и они заняли все процессы, стрелки указывают на Wp SuperCache. То, что проблема именно с семафором, подтверждает вывод ps -C php-cgi -opid,state,wchan:25,args
:
23024 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23025 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23047 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23048 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23049 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23050 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23051 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23052 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23053 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23054 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23055 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23056 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23057 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23058 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23059 S flock_lock_file_wait /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23060 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23061 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23062 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23063 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23064 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23065 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23066 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23067 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23068 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23069 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23070 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23071 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23072 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23073 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23074 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23078 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23079 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23080 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23081 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23082 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23083 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23084 S flock_lock_file_wait /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23085 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23086 S semtimedop /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
S
означает "сон, который можно прервать" (ожидание свершения события), а semtimedop
— функция, в которой процесс уснул.
Так как в пуле 40 процессов, и все 40 процессов спят, имеем проблему с синхронизацией. Особенно смущает засыпание в flock_lock_file_wait
— по идее, WP SuperCache использует либо семафоры, либо файловую блокировку, но вероятно, я что-то не учитываю (ибо не kernel developer).
Теоретически (если верить документации) неосвобождённые семафоры автоматически удаляются при завершении скрипта (то есть в ситуации, когда скрипт захватил семафор и трагически погиб, семафор будет освобождён).
В общем, буду копать код WP SuperCache и искать баги.
Спасибо за инфу
И что люди в этом плагине нашли? Hyper Chace намного проще.
Что то подобное подозревалось изначально, учитывая сколько хелпов на форуме майвордпрес… И стрелки ведут к СуперКешу. Было бы неплохо докопаться до истины. А пока рекомендовать всем воздержаться от использования ( но это только мое мнение).
Проблема решается путём отключения блокировки, но это полумера.
И я об этом - лучше не рисковать… Ко всему прочему он не меряно забирает дисковое пространство при не правильной настройке ( но это уже другая тема).