К списку статей DevOps и Инфраструктура

Тюнинг производительности бэкенда: Оптимизация пулов PHP-FPM, буферов Nginx и OPcache

Опубликовано: 28.09.2026 в 15:00

Как выжать максимум из текущего железа: ликвидация скрытых узких мест бэкенда

Часто при падении сайта под нагрузкой владельцы бизнеса сразу принимают решение покупать более дорогой сервер. Однако в 80% случаев проблема кроется не в нехватке физических ресурсов процессора или RAM, а в дефолтных настройках системных пакетов. Стандартная конфигурация веб-сервера из коробки рассчитана на слабые домашние ПК разработчиков, чтобы не перегрузить систему. В условиях реального продакшена некорректные лимиты процессов PHP-FPM и буферов Nginx приводят к тому, что сервер начинает отвечать ошибками 502 Bad Gateway или 504 Gateway Time-out задолго до того, как ресурсы железа будут исчерпаны. Мы разберем, как правильно рассчитать и настроить параметры для обеспечения максимальной пропускной способности бэкенда.

Поиск баланса между оперативной памятью и процессами PHP-FPM

PHP-FPM обрабатывает каждый входящий запрос в отдельном изолированном процессе. Самая частая причина падения бэкенда — использование режима pm = dynamic с некорректным лимитом максимального количества воркеров (pm.max_children). Если это число слишком велико, при наплыве трафика процессы PHP мгновенно съедят всю доступную RAM, сервер уйдет в жесткий своп и зависнет. Если число слишком мало — пользователи выстроятся в очередь, время ожидания ответа превысит лимиты Nginx, и сайт начнет отдавать 504 ошибку. Для продакшн-серверов со стабильным трафиком рекомендуется использовать статический режим (pm = static), где количество процессов фиксировано и выделено под свободный объем памяти.

Шаг 1: Конфигурация пула PHP-FPM для стабильной работы

Переводим пул веб-сайта в статический режим работы и фиксируем количество процессов в файле конфигурации /etc/php/8.3/fpm/pool.d/www.conf

ini

; Тюнинг пула процессов PHP-FPM для продакшн-сервера
pm = static
pm.max_children = 100
pm.max_requests = 1000
request_terminate_timeout = 60
catch_workers_output = yes

Шаг 2: Включение кэширования скомпилированного кода через OPcache

Каждый запуск PHP-скрипта без OPcache заставляет сервер заново читать файлы с диска, парсить их и компилировать в байт-код. Включение кэширования в php.ini позволяет хранить скомпилированный код в оперативной памяти, увеличивая скорость работы Laravel-приложения в 3–5 раз.

php

; Настройка параметров OPcache в php.ini
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0 ; Выключаем проверку файлов на проде для максимальной скорости
opcache.jit=tracing ; Включение JIT компилятора

Итоги и резюме

Результат системного тюнинга

Тонкая настройка связки Nginx и PHP-FPM позволяет текущему серверу выдерживать нагрузки в несколько раз выше первоначальных без покупки дополнительного оборудования. Время ответа бэкенда становится стабильным, исчезают внезапные всплески 502 ошибок в моменты пикового трафика, а утилизация процессора распределяется равномерно. Проект работает плавно, эффективно используя каждый мегабайт оплаченной оперативной памяти.

Была ли полезна статья?

Оценки помогают мне понимать, какие темы вам наиболее интересны.

Чтобы оценить, войдите или зарегистрируйтесь.