У меня была похожая проблема, что у fcgid закончились доступные слоты процесса после некоторого периода активности.
Сообщение в журнале было примерно так:
[fcgid:warn] mod_fcgid: can't apply process slot for /var/www/cgi-bin/xxx/php-cgi, referer: ...
Я отследил проблему вплоть до следующего:
[fcgid:emerg] (35)Resource deadlock avoided: [client ....] mod_fcgid: can't get pipe mutex, referer: ...
, которая возникает из-за неправильной блокировки. В моём случае, Apache использовал блокировку fcntl() (по умолчанию в debian), поэтому я изменил её на flock() в apache2.conf
:
Mutex flock:${APACHE_LOCK_DIR} default
Ссылка, которая привела меня к решению проблемы: https://bz.apache.org/bugzilla/show_bug.cgi?id=53999
Документация по различным опциям блокировки (у fcgid есть предупреждение о том, что не стоит usign it ни с чем, что могло бы вовлечь потоки): https://httpd.apache.org/docs/2.4/mod/core.html#mutex
У меня нет точного ответа, но, возможно, дополнительная информация поможет решить проблему. Я хотел бы сказать, что у меня такая же проблема на сервере Windows с PHP 5.3.5.
Некоторые cgi-процессы остаются своего рода зомби-задачами после их реального выполнения. Они даже игнорируют такие настройки, как max_execution time.
В настоящее время у меня есть запланированный сценарий, который убивает эти старые процессы. Проблема с этим решением заключается в том, что даже "нормальные" процессы cgi были убиты, возможно, было бы полезно определить время выполнения процессов и уничтожить их только в том случае, если у них истекло время max_execution.
Переход на «sem», как предложил Томас в https://bz.apache.org/bugzilla /show_bug.cgi?id=53999 у меня сработало.
Так что я бы порекомендовал любому отредактировать его apache2.conf, прокомментировать строку Mutex и поставить:
# Mutex file:${APACHE_LOCK_DIR} default # Original debian config
Mutex sem # Solves orphaned PHP processes.