Процессор свободен, а PHP-запросы ждут: как увидеть очередь PHP-FPM

Карточка товара открывается несколько секунд, а средняя загрузка процессора остаётся небольшой. Это ещё не доказательство, что серверу хватает ресурсов. Динамический запрос может ждать свободный процесс PHP-FPM; уже занятые процессы в это время могут ожидать базу или внешний сервис.

Я бы начала с более узкого вопроса: стояли ли запросы в очереди именно того пула PHP, который обслуживает магазин, в момент задержки? Ни процент CPU, ни одно старое максимальное значение сами по себе на него не отвечают.

Пул — группа процессов PHP-FPM. Свободный процесс принимает запрос, занятый обслуживает предыдущий. Если свободных процессов нет, запросы могут ждать перед пулом. Такой участок задержки отличается от времени, которое уже получивший запрос процесс тратит на работу приложения.

Среднее значение CPU по серверу способно скрыть нагрузку отдельного ядра. Обратная ситуация тоже возможна: процесс PHP занят запросом, но большую часть времени ждёт ответ другой системы. Поэтому свободный процессор не равен свободному пулу.

Если статус FPM уже собирается внутренним мониторингом, возьмите данные оттуда. Иначе попросите администратора подготовить доступ только для разрешённых внутренних запросов. Статус содержит сведения о ресурсах и запросах: открывать его всем посетителям сайта ради проверки не нужно.

Сохраните несколько снимков в течение самого замедления и один после него. Рядом запишите время с часовым поясом, затронутый маршрут магазина, время ответа и ошибки за тот же интервал. Эти данные относятся к одному пулу; после перезапуска FPM его значения сбрасываются.

Для запроса администратору достаточно такой формулировки: «Во время медленного открытия карточки проверьте пул этого сайта: есть ли текущая очередь, остаются ли свободные процессы и достигается ли настроенный предел. Сохраните показатели вместе со временем ответа, чтобы сравнить их на одной шкале». Это запрос на наблюдение, а не на изменение конфигурации.

Чтобы проверить арифметику, при подготовке статьи мы выполнили отдельный расчёт непрерывного потока. В нём четыре процесса, равномерный вход 10 запросов в секунду, начальная очередь нулевая. Один запрос занимает процесс 0,5 секунды. Идеальная пропускная способность тогда равна 4 / 0,5 = 8 запросам в секунду, а очередь растёт на 2 запроса в секунду.

Расчёт дал 10 ожидающих запросов через 5 секунд и 20 через 10. Во втором варианте мы сохранили четыре процесса и тот же вход, но сократили занятость на запрос до 0,25 секунды. Расчётная способность стала 16 запросов в секунду, и очередь в этой модели не росла.

Проверку можно повторить в Python 3. Следующие строки выводят две расчётные длины очереди для каждого момента:

Вывод расчёта: для 0 секунд — [0, 0], для 5 — [10, 0], для 10 — [20, 0]. Модель намеренно не учитывает дискретные завершения, всплески, ошибки и изменение длительности запросов. Она показывает влияние времени занятости процесса. Чтобы прогнозировать реальный магазин, нужны его собственные измерения.

Нулевая очередь в одном снимке не исключает короткий пик между измерениями. И наличие очереди не сообщает, что именно задержало занятые процессы. Полезный результат проверки — временная связь между ожиданием и замедлением, а затем установление причины длительных запросов.

A product card takes several seconds to open, yet average CPU usage remains low. This alone does not prove the server has sufficient resources. A dynamic request may be waiting for a free PHP-FPM process; meanwhile, already occupied processes might be waiting for the database or an external service.

I would start with a more specific question: were requests in the queue for the exact PHP pool serving the store at the moment of the delay? Neither CPU percentage nor a single historical maximum value answers this on their own.

A pool is a group of PHP-FPM processes. A free process accepts a request; a busy one handles the previous request. If no free processes exist, requests may wait before the pool. This waiting period differs from the time a process already holding a request spends executing application code.

Average CPU usage across the server can mask the load on a specific core. The reverse situation is also possible: a PHP process is busy handling a request but spends most of its time waiting for a response from another system. Therefore, an idle processor does not equal an available pool.

If the FPM status is already being collected by internal monitoring, retrieve the data from there. Otherwise, ask the administrator to prepare access restricted only to authorized internal requests. The status contains information about resources and requests; there is no need to expose it to all site visitors for verification purposes.

Save several snapshots during the slowdown and one after it. Record the time with the time zone, the affected store route, the response time, and any errors for that same interval. These data points belong to a single pool; after an FPM restart, its values are reset.

For a request to the administrator, the following phrasing is sufficient: 'During the slow loading of the product card, check the pool for this site: is there a current queue, are there still idle processes, and is the configured limit being reached? Save the metrics along with the response time so they can be compared on the same scale.' This is a request for observation, not for configuration changes.

To verify the arithmetic, we performed a separate continuous flow calculation while preparing the article. It involves four processes, a uniform input of 10 requests per second, and an initial queue of zero. One request occupies a process for 0.5 seconds. The ideal throughput is then 4 / 0.5 = 8 requests per second, and the queue grows by 2 requests per second.

The calculation yielded 10 pending requests after 5 seconds and 20 after 10. In the second variant, we kept four processes and the same input but reduced the request processing time to 0.25 seconds. The calculated capacity became 16 requests per second, and the queue in this model did not grow.

The check can be repeated in Python 3. The following lines output two calculated queue lengths for each moment:

Calculation output: for 0 seconds — [0, 0], for 5 — [10, 0], for 10 — [20, 0]. The model intentionally does not account for discrete completions, spikes, errors, or changes in request duration. It shows the impact of process busy time. To forecast a real store, its own measurements are needed.

A zero queue in a single snapshot does not rule out a short spike between measurements. The presence of a queue does not indicate what specifically delayed the busy processes. The useful result of the check is establishing a temporal link between waiting and slowdown, followed by identifying the cause of long-running requests.