PHP-FPM LinuxPHP 8.xNginx/Apache

PHP-FPM: request_terminate_timeout прерывает импорт крупного файла

  • Обновлено
  • Чтение ≈ 4 минуты
  • Нужны права администратора

Краткий ответ

В отличие от обычной ошибки upload_max_filesize, файл может успешно загрузиться, а сбой возникает уже во время обработки внутри PHP. Увеличение времени запроса не решает проблему частично записанных данных и занятого работника.

В этой статье
  1. Симптомы и отличие от похожих неисправностей
  2. Диагностика и пошаговое устранение
  3. Как проверить результат и что предпринять при неуспехе

#Симптомы и отличие от похожих неисправностей

При длительном импорте CSV или большого архива PHP-FPM принудительно завершает работающий процесс по request_terminate_timeout, после чего браузер получает 502/504 или оборванное соединение. Как определить, какой таймаут сработал, и безопасно обработать большой объём. В отличие от обычной ошибки upload_max_filesize, файл может успешно загрузиться, а сбой возникает уже во время обработки внутри PHP. Увеличение времени запроса не решает проблему частично записанных данных и занятого работника.

Возможная причинаКак узнатьЧто делать
Установлен короткий request_terminate_timeoutFPM останавливает работника через заданный период обслуживания запроса, даже когда код ещё занят обработкой.В журнале FPM есть execution timed out ... terminating и затем сообщение о завершении процесса.Сопоставить лимит со временем импорта и разделить обработку на порции.
Сработал другой предел до PHP-FPMNginx fastcgi_read_timeout, PHP max_execution_time или клиентское ожидание обрывают ответ по другой причине.В Nginx upstream timed out, но нет сообщения FPM о принудительном завершении.Разграничить записи журналов по одной операции.
Импорт выполняется без контрольных точек и повторных попытокВесь архив разбирается в одном HTTP-запросе; ошибка оставляет часть строк внесёнными.Повторный импорт создаёт дубли или результаты частично появляются.Сделать идемпотентное порционное выполнение с учётом состояния.

#Диагностика и пошаговое устранение

  1. Зафиксируйте границу между загрузкой файла и его обработкойВ браузере начните тестовый импорт небольшого обезличенного файла. Запишите размер, количество строк, время нажатия «Импортировать», последнюю отображённую стадию и код ответа. Если файл вообще не попал на сервер и ошибка возникает мгновенно, сначала проверьте upload_max_filesize и лимит Nginx — эта инструкция касается сбоя после начала PHP-обработки.
  1. Найдите конкретный текст о завершении процесса в журналеОткройте в панели сервера журнал ошибок нужного пула PHP-FPM. По SSH для стандартного systemd-сервиса используйте sudo journalctl -u php8.2-fpm --since "30 min ago" --no-pager с заменой версии. Ищите строки вроде execution timed out (60.000000 sec), terminating и child ... exited on signal 15. Если таких строк нет, сопоставьте время с журналом Nginx, чтобы не обвинять FPM по одному ответу 504.
    Linux · Терминал (Bash)КомандаНужен sudo
    Только чтение журнала systemd. Пример имени службы для Debian PHP 8.2; для панели/другой версии смотрите её собственный журнал.
    sudo journalctl -u php8.2-fpm --since "30 min ago" --no-pager
  1. Проверьте активный предел FPM и другие таймауты по цепочкеВ конфигурации конкретного пула найдите request_terminate_timeout. Запишите значение с единицами: 60s означает 60 секунд, 0 выключает ограничитель. Отдельно проверьте max_execution_time в PHP и fastcgi_read_timeout в конфигурации Nginx. Таймаут Nginx относится к промежутку ожидания данных между чтениями, а не обязательно к общей продолжительности передачи. Не изменяйте все три величины заодно: требуется доказательство сработавшего предела.
  1. Проверьте сохранность данных перед повторомЕсли импорт мог остановиться посередине, сначала откройте в панели приложения список загруженных записей и сравните их количество с файлом. Сохраните резервную копию затронутой базы и файла импорта до повторной попытки. Обсудите с разработчиком уникальный идентификатор записей и возможность безопасного повторного запуска; простой повтор часто создаёт дубликаты. Не запускайте очистку таблиц ради повторного импорта.
  1. Предпочтите порционную обработку, а не бесконечный HTTP-запросРазработчик должен отделить приём файла от обработки: после загрузки создать задачу со статусом, читать строки порциями, фиксировать номер последней обработанной записи и сохранять результат в транзакциях разумного размера. В браузере пользователь должен видеть ход задачи и сообщение о завершении. Для PHP CLI или очереди задач настройте ограничение числа параллельных импортов, ошибки, повторное исполнение и доступ к файлу без раскрытия его публично.
  1. Используйте ограниченное временное увеличение только для подтверждённого случаяЕсли архитектуру импорта нельзя изменить сразу, а импорт ограничен администраторами и проверены RAM/база/прокси, временно увеличьте request_terminate_timeout только в соответствующем пуле на заранее рассчитанное значение. Например, из 60s в 120s при измеренной операции 75s; это иллюстрация, не гарантия. Запишите исходный лимит и согласуйте период диагностики: более длинный запрос занимает процесс, а клиенты всё равно могут завершить ожидание.
  2. Только пример временной диагностики для подтверждённого запроса ~75 секунд
    INI
    Только пример временной диагностики для подтверждённого запроса ~75 секунд. Не копируйте без измерений и оценки рисков.
    request_terminate_timeout = 120s
  1. Проверьте и примените конфигурацию без остановки всех сайтовПосле резервного копирования файла пула выполните проверку нужного PHP-FPM, например sudo php-fpm8.2 -t. Если тест успешен, используйте sudo systemctl reload php8.2-fpm; при ошибке восстановите файл, не выполняйте reload. Учитывайте, что reload не продлевает уже выполняющийся запрос: новый лимит проверяйте на следующей тестовой задаче.
    Linux · Терминал (Bash)С осторожностьюНужен sudo
    Для Debian PHP 8.2, с правами администратора. Версию и службу следует заменить; reload только после успешной проверки. Команда перезагрузки выполняется только при успешной проверке конфигурации (оператор &&). При ошибке исправьте конфигурацию и повторите проверку; не запускайте перезагрузку вручную.
    sudo php-fpm8.2 -t && sudo systemctl reload php8.2-fpm

    Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.

  1. Повторите тест на копии данных и зафиксируйте откатЗапустите контролируемый импорт в тестовой копии базы, после завершения сравните число строк, контрольные суммы и журнал приложения. При отсутствии прерываний проверьте повторный запуск: он не должен размножать записи. Если FPM продолжает убивать процесс или Nginx отвечает 504, восстановите исходный таймаут и разберите другой ограничитель. Даже если временное увеличение помогло, замените долгий HTTP-импорт фоновой работой в плановом исправлении.

#Как проверить результат и что предпринять при неуспехе

Успех — обработка тестового файла завершается полностью, подтверждён итоговый счёт записей, повтор не создаёт дублей, FPM не завершает работников по таймауту. При расхождении количества записей вернитесь к резервной копии в тестовой среде и выясните точку сбоя; не повторяйте импорт в живую базу без стратегии восстановления.

Так эту ошибку тоже называют

PHP-FPM: server reached pm.max_children setting — причины и решение Предупреждение PHP-FPM «server reached pm.max_children setting» означает, что все процессы заняты. Рассчитайте max_children по памяти, найдите долгие запросы через slowl… Сайты, серверы и хостинг PHP-FPM Linux PHP-FPM: как рассчитать pm.max_children по памяти — причины и решение Предупреждение pm.max_children reached в PHP-FPM означает исчерпание пула процессов. Рассчитайте max_children по доступной памяти и среднему размеру процесса, выберите р… Сайты, серверы и хостинг PHP-FPM Linux PHP-FPM: запросы выполняются медленно, в логе slowlog — причины и решение Медленные запросы и таймауты в PHP-FPM (502/504) исправляются включением slowlog, настройкой request_terminate_timeout, fastcgi_read_timeout в nginx, оптимизацией запрос… Сайты, серверы и хостинг PHP-FPM Linux PHP-FPM: connect() to unix socket failed (13: Permission denied) — причины и решение Ошибка «connect() to unix:/run/php/php-fpm.sock failed (13: Permission denied)» исправляется настройкой listen.owner, listen.group и listen.mode в пуле PHP-FPM под польз… Сайты, серверы и хостинг PHP-FPM Linux PHP-FPM: server reached pm.max_children и ответы 503/504 — причины и решение Предупреждение значит, что все процессы заняты. Найдите медленные запросы, увеличьте max_children при наличии памяти и включите кэширование. Сайты, серверы и хостинг PHP-FPM Linux

Источники и обновления

Последнее обновление статьи: 2 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.