#Симптом и границы применимости
PHP-FPM может завершать рабочий процесс, если обработка одного запроса превышает request_terminate_timeout. Это отдельный механизм от max_execution_time PHP и тайм-аутов Nginx/Apache. Изменять лимит без выяснения причины зависания опасно: очередь может стать ещё больше.
#Возможные причины и как их отличить
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Приложение выполняет медленный запрос БДПроцесс занят до срабатывания ограничения. | Одинаковый URL длительно ожидает и затем обрывается | Найти дорогой SQL либо блокировку |
| Зависание на внешнем HTTP/сервисеУвеличение лимита FPM не устраняет недоступный сервис. | Запрос ждёт API либо сеть, не загружая CPU | Настроить тайм-аут вызова приложения |
| Не совпадают тайм-ауты уровнейКаждый слой может прервать запрос независимо. | Браузер получает 504 раньше убийства процесса FPM | Сравнить proxy/fastcgi timeout и PHP-FPM настройки |
#Пошаговая диагностика и исправление
- Зафиксируйте точную длительность и URLВоспроизведите один безопасный GET без побочных действий; измерьте время curl, сохраните код ответа и дату. Для POST-операций (оплата, регистрация, рассылка) повторять запросы нельзя без тестовой среды.Linux · Терминал (Bash)Команда
curl -sS -o /dev/null -w "HTTP=%{http_code} total=%{time_total}\n" --max-time 120 https://example.com/
- Найдите подтверждение в журнале FPMПо SSH прочитайте сообщения конкретного пула за то же время. Найдите строки про execution timed out и termination после N секунд. Если журнал чист, проверьте тайм-аут внешнего Nginx/Apache, а не приписывайте сбой FPM.
- Имя службы условное; запросы могут логироваться в отдельный файл FPMLinux · Терминал (Bash)КомандаНужен sudoИмя службы условное; запросы могут логироваться в отдельный файл FPM.
sudo journalctl -u php8.2-fpm -n 100 --no-pager
- Найдите, где задано ограничениеВ конфигурации пула ищите request_terminate_timeout и при необходимости request_terminate_timeout_track_finished. Учитывайте единицы секунд, минуты, часы; значение 0 означает отсутствие ограничения, поэтому ставить его на публичном сервере без анализа рискованно. Настройки php.ini max_execution_time проверяются отдельно.
- Выясните, на чём процесс тратит времяВ тестовой среде включите slowlog и request_slowlog_timeout, задав файл журнала с закрытым доступом. Журнал стека PHP поможет определить зависшую функцию; в приложение добавьте измерение времени SQL и внешних HTTP-вызовов. Не включайте детальные трассировки с персональными данными в публичном каталоге.
- Исправьте реальную причину либо выделите фоновые задачиЕсли запрос запускает долгий отчёт, перенесите операцию в очередь с отображением состояния, если приложение это поддерживает. Для внешнего API используйте его разумный тайм-аут и обработку ошибки. Поднимать request_terminate_timeout допустимо лишь на измеренный период и при достаточной ёмкости пула; не делайте его бесконечным.
- Примените изменения осторожноСохраните копию файла пула, проверьте php-fpm -t именно правильной версии, затем выполните управляемый reload/restart в согласованное окно. Протестируйте одну безопасную операцию и следите, не выросло ли число одновременно занятых процессов.
- Дополнительная команда по темеLinux · Терминал (Bash)С осторожностьюНужен sudoИмя двоичного файла меняется по версии; применять конфигурацию только после успешного теста.
sudo php-fpm8.2 -tКоманда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
#Как проверить результат
Безопасный исходный запрос завершается до своего ограничителя с ожидаемым ответом, нет новых сообщений о request_terminate_timeout и не растёт очередь пула.
#Если проблема не устранена
Если медленное выполнение необходимо по бизнес-логике, используйте фоновые задачи; если тайм-аут срабатывает на уровне прокси раньше, сверяйте его отдельно. Не отключайте защитные лимиты без нагрузки и плана отката.