Спасибо за Ваш ответ. У меня есть вся ошибка PHP при движении в файл журнала. Я получаю несколько уведомлений, но никакие ошибки. Я должен признать, что не написал этот код. На данный момент я перенаправил все 500 ошибок к index.php, с помощью .htaccess 'правило. Я должен пропускать что-то все же. Этого не должно происходить. Единственное предположение, которое я имею, - то, что, после того как' PHP_FCGI_MAX_REQUESTS' достигает, он макс., php уничтожает ребенка, и это путает FastCGI. Однако, если я понимаю правильно, что PHP имеет родительский процесс, который должен быть единственным, с которым говорит FastCGI, таким образом, я не к уверенному, что это - он... Вот мой сценарий обертки:

#!/bin/bash
# Shell Script To Run PHP5 using mod_fastcgi under Apache 2.x
# Tested under Red Hat Enterprise Linux / CentOS 5.x
### Set PATH ###
PHP_CGI='/usr/bin/php-cgi -d apc.shm_size=60M'
PHP_FCGI_CHILDREN=25
PHP_FCGI_MAX_REQUESTS=1000
### no editing below ###
export PHP_FCGI_CHILDREN
export PHP_FCGI_MAX_REQUESTS
exec $PHP_CGI

Это - сервер очень большого объема так, чтобы был то, почему PHP_FCGI_CHILDREN установлен настолько высоко.

Еще раз спасибо, Ben

Я где-то читал (имея дело с lighttpd, а не с apache), что php по какой-то причине не может обрабатывать более 500 запросов. 501-й запрос взорвется по какой-либо причине.

Извините, у меня нет дополнительной информации, но это, по крайней мере, стоит попробовать.

tl; dr попробуйте установить PHP_FCGI_MAX_REQUESTS на 500 и посмотреть, исчезнет ли проблема сама собой вверх.

Нашел информацию, она применима к Lighttpd, и я не знаю, применима она к apache или нет.

Протестируйте ее, и я хотел бы услышать, является ли это проблема только с lighttpd, или она является общей проблемой.

Почему мое приложение PHP время от времени возвращает ошибку 500?

«Эта проблема, похоже, связана с малоизвестной проблемой с PHP: PHP перестает принимать новые FastCGI-соединения после обработки 500 запросов; к сожалению, существует потенциальное состояние гонки во время кода очистки PHP, при котором PHP может выключиться, но сокет все еще открыт, поэтому лайтти может отправить запрос номер 501 в PHP и принять его, но тогда PHP, кажется, просто выходит , вызывая возврат 500 от lighty.

Чтобы ограничить эту возможность, установите PHP_FCGI_MAX_REQUESTS на 500. "

- http://redmine.lighttpd.net/projects/1/wiki/Docs:PerformanceFastCGI

Краткое содержание

Я наблюдал такое же поведение с Apache; похоже, что эта проблема не специфична для lighttpd.

В моем случае симптомы были точно такими же; журналы доступа Apache были заполнены прерывистыми кодами ответов 500, и в журнале ошибок PHP не было соответствующих записей (а отчеты об ошибках PHP были настроены на максимально подробный).

Я подробно описал проблему в списке рассылки Apache ( поищите в архивах списков тему «500 прерывистых ответов в access.log без соответствующих записей в error.log»).

Основная причина

Ответ 1100110 указывает на основную причину, но я предоставлю дополнительную документацию, прямо от Apache, а также предложения по устранению проблемы. and they may exit after this module has already connected to the application and sent the next request. When that occurs, an error will be logged and 500 Internal Server Error will be returned to the client. This PHP behavior can be disabled by setting PHP_FCGI_MAX_REQUESTS to 0, but that can be a problem if the PHP application leaks resources. Alternatively, PHP_FCGI_MAX_REQUESTS can be set to a much higher value than the default to reduce the frequency of this problem. FcgidMaxRequestsPerProcess can be set to a value less than or equal to PHP_FCGI_MAX_REQUESTS to resolve the problem.

PHP child process management (PHP_FCGI_CHILDREN) should always be disabled with mod_fcgid, which will only route one request at a time to application processes it has spawned; thus, any child processes created by PHP will not be used effectively. (Additionally, the PHP child processes may not be terminated properly.) By default, and with the environment variable setting PHP_FCGI_CHILDREN=0, PHP child process management is disabled.

The popular APC opcode cache for PHP cannot share a cache between PHP FastCGI processes unless PHP manages the child processes. Thus, the effectiveness of the cache is limited with mod_fcgid; concurrent PHP Однако в документации упускается важный момент: значение также должно быть больше нуля (потому что ноль в данном контексте означает «неограниченно» или «отключить проверку»). Учитывая, что значение по умолчанию для FcgidMaxRequestsPerProcess равно нулю, а значение по умолчанию для PHP_FCGI_MAX_REQUESTS - 500, любой администратор, который не переопределил эти значения, будет сталкиваться с прерывистыми кодами ответа 500. По этой причине я не могу понять, почему FcgidMaxRequestsPerProcess и PHP_FCGI_MAX_REQUESTS не имеют одного и того же значения по умолчанию. Возможно, это связано с тем, что настройка этих двух директив как таковых дает тот же чистый результат, что и установка PHP_FCGI_MAX_REQUESTS в ноль; документация неоднозначна в этом отношении.

Вариант 3

Третье решение - полностью отказаться от Fast-CGI, в пользу сопоставимой альтернативы, такой как suPHP или простой CGI + SuExec. Я провел базовый, необработанный тест производительности в различных режимах PHP и получил следующие результаты:

1. Mod-PHP 77.7
2. CGI 69.0
3. suPHP 67.0
4. Fast-CGI 55.7

Mod -PHP является самым эффективным с показателем 77,7. Оценки являются произвольными и служат только для демонстрации относительной разницы во времени загрузки страницы в разных режимах PHP.

Если мы предположим, что эти тесты достаточно репрезентативны, то, похоже, будет очень мало причин придерживаться Fast-CGI, учитывая этот (довольно серьезный) недостаток в его реализации. Единственная существенная причина, которая приходит на ум, - это кеширование кода операции. Насколько я понимаю, PHP не может использовать кэширование кода операции через режим CGI или suPHP (поскольку процессы не сохраняются между запросами).

Хотя Fast-CGI не использует преимущества кэширования кода операции (например, через APC) из коробки, умные пользователи разработали метод обеспечения эффективности APC с помощью Fast-CGI (через кеширование для каждого пользователя). ): http://www.brandonturner.net/blog/2009/07/fastcgi_with_php_opcode_cache/ . Однако есть несколько недостатков:

1. Требования к памяти (ОЗУ) значительны, так как для каждого пользователя есть выделенный кэш. (Для перспективы примите во внимание, что в режиме Mod-PHP все пользователи используют один кеш.)
2. Apache должен использовать старый модуль mod_fastcgi вместо более нового эквивалента mod_fcgid. (Подробнее см. Статью, процитированную в предыдущем абзаце.)
3. Конфигурация довольно сложная.

В качестве связанного следствия вы сказали следующее в своем вопросе:

Сначала я использую APC, поэтому PHP в управлении собственными процессами, не FastCGI.

Если вы не используете mod_fastcgi (а не mod_fcgid), и если вы не выполнили шаги, аналогичные приведенным в нескольких абзацах выше, APC потребляет ресурсы безрезультатно. Таким образом, вы можете отключить APC.

Краткое изложение решения

Примите одно из следующих трех мер:

1. Установите для переменной среды PHP_FCGI_MAX_REQUESTS значение ноль. (Создает возможность выхода утечек памяти в сценариях PHP из-под контроля.)
2. Установите для FcgidMaxRequestsPerProcess значение, меньшее или равное PHP_FCGI_MAX_REQUESTS, но больше нуля.
3. Отказаться от Fast-CGI в пользу сопоставимой альтернативы, например suPHP или старый CGI + SuExec.