PHP-FPM LinuxPHP 8.xNginx/Apache

PHP-FPM: растёт память пула при pm.max_requests = 0

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

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

Значение 0 не ограничивает количество запросов, выполняемых одним рабочим процессом. Это не доказательство утечки; pm.max_requests может уменьшить накопление памяти у отдельных работников, но не исправит код, удерживающий большие объекты.

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

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

Процессы пула PHP-FPM со временем используют всё больше памяти, а в конфигурации установлен pm.max_requests = 0. Как отличить утечку в приложении от нормального кэширования и настроить перезапуск работников без маскировки проблем. Значение 0 не ограничивает количество запросов, выполняемых одним рабочим процессом. Это не доказательство утечки; pm.max_requests может уменьшить накопление памяти у отдельных работников, но не исправит код, удерживающий большие объекты.

Возможная причинаКак узнатьЧто делать
Код или расширение сохраняет память между запросамиРасход RSS одного дочернего процесса постепенно растёт на одинаковых задачах, даже когда параллелизм невелик.Один PID накапливает больше RSS после сотен однотипных обращений.Найти причину в приложении и измерить процесс на повторном тесте.
Режим static/dynamic запускает слишком много работниковБольшой pm.max_children и pm = static удерживают много процессов, расходуя общую память даже без запросов.Растёт общая сумма RSS, но каждый процесс примерно одинакового размера.Проверить режим и разумность числа процессов.
Считается память с разделяемыми страницами или кэшемRSS нескольких процессов включает общие страницы; свободная память Linux расходуется на файловый кэш и может освобождаться.free -h показывает достаточный available, а RSS кажется большой суммой.Сопоставить available, PSS при наличии инструмента и реальные OOM.

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

  1. Проверьте, действительно ли память растёт со временемПодключитесь к серверу по SSH из терминала Windows/Linux. Во время низкой нагрузки запишите дату, free -h и несколько рабочих процессов PHP-FPM; через час при похожем трафике повторите. Фиксируйте PID и RSS конкретных процессов, а не только общий объём, который показывает панель. Если значение available остаётся высоким и страницы отвечают нормально, высокая величина Used сама по себе не означает аварии.
  2. Дополнительная команда по теме
    Linux · Терминал (Bash)Команда
    Просмотровые команды Linux по SSH; rss — КиБ физической памяти, etime — возраст процесса. По PID можно сравнить один и тот же процесс в двух снимках.
    date -Is
    free -h
    ps -eo pid,ppid,rss,etime,cmd --sort=-rss | head -n 30
  1. Найдите активные параметры пула и проверьте их смыслВ панели хостинга найдите конфигурацию конкретного пула; выпишите pm, pm.max_children, pm.max_requests и при dynamic — настройки числа запасных процессов. Значение pm.max_requests = 0 означает, что принудительного обновления работника по количеству запросов нет. При static все работники обычно находятся в памяти постоянно, а ondemand создаёт и завершает их по потребности. Не меняйте режим и пределы одновременно.
  1. Измерьте память одного работника до и после одинаковых запросовВ тестовой среде выберите безопасный URL, который не вносит изменения в базу. Сделайте несколько последовательных обращений вручную, фиксируя RSS и PID в ps. Из-за распределения запросов по разным процессам рост памяти должен подтверждаться на том же PID, иначе вывод преждевременен. При наличии smem можно смотреть PSS, чтобы не суммировать общую память несколько раз; не устанавливайте новый инструмент на продуктивном сервере без согласования.
  1. Сопоставьте рост с реальными операциями приложенияПроверьте журнал PHP, долгие запросы, создание изображений, обработку больших JSON, работу OPcache и расширений. Если память растёт после конкретной операции, проверьте результат в профилировщике на тестовом окружении и исправьте накопление объектов или временных массивов. Принудительная перезапись процессов скрывает симптомы, но не является доказательством исправления; возможен и повторный рост с каждым обращением.
  1. Подберите ограниченный pm.max_requests как временную защитуКогда в одинаковых условиях подтверждён рост памяти отдельного работника и есть резерв CPU, установите в конфигурации пула, например, pm.max_requests = 500 как исходный эксперимент. После 500 обслуженных запросов работник будет заменён, поэтому память накопившегося процесса освобождается при завершении. Реальный интервал подбирайте по замерам: слишком малое число увеличивает стоимость создания процессов и может снизить производительность. Сохраните исходный 0 для отката.
  2. Пример начального испытания, не универсальный норматив
    INI
    Пример начального испытания, не универсальный норматив. Устанавливать только после измерений и резервной копии конфигурации.
    pm.max_requests = 500
  1. Убедитесь, что проблема не вызвана неподходящим pm.max_childrenЕсли памяти не хватает из-за множества одновременно запущенных процессов, уменьшение интервала pm.max_requests мало поможет. Подсчитайте доступный бюджет ОЗУ с учётом БД, OS и остальных сайтов и оцените предел pm.max_children отдельно. Не сокращайте его до числа, которое вызывает очереди и 502/504 при обычной нагрузке. При нехватке памяти лучше устранить тяжёлый код и пиковые запросы.
  1. Проверьте и примените новую конфигурацию аккуратноСделайте копию пула и запустите sudo php-fpm8.2 -t для Debian PHP 8.2 либо штатный тест вашей установки. При успехе sudo systemctl reload php8.2-fpm. Если есть ошибка конфигурации, верните 0 из копии и повторите проверку. Отслеживайте перезапуски работников по PID: смена PID после заданного количества запросов нормальна, а частые аварии с SIGSEGV — отдельная проблема.
    Linux · Терминал (Bash)С осторожностьюНужен sudo
    Пример для Debian 8.2: тест конфигурации обязателен; менять версию и службу в соответствии с сайтом, права администратора. Команда перезагрузки выполняется только при успешной проверке конфигурации (оператор &&). При ошибке исправьте конфигурацию и повторите проверку; не запускайте перезагрузку вручную.
    sudo php-fpm8.2 -t && sudo systemctl reload php8.2-fpm

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

  1. Наблюдайте не только память, но и задержки после измененияНесколько часов или сопоставимое количество запросов отслеживайте available RAM, возраст работников, количество 502, время ответа и сообщения FPM. Если память стабилизировалась без роста отказов, оставьте согласованное значение и продолжите поиск утечки в тестовой среде. Если процессы пересоздаются слишком часто, а задержки выросли, верните pm.max_requests = 0, проверьте конфигурацию и reload; передайте разработчику снимки памяти и условия воспроизведения.

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

Успех — память стабилизируется при сопоставимой нагрузке, нет новых отказов OOM и массовых 502, задержки сайтов не растут. Если память не снижается, проверьте количество одновременно запущенных процессов, общий OPcache и состав приложения; при ухудшении верните прежний параметр из копии.

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

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. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.