PHP-FPM ломает сайт не сам по себе — чаще его убивает неправильная настройка пула

PHP-FPM ломает сайт не сам по себе — чаще его убивает неправильная настройка пула

Когда WordPress начинает тормозить, а CPU прыгает, первым делом смотрят не в тему и плагины, а в PHP-FPM. Типовые симптомы: очереди запросов, 502 под нагрузкой, медленные админка и REST-запросы. В большинстве случаев проблема не в «слабом сервере», а в том, что пулу дали мало процессов или, наоборот, слишком много.

Проверьте базовые вещи:
— pm = ondemand, если трафик редкий и важна экономия RAM
— pm = dynamic, если нагрузка ровная и нужны быстрые ответы
— pm.max_children упирается в память, а не в желание «поставить побольше»
— request_terminate_timeout нужен, чтобы зависшие PHP-скрипты не висели бесконечно

Если сайт резко становится медленным в пике, смотрите логи FPM и статус пула: там видно, копятся ли очереди, не исчерпаны ли воркеры и не забиты ли медленными запросами одни и те же обработчики. Отдельно полезно включить slowlog: он быстро показывает, какой код реально тормозит, а не только дает общую «просадку».

Главное правило: PHP-FPM настраивают от памяти и реального профиля нагрузки, а не по шаблону с форума. Сначала посчитайте, сколько RAM съедает один процесс, потом уже подбирайте pm и max_children — так WordPress перестает «плыть» под нагрузкой.