Сбой интенсивного PHP-скрипта с «истекло указанное время ожидания» error / ap_content_length_filter - PullRequest
9 голосов
/ 13 января 2010

Запуск интенсивного сценария PHP MySQL, который терпит неудачу. Журнал Apache сообщает об этом:

[Wed Jan 13 00:20:10 2010] [error] [client xxx.xx.xxx.xxxx] (70007)
The timeout specified has expired:
ap_content_length_filter: apr_bucket_read() failed,
referer: http://domain.com/script.php

Пробовал ставить set_time_limit(0) вверху.

Также пробовал set_time_limit(0)

Ни один из них не зафиксировал тайм-аут.

Есть ли какой-то определенный предел тайм-аута, который я могу увеличить в http.conf (или в другом месте), чтобы предотвратить это?

Ответы [ 9 ]

7 голосов
/ 20 марта 2014

Я также очень похож на стену с Apache 2.4.6 и PHP 5.4.23 FPM / FastCGI .

Симптом:

Независимо от того, что я установил в PHP или Apache, мой скрипт остановился бы через 30 секунд, и я увидел бы следующее в моем журнале ошибок Apache:

[timestamp] [proxy_fcgi:error] [pid...] (70007)The timeout specified has expired: [client ...] AH01075: Error dispatching request to :

Мой Виртуальный Хост:

TimeOut  300
KeepAliveTimeout 300

<IfModule reqtimeout_module>
  RequestReadTimeout header=120-240,minrate=500
  RequestReadTimeout body=120,minrate=500
</IfModule>

<IfModule mod_proxy.c>
  ProxyTimeout 300
</IfModule>

<IfModule mod_fcgid.c>
  FcgidConnectTimeout 300
</IfModule>

Скрипт php:

ini_set( 'max_execution_time', '120' );
...
ini_restore( 'max_execution_time' );

Исправление: это жестко закодированное значение в Apache mod_proxy_fcgi

Посмотрите отчет об ошибке здесь

  • Доступен патч (ссылка выше)
  • Исправление пока не выпущено для общего выпуска (март 2014 г.)
5 голосов
/ 19 сентября 2012

Во-первых, мое решение применимо только к веб-серверу Apache.

Я работаю над сценарием, предназначенным для использования в качестве сценария загрузки csv для отчета с очень очень большой базой данных, и я тоже столкнулся с этой проблемой. Я не использую php, но вместо этого мой скрипт написан на каком-то непонятном языке heitml; -)

Проблема тайм-аута запроса возникает в моем сценарии следующим образом:

[Wed Sep 19 20:29:01 2012] [warn] [client ::1] Timeout waiting for output from CGI script /var/www/cgi-bin/heitml
[Wed Sep 19 20:29:01 2012] [error] [client ::1] (70007)The timeout specified has expired: ap_content_length_filter: apr_bucket_read() failed

И единственное серьезное решение, к которому я могу сейчас приспособиться, - это использовать это официальное расширение конфигурации таймаута здесь: mod_reqtimeout . Это позволяет регулировать параметры тайм-аута, например:

Разрешить 10 секунд для получения запроса, включая заголовки, и 30 секунд для получения тела запроса:

RequestReadTimeout header=10 body=30

Подождите не менее 10 секунд, чтобы получить тело запроса. Если клиент отправляет данные, увеличьте время ожидания на 1 секунду для каждых 1000 полученных байтов без ограничения верхнего предела для времени ожидания (за исключением предела, косвенно заданного LimitRequestBody):

RequestReadTimeout body=10,MinRate=1000

Подождите не менее 10 секунд, чтобы получить запрос, включая заголовки. Если клиент отправляет данные, увеличьте время ожидания на 1 секунду для каждых 500 полученных байтов. Но не допускайте более 30 секунд для запроса, включая заголовки:

RequestReadTimeout header=10-30,MinRate=500

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

RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500

Еще предстоит выяснить, есть ли лучшее решение, предлагаемое Apache, которое не требует от меня использования этого модуля (при условии, что он не установлен по умолчанию - хотя он включен во все версии 2.2.15 и более поздние).

4 голосов
/ 02 августа 2016

Я подозреваю, что получаю ту же ошибку, обновленную для более поздней версии Apache (2.4.16):

[Tue Aug 02 11:49:41.930884 2016] [core:error] [pid 28640] (70007)The timeout specified has expired: [client xxx.xxx.xxx.xxx:xxxxx] AH00574: ap_content_length_filter: apr_bucket_read() failed, referer: https://domain.com/script.php

Мне было интересно, почему увеличение max_execution_time в php.ini не работает.

Для меня исправлением было просто увеличение директивы Timeout в httpd.conf https://httpd.apache.org/docs/2.4/mod/core.html#timeout

Timeout 900

(или в WHM -> Apache Configuration -> Global Configuration, в зависимости от обстоятельств)

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

3 голосов
/ 13 января 2010

Также есть директива php max_execution_time . Обратите внимание, что настройки тайм-аута веб-сервера также могут ограничивать ваш скрипт:

Ваш веб-сервер может иметь другой тайм-аут конфигурации, которые также могут прерывать Выполнение PHP. Apache имеет тайм-аут директива и IIS имеет тайм-аут CGI функция. Оба по умолчанию до 300 секунд. Смотрите документацию вашего веб-сервера для конкретные детали.

* +1007 *

На самом деле это похоже на ошибку Apache, это также влияет на скрипты Python. Вы уже пробовали погуглить?

1 голос
/ 13 июня 2011

Существует другое значение тайм-аута, помещенное не в сам php, а на сервер apache. Он будет тормозить скрипт, когда ничего не выводится в течение указанного времени, поэтому при выполнении более сложной работы в PHP вы можете достичь этого предела. Просто передайте что-нибудь обратно в браузер (не буферы!) Или увеличьте значение тайм-аута Apache до безопасного значения, насколько я помню, это свойство Apache KeepAliveTimeOut. Удачи :)

0 голосов
/ 19 апреля 2018

Я перепробовал все предложения, но моя проблема была в конфигурации php-fpm . Я установил следующую строку в моем файле конфигурации php-fpm:

request_terminate_timeout = 300s
0 голосов
/ 05 января 2016

Примечание: Этот ответ дословно дублируется от аналогичного вопроса .

Оригинальный ответ

У меня есть Apache 2.4.6, но исправление для его исправления предоставляется в Apache> = 2.4.8. Ключом здесь является немедленное начало вывода, чтобы Apache (mod_proxy_fcgi) решил, что соединение активно.

Например, я использую PHP, и запрос БД для моего вызова AJAX занимает> 30 секунд. Поскольку я знаю, что общий ответ будет «Content-Type: application / json», я немедленно отправляю этот заголовок.

#1: Start output immediately
#Note: Sending the header is innocuous
#   it can be changed later using the $replace parameter
#   (see #3)
header( 'Content-Type: application/json' );

#2: Run slow query
mysql_query( "SELECT * FROM giant_table" );

#3: Change header as needed
header( 'Content-Type: application/csv', true );

#output content
0 голосов
/ 17 января 2010

Я поэкспериментировал с этими ограничениями ресурсов в php.ini, чтобы исправить проблему.

max_execution_time = 300
max_input_time = 300
memory_limit = -1
0 голосов
/ 13 января 2010

В php.ini также есть тайм-аут.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...