Почему PHP-FPM процессы занимают всю доступную память? Потому что PHP-FPM не ограничивает суммарное потребление RAM: каждый воркер вправе вырасти до значения memory_limit, а их количество задаёт pm.max_children, поэтому при пиковой нагрузке общее потребление равно произведению числа воркеров на лимит одного процесса и легко выходит за пределы сервера. Дополнительно память удерживают долгие запросы к базе, тяжёлые выборки, утечки в сторонних расширениях и отсутствие перезапуска воркеров после обработки запросов.
Быстрая диагностика выглядит так: посмотрите реальное потребление одного процесса через ps с сортировкой по памяти, сравните его с memory_limit, проверьте значение pm.max_children и тип пула — static держит все воркеры постоянно, dynamic освобождает лишние, ondemand запускает по требованию. Затем задайте pm.max_requests, чтобы воркер перезапускался после заданного числа запросов, включите slowlog для поиска медленных скриптов и request_terminate_timeout для обрыва зависших. Отдельно проверьте кэш OPcache и размер буферов MySQL — часто память уходит именно туда, а не в сам PHP.
Готовое решение внедряется в четыре этапа: аудит текущих параметров пула и профиля нагрузки, расчёт безопасного pm.max_children исходя из доступной RAM с запасом на базу и систему, настройка лимитов и мониторинга с алертами по памяти, затем плановая оптимизация кода и запросов, которые съедают ресурс. Такой порядок убирает аварийные перезагрузки и держит стабильный отклик под пиками — если нужен расчёт под ваш сервер и трафик, эту работу можно заказать целиком.