Как работает PHP-FPM process model и какие параметры важны под нагрузкой?

Конфигурационный файл пула

; /etc/php/8.3/fpm/pool.d/www.conf

[www]
user  = www-data
group = www-data

; Unix-сокет быстрее TCP для Nginx на том же хосте
listen = /run/php/php8.3-fpm.sock

pm                   = dynamic
pm.max_children      = 50   ; верхний лимит воркеров
pm.start_servers     = 10   ; стартовое количество
pm.min_spare_servers = 5    ; минимум простаивающих
pm.max_spare_servers = 20   ; максимум простаивающих
pm.max_requests      = 500  ; перезапуск воркера после N запросов (борьба с утечками памяти)

request_terminate_timeout = 30s  ; убить воркер если запрос висит дольше
request_slowlog_timeout   = 5s   ; писать slow-log при превышении
slowlog                   = /var/log/php-fpm/slow.log

; Передаём переменные окружения в воркер
env[APP_ENV]       = production
env[DATABASE_URL]  = $DATABASE_URL

; Статус-страница для мониторинга
pm.status_path = /fpm-status

Как работает PHP-FPM

PHP-FPM (FastCGI Process Manager) — реализация FastCGI для PHP. Nginx или Apache передают HTTP-запрос через FastCGI-сокет (Unix-socket или TCP) мастер-процессу FPM, который делегирует его одному из worker-процессов пула. Worker выполняет PHP-скрипт и возвращает ответ через тот же сокет.

Архитектура: один мастер-процесс управляет несколькими пулами (pool), каждый пул — набор форк-процессов с изолированным php.ini-окружением.

Режимы управления процессами (pm)

• static — фиксированное число процессов (pm.max_children). Минимум латентности, но фиксированный расход памяти.
• dynamic — число процессов плавает между min и max. Баланс памяти и производительности; используется чаще всего.
• ondemand — процессы создаются по запросу и убиваются после pm.process_idle_timeout. Для редко запрашиваемых сервисов.

Расчёт pm.max_children

# Посмотреть реальный расход памяти одним воркером
ps --no-headers -o rss -p $(pgrep -d',' php-fpm) | awk '{s+=$1} END {printf "%.0f MB\n", s/NR/1024}'

# Формула: max_children = свободная_RAM / средний_размер_воркера
# Пример: 4096 MB / 80 MB = ~51, ставим 50 с запасом

Мониторинг через status-страницу

curl http://127.0.0.1/fpm-status?full
# Выводит: pool, process manager, start time, accepted conn,
# listen queue, idle/active processes, slow requests и т.д.

Nginx — передача запросов в FPM

location ~ \.php$ {
    fastcgi_pass   unix:/run/php/php8.3-fpm.sock;
    fastcgi_index  index.php;
    include        fastcgi_params;
    fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_read_timeout 30;
}

Подводные камни

• Выставить pm.max_children слишком высоко: при нехватке RAM ОС начнёт свопировать, и латентность резко вырастет.
• Не задать pm.max_requests: воркеры с утечками памяти растут до OOM и убивают весь сервер.
• Использовать TCP (127.0.0.1:9000) вместо Unix-сокета при Nginx и FPM на одном хосте — лишние syscall и ~20% накладные расходы.
• Игнорировать listen queue в статусе: очередь > 0 — сигнал, что воркеров не хватает.
• Не настраивать request_terminate_timeout: зависший скрипт занимает воркер и со временем блокирует весь пул.
• Запускать несколько приложений в одном пуле: конфликт параметров php.ini, нет изоляции пользователей.
• Забыть перезапустить FPM после смены конфига: systemctl reload php8.3-fpm применяет изменения без полного рестарта.

• Отвечать определением без production-сценария.
• Не называть runtime boundary, security boundary или failure mode.
• Игнорировать версию API, observability и тестовую проверку.

• Объясняет механизм своими словами и без выдуманных API.
• Называет реальные риски, диагностику и критерий корректности.
• Связывает ответ с текущей документацией и миграционными ограничениями.