PHP и mod fcgid: AP pass brigade не удалось выполнить функцию IPC запроса дескриптора

об этом спрашивали и отвечали раньше https://stackoverflow.com/a/12686252/219116 но, решение там не работает для меня.

mod_fcgid конфигурации

<IfModule mod_fcgid.c>
  AddHandler    fcgid-script .fcgi
  FcgidIPCDir /var/run/mod_fcgid/
  FcgidProcessTableFile /var/run/mod_fcgid/fcgid_shm

  FcgidIdleTimeout 60
  FcgidProcessLifeTime 120
  FcgidMaxRequestsPerProcess 500
  FcgidMaxProcesses 150
  FcgidMaxProcessesPerClass 144
  FcgidMinProcessesPerClass 0
  FcgidConnectTimeout 30
  FcgidIOTimeout 600
  FcgidIdleScanInterval 10
  FcgidMaxRequestLen 269484032

</IfModule>

в php-cgi-скрипт

#!/bin/bassh
export PHPRC=/var/www/vhosts/example.com/etc/
export PHP_FCGI_MAX_REQUESTS=5000
exec /usr/bin/php-cgi

сведения о системе

  • CentOS Linux выпуска 7.1.1503 (Core)
  • httpd-2.4.6-31.el7.в CentOS.архитектуру x86_64
  • mod_fcgid-2.3.9-4.el7.архитектуру x86_64
  • php56u-cli-5.6.12-1.МСС.centos7.архитектуру x86_64

таким образом, мой FcgidMaxRequestsPerProcess установлен в 500, а мой PHP_FCGI_MAX_REQUESTS установлен в 10x, как это было предложено в предыдущих ответах и документации Apache. И все же я все еще получаю эти ошибки

[Thu Nov 19 18:16:48.197238 2015] [fcgid:warn] [pid 6468:tid 139726677858048]
(32)Broken pipe: [client X.X.X.X:41098] mod_fcgid: ap_pass_brigade failed in handle_request_ipc function

2 ответов


предупреждение не имеет ничего общего с какими-либо Fcgidxxx options и просто вызвано закрытием клиентом своей стороны соединения до того, как сервер получит возможность ответить.

из фактического источника:

/* Now pass any remaining response body data to output filters */
if ((rv = ap_pass_brigade(r->output_filters, brigade_stdout)) != APR_SUCCESS) {
    if (!APR_STATUS_IS_ECONNABORTED(rv)) {
        ap_log_rerror(APLOG_MARK, APLOG_WARNING, rv, r,
                      "mod_fcgid: ap_pass_brigade failed in "
                      "handle_request_ipc function");
    }

    return HTTP_INTERNAL_SERVER_ERROR;
}

заслуга птичий блог кто узнал об этом.


я также получаю ту же проблему около года назад, тогда я пробовал много вещей, и в последний раз я сделал некоторые из хитов и запустить вещи после чтения документации, и моя проблема ушла. Во-первых, важные вещи, которые необходимо установить как:

FcgidBusyTimeout     300 [default]
FcgidBusyScanInterval    120 [default]

цель этой директивы -завершить зависшие приложения. Тайм-аут по умолчанию может потребоваться увеличить для приложений, которые могут занять больше времени для обработки запроса. Ведь проверить выполняется с интервалом, определяемым FcgidBusyScanInterval, обработка запросов может продолжаться в течение более длительного периода времени

FcgidProcessLifeTime     3600 [default]

простаивающие процессы приложений, которые существовали больше этого времени, будут завершены, если количество процессов для класса превышает FcgidMinProcessesPerClass.

эта проверка продолжительности жизни процесса выполняется на частоте настроенного FcgidIdleScanInterval.

FcgidZombieScanInterval   3 [seconds default]

модуль проверяет наличие выходящих приложений FastCGI при этом интервал. В течение этого периода времени, приложение может существовать в таблице процессов, как зомби (на Unix).

Примечание: все вышеуказанные варианты уменьшают или увеличивают согласно вашим времени или потребностям процесса применения или применяются к специфическому vhost.

но моя проблема решается этой опцией:

выше параметры настроили мой сервер, но через некоторое время ошибки, кажется, снова, но ошибка действительно решить это:

 FcgidOutputBufferSize   65536 [default]

я изменил его на

 FcgidOutputBufferSize   0

это максимальный объем данных ответа, который модуль будет считывать из приложения FastCGI перед сбросом данных клиенту. Это мгновенно очистит данные, не дожидаясь 64 КБ байтов,что действительно поможет мне быстрее очистить процесс.

другие вопросы, которые я получил

если придет 500 ошибка с nginx времени. Этот исправить:

/и т. д./nginx/nginx в.conf

keepalive_timeout  125;
proxy_read_timeout 125;
proxy_connect_timeout 125;
fastcgi_read_timeout 125;

периодически я бы получил ошибку MySQL "MySQL server ушел", которая потребовала еще одной настройки: / etc / my.conf

wait_timeout = 120

затем, просто для удовольствия, я пошел вперед и увеличил свой предел памяти PHP, на всякий случай: / etc / php.ini

memory_limit = 256M

Использование SuExec

mod_fastcgi не работает вообще под SuExec on Apache 2.x. Я ничего, кроме неприятностей от него (у него также было множество других проблем в нашем тестировании). Реальная причина вашей проблемы-SuExec

в моем случае это был запуск для меня, я запускаю Apache, mod_fcgid порождает ровно 5 процессов для каждого vhost. Теперь, при использовании простого сценария загрузки и отправки файла больше 4-8KB все эти дочерние процессы убиваются сразу для конкретного vhost, на котором был выполнен скрипт.

возможно, можно сделать отладочную сборку или кривошип до входа в mod_fcgid, который может дать ключ.

я пробовал mod_fastcgi тем временем в течение 1 года, и я тоже могу сказать со многими другими, что SuExec не что иное, как хлопотно и работает не гладко, в каждом случае.