PHP-FPM тормозит сайт чаще из-за настроек пула, чем из-за самого PHP

PHP-FPM тормозит сайт чаще из-за настроек пула, чем из-за самого PHP

PHP-FPM — это менеджер процессов, и его задача простая: быстро принимать запросы и не держать сервер в очереди. Если сайт «плавает» под нагрузкой, сначала смотрят не на CPU, а на пул: хватает ли детей, не упирается ли он в память, не копятся ли запросы в очереди.

Проверьте базовые параметры:
— pm = dynamic или ondemand по сценарию нагрузки
— pm.max_children: если мало, запросы ждут; если много, съедается RAM
— pm.max_requests: нужен, чтобы периодически перезапускать утечки памяти
— request_terminate_timeout: защищает от зависших скриптов

Отдельно смотрите на slowlog и access log пула. Медленные запросы WordPress часто сидят в плагинах, но в логах PHP-FPM видно, какой именно код держит воркер. Если очереди растут, а свободных процессов нет, проблема почти всегда в балансе между памятью и количеством воркеров.

Для WordPress полезно держать отдельный пул под сайт, а не один общий на весь сервер. Так проще ограничить ресурсы, точнее ловить узкие места и не дать одному проекту забить всех соседей.

Если PHP-FPM настроен правильно, сайт не «ускоряется магией» — он просто перестаёт ждать лишнего.