Настройку PHP-FPM на небольшом VPS стоит начинать с memory budget, а не со случайного увеличения `pm.max_children`. Главный вопрос - сколько одновременных PHP-запросов выдержит сервер, сохранив достаточный запас RAM для database, OS и cache.
Сначала измерьте один worker
Посмотрите реальный RSS PHP-FPM процессов под типичной нагрузкой. Если один worker потребляет около 90 MB, двадцать workers могут занять примерно 1.8 GB только под PHP. Это пример, а не универсальная норма - измеряйте своё приложение.
Рабочий memory budget для VPS с 4 GB
| Компонент | Зачем ему RAM |
|---|---|
| OS + system services | базовая работа и headroom |
| Database | buffers, cache, connections |
| PHP-FPM | worker count × реальный RSS |
| Cache / monitoring / panel | дополнительный постоянный overhead |
гайд по оптимизации WordPress полезен потому, что tuning workers не исправит тяжёлый plugin или плохой query. статья о выборе database server помогает учесть другого крупного потребителя RAM.
dynamic или ondemand?
dynamic
Хорошая отправная точка для меняющегося web traffic, если spare workers и limits выставлены по измерениям.
ondemand
Может быть удобен при низком или нерегулярном traffic, когда хочется уменьшить память idle workers.
Как найти реальный предел
- измерьте peak concurrency;
- посмотрите request duration;
- следите за queue и событиями `max_children reached`;
- одновременно проверяйте swap, DB latency и CPU;
- меняйте один параметр и измеряйте снова.
На Unmanaged VPS такой tuning полностью входит в вашу ответственность. Если хотите передать операции с OS и web stack, сравните с Managed VPS и уточните границу performance tuning.
Простая формула - только начальная оценка
Верхнюю границу можно приблизительно оценить так:
RAM, доступная PHP ÷ средний RSS одного реального worker = теоретическое количество workers.
Не копируйте это число напрямую в `pm.max_children`. Нужен headroom для traffic spikes, роста DB memory, OS page cache и дорогих requests. Production limit обычно должен быть ниже чисто теоретического максимума.
Какой metric на что указывает?
| Сигнал | Возможная причина |
|---|---|
| `max_children reached` | низкий concurrency limit или слишком долгие requests |
| queue растёт, CPU свободен | worker limit или blocking operation |
| растёт swap | workers, DB и cache вместе превышают RAM |
| CPU насыщен и queue растёт | добавление workers может ухудшить ситуацию |
| несколько requests очень медленные | важнее slowlog/application profiling |
FPM status и slowlog - часть tuning
Настройка - это не только `top`. FPM status показывает active/idle workers, queue и saturation process manager. Slowlog помогает увидеть PHP call path запросов, которые работают слишком долго.
24-часовой tuning cycle
- зафиксируйте baseline в реальный peak;
- измените один основной parameter;
- наблюдайте такой же traffic pattern;
- сравните p95 response time, queue, CPU, RAM и errors;
- сделайте rollback, если стало хуже.
Главная ошибка - путать capacity problem с application problem. Если один request работает три секунды из-за плохого query, больше workers просто запустят больше медленных requests одновременно.
