Долгий скрипт на Nginx, php5-fpm. Ошибка 504 через 60 сек. Куда смотреть?

Question

[zveb]

Есть долгоиграющий php-скрипт - порядка 3-х минут работает.
Через php scriptname.php отрабатывает.

Форум работает отлично, кроме этого скрипта.
Кусок конфига nginx:

location ~ \.php$ {
                ...
                fastcgi_read_timeout 600;
                ...
        }

Браузер при обращении к скрипту выдает через минуту: "504 Gateway Time-out"

в логе ngnix:

2014/11/23 05:21:05 [error] 8534#0: *1 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.1.41, server: server.ru, request: "GET /scriptname.php HTTP/1.0", upstream: "fastcgi://unix:/var/run/php5-fpm.sock", host: "server.ru"

phpinfo() утверждает, что max_execution_time = 0

Кто еще может ограничивать время выполнения скрипта? Куда копать?

Comments

[zveb]

Настроил все заново на другом сервере - все работает.
никакие таймауты не трогал, за исключением директивы fastcgi_read_timeout в nginx`е, ну и в php-скрипте было @ini_set('max_execution_time', 900);

Сервер, на котором возникла проблема не имеет белого IP, а проброшен через виртуальные хосты другого nginx`а. Он, наверное и не дожидался ответа бэкенда.

Всем спасибо за обсуждение, проблема решена.

Answer 1

[neolink]

ну раз получаете ответ c 504 значит тюнить надо nginx
fastcgi_connect_timeout
также возможно придется поднять keepalive_timeout

а вообще перенесите выполнение этого скрипта на cron

Comments

[zveb]

возможно так и сделаю, хотя разработчик советует запускать кроном wget

[Алексей Сундуков]

neolink: все таймауты работы с бэкэндом выше 75 сек не поднимаются.
keepalive в данном контексте это вообще о другом.

[neolink]

Алексей Сундуков: это время сохранения неактивного соединения с браузером пользователя, похоже же разве нет?

а по поводу 75 секунд можно всетаки пруф, вот вам исходник fastcgi модуля
https://github.com/nginx/nginx/blob/master/src/htt...

единственный таймаут который по умолчанию 75 секунд это keepalive_timeout
https://github.com/nginx/nginx/blob/master/src/htt...

[Алексей Сундуков]

zveb: Правильно советуют. Если задача фоновая и не требует реакции от пользователя, то она должна запускаться из крона.

[Алексей Сундуков]

neolink: Правильнее было говорить, что это механизм передачи по одному tcp сокету разных http ресурсов. Это ключевой момент. Потому что "неактивным" может быть и простое, не keepalive, соединение.

Пруф по исходникам я не найду, он упоминался в рассылке Максимом Дуниным если не ошибась, можно поискать либо поднять этот вопрос повторно. Пруф по докам вот: nginx.org/ru/docs/http/ngx_http_fastcgi_module.htm...

[neolink]

Алексей Сундуков: keepalive_timeout это параметр к конфиге nginx, keepalive - это "механизм" суть которого не закрывать сокет после отправки последнего байта клиенту и переводить конечный автомат в состояние "ожидаем запроса пользователя"

https://github.com/nginx/nginx/blob/bb8c0683da7735...
для spdy это точно такой же таймер как и например *_read_timeout, я поэтому и написал "возможно"

по поводу 75 секунд - в доке написано "обычно", а не захардкожено, у меня например сейчас уже 5 минут висит коннекшен в котором я ничего не посылаю

[Алексей Сундуков]

neolink: Не закрывать сокет после отправки последнего байта клиенту можно и не по keepalive соединению.

Касательно таймаутов и харкода посмотрю на досуге, может в последних версиях харкод убрали.

[Алексей Сундуков]

neolink: Ситуация прояснилась. Насчет харкода ввели меня в свое время в заблуждение. Но не важно. В общем хардкодом не ограничивают, ограничивает само ядро. 75 секунд величина сложилась исторически, т.к. изначально nginx работал под фряхой и это дефолтное значение по умолчанию.

Значит автору нужно либо выносить в крон, либо тюнить ядро, либо не выходить за таймауты (по времени исполнения, либо сбрасывая буфера).

[neolink]

Алексей Сундуков: serverfault.com/questions/571614/why-cant-nginx-ha...

75 секунд это таймаут на доставку syn пакета, то есть если у вас бекенд не упал (или сеть не перегружена и т.п.) вы в это не упретесь

[zveb]

Как я уже написал в комментарии к стартовому посту - проблема оказалась в том, что мой nginx является является бэкендом другого nginx`а.
Я настроил все на другом сервере и убедился, что директива fastcgi_read_timeout "убеждает" nginx ждать ответа сколько скажут ;)

Answer 2

[Борис Беньковский]

Где вы взяли phpinfo? в php5-fpm или в cli? подозреваю, раз

php scriptname.php

работает нормально, то значение вы достали из cli .
1. Конфиг ищите в /etc/php5/fpm/php.ini
2. Либо наш любимый быдлокод
ini_set('max_execution_time', 0);
(если эту дерективу можно менять в рантайме.... просто не помню)
UPD:
Также есть переменная для php5fpm пула (файл точно не помню , вроде этот /etc/php5/fpm/pool.d/your_pool)
request_terminate_timeout = 300

Comments

[zveb]

Вызов phpinfo смотрю в админке phpbb
1. В /etc/php5/fpm/php.ini я поставил max_execution_time 0
2. Есть такое ;)
// This script will take a while. We should disable max_execution_time.
@ini_set('max_execution_time', 900);

[Lynn «Кофеман»]

А если fastcgi_connect_timeout поменять?

Answer 3

[Алексей Сундуков]

Максимальное время которое nginx ждет ответ от бэкэнда - 75 секунд. Причем это захардкожено в коде самого nginx. Это предельная величина директивы конфига fastcgi_read_timeout (которая по умолчанию как раз 60 секунд). Нужно более долгое время - сбрасывайте буфера на бэкэнде не реже этого времени. Я так желаю:

// отправляем данные nginx-у что бы не выйти за fastcgi_read_timeout
$output_buffer = ob_get_length();
if ( !empty($output_buffer) ) {
    flush();
    ob_flush();
}

Comments

[zveb]

Вставил этот код в самый "страшный" на вид цикл, но не помогло. Не угадал, видимо. Нужно более вдумчиво почитать скриптюню ;)

[neolink]

а может вы и строчку покажете где это захардкожено?

[Алексей Сундуков]

zveb: Что код работает проверено на множестве проектов. Значит он вставлен либо: 1) не в том место, либо 2) скрипт ни чего не отдает (из-за !empty($output_buffer) буфер не очищается если очищать нечего), 3) приведенный мною код вызывается реже, чем в минуту.

Что бы сработало, скрипт должен в процессе работы что-то отдавать на выход. Если echo-ть нечего, то можно тупо печатать какой нибудь мусор. echo time() допустим.

Answer 4

[VovanZ]

Если вам нужно, чтобы скрипт просто отработал, и не нужно получать резутат в браузере, то можно установить ignore_user_abort(true) (php.net/manual/ru/function.ignore-user-abort.php), чтобы скрипт доработал после того, как nginx перестает ждать ответа, или же прервать ожидание самому, с помощью fastcgi_finish_request() (php.net/manual/ru/function.fastcgi-finish-request.php) и после этого доделать всё, что надо.