Использование страницы состояния PHP-FPM для анализа производительности

Какую информацию о пуле отображает страница состояния

Страница состояния PHP-FPM показывает, как работает конкретный бассейн Обработанные запросы PHP: в том числе количество активных или свободных процессов, а также наличие запросов в очереди. Условием является то, что приложение действительно обслуживается PHP-FPM. Версия PHP, отображаемая в командной строке, сама по себе не указывает ни на это, ни на версию соответствующей службы FPM.

Поэтому сначала определите используемую версию FPM и пул, в который веб-сервер перенаправляет приложение. Сюда входят используемый Unix-сокет или TCP-прослушиватель, а также маршрутизация в соответствующем виртуальном хосте. Это сопоставление важно для того, чтобы при последующем запросе статуса случайно не был указан другой пул.

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

Запрос — это, в первую очередь, Снимок: Между двумя запросами могут возникать и исчезать короткие очереди. Другие значения учитывают события, произошедшие с момента запуска FPM; при перезапуске они сбрасываются. Поэтому для получения наглядной динамики следует сохранять время запроса и идентификатор пула вместе с самими значениями.

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

Понимание роли рабочих и менеджеров процессов

Менеджер процессов определяет, как пул предоставляет своих рабочих процессов. При static их количество остается неизменным. dynamic адаптирует количество в пределах заданных настроек в соответствии с потребностями; ondemand запускает процессы по мере необходимости. Таким образом, ожидаемый объем свободных мощностей зависит также от выбранного режима работы.

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

Даже кратковременное исчерпание резерва само по себе ещё не является доказательством постоянного дефицита. Сравните повторные запросы с настроенными Предельное значение процесса и временными интервалами, в которые пользователи действительно замечают задержки. Так ты сможешь лучше отличить кратковременный пик нагрузки от повторяющейся перегрузки.

Большее количество рабочих процессов позволяет параллельно обрабатывать больше запросов, однако для этого требуется дополнительная память, а нагрузка на базы данных или внешние сервисы может возрасти. Если многие процессы ожидают выполнения одной и той же медленной операции, увеличение предельного значения не устранит причину проблемы. Поэтому перед тем, как pm.max_children измениться.

Для определения распределения обязанностей в стеке хостинга полезно сравнить Модуль NGINX и PHP-FPM. Он дополняет архитектурную перспективу; конкретные значения состояния и настройки диспетчера процессов тебе по-прежнему необходимо проверять в реально используемом пуле FPM.

Обеспечение безопасности доступа к статусам и FastCGI

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

Ограничь Доступ по протоколу HTTP на внутренние запросы или на IP-адреса клиентов, явно указанные в списке. При этом необходимо проверить, какой адрес веб-сервер фактически воспринимает как адрес клиента, если перед ним установлен прокси-сервер. Защита должна распространяться на маршрутизацию страницы состояния и должна быть проверена перед предоставлением доступа.

В любом случае обеспечьте Доступ к FastCGI самостоятельно. В случае Unix-сокета важно учитывать владельца и права доступа; в случае TCP необходимо проверять сетевую привязку и разрешённых клиентов. Блокировка на веб-сервере не защищает порт FastCGI, доступ к которому можно получить отдельно из ненадежной сети.

Проект PHP зафиксировал уязвимость XSS в выводе статуса FPM под номером CVE-2026-6735. Исправленные версии включают PHP 8.4.21 и 8.5.6. Для других ветвей версий и дистрибутивных пакетов проверьте соответствующий уровень безопасности или обратно портированные патчи, а не делайте выводы о защите, основываясь исключительно на указанном номере версии.

Обновление не заменяет ограничение доступа: даже исправленная страница состояния может по-прежнему раскрывать операционные данные. Ограничьте доступ по HTTP и работу прослушивателя только для предусмотренного круга пользователей и учитывайте эти два уровня защиты при последующих изменениях в маршрутизации.

Размещение страницы состояния в защищённом режиме

Сначала определите, какой пул FPM обрабатывает данное приложение и через какой сокет или TCP-адрес веб-сервер подключается к нему. При наличии нескольких пулов запрос о состоянии относится к тому пулу, в который он перенаправляется. Сама по себе версия PHP, указанная в командной строке, не показывает, какой сервис FPM отвечает за данное приложение.

В файле конфигурации соответствующего пула следующий фрагмент кода активирует Путь статуса. Это не файл PHP, который нужно создать в каталоге документов. Данный фрагмент кода представляет собой пример конфигурации и предполагает, что у вас есть права на редактирование конфигурации пула.

pm.status_path = /fpm-status

Настройте на веб-сервере соответствующий маршрут, который будет перенаправлять запросы по этому пути напрямую через FastCGI в выбранный пул. Обычная система маршрутизации приложения не должна перехватывать этот запрос. Ограничьте доступ по HTTP только внутренними запросами или известными IP-адресами клиентов и обеспечьте безопасность сокета FastCGI независимо от этого с помощью прав доступа, сетевых ограничений и списка разрешённых клиентов.

Перед запуском обновления проверьте конфигурацию как веб-сервера, так и FPM с помощью процедур проверки, предусмотренных в вашей среде. Убедитесь, что вы изменяете нужную службу и пул, а также что ограничение доступа действует и для пути состояния. Простое задание пути ещё не делает данные доступными через HTTP.

Для уже настроенной локально защищённой среды следующая команда терминала считывает вывод в формате JSON. Она предполагает, что по указанному адресу доступен соответствующий локальный виртуальный HTTP-хост. В противном случае вам необходимо адаптировать адрес, маршрутизацию хоста и, при необходимости, TLS к вашей среде; выполнение этой команды не изменяет конфигурацию.

curl --fail --silent --show-error 'http://127.0.0.1/fpm-status?json'

В ответе обратите особое внимание на имя пула. Сообщение об ошибке или неожиданный вывод приложения могут указывать на неверную маршрутизацию; также доступ может быть заблокирован, что препятствует запросу. В таком случае проверьте соответствующую конфигурацию веб-сервера и журналы, а не спешите снимать защиту.

Как правильно интерпретировать и рассчитывать показатели

Значения статуса отражают разные временные интервалы: одни показывают состояние на момент запроса, другие — подсчитывают количество событий или фиксируют максимальное значение с момента запуска. Для диагностики это различие имеет большее значение, чем отдельное подозрительное значение. В приведенной ниже таблице приведены основные показатели.

Для Скорость соединенияты вычитаешь два значения из accepted conn отнимаешь одно от другого и делишь разницу на прошедшее время. Гипотетический расчетный пример, не основанный на измерениях: если показатель увеличивается с 12 000 до 12 600 за 60 секунд, то в среднем получается десять предполагаемых подключений в секунду. Из этого нельзя непосредственно сделать выводы ни о количестве просмотров страниц, ни о задержке приложения.

Сохраняйте время и идентификатор пула для каждой точки измерения. После перезапуска FPM значения состояния сбрасываются; поэтому разница, охватывающая этот перерыв, не является допустимой скоростью. Обнаруживайте снижение показателя счетчика или изменение момента начала и заново начинайте расчет для нового периода.

На сайте max children reached решающую роль играет менеджер процессов: в примере конфигурации PHP 8.4.21 описан счетчик для параметров `dynamic` и `ondemand`. В случае параметра `static` нельзя рассматривать нулевое значение как доказательство наличия свободных ресурсов. Для slow requests пороговое значение и Slowlog должны быть настроены соответствующим образом; пороговое значение определяет, какие именно длинные запросы будут вообще учитываться.

Сравнение форматов вывода и сведений о процессе

Краткая версия подходит для общего обзора всего пула. При выборе формата решающим фактором является то, собираетесь ли вы считывать значения вручную или регулярно обрабатывать их с помощью системы мониторинга. Параметр full добавляет в вывод сведения о процессе; он не является самостоятельным форматом обмена данными.

Кроме того, в руководстве по PHP описаны форматы XML и HTML. При автоматическом запросе данных проверьте фактически установленную версию FPM и её вывод, прежде чем полагаться на конкретные поля или сведения о процессах. В частности, следует обратить внимание на сочетание OpenMetrics и full проверить в собственной версии, вместо того чтобы безоговорочно исходить из данных отдельных процессов.

Die Продолжительность запроса В полной версии значение указано в микросекундах. Для активного процесса оно обозначает продолжительность обработки текущего запроса; для неактивного процесса — продолжительность обработки последнего запроса. Поэтому высокое значение для свободного рабочего процесса не означает, что он в данный момент занят обработкой запроса.

Поля last request cpu и last request memory при активных процессах отображаются как нуль, поскольку их оценка происходит только после завершения запроса. Таким образом, эти нулевые значения не означают отсутствие загрузки ЦП или памяти. Повторные запросы могут показать, остается ли процесс активным в течение длительного времени; однако они не заменяют полного трассирования приложения.

Анализ очередей и медленных запросов

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

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

Неоднократно запрашивай защищенный полный вывод во время заметной фазы. Длительная продолжительность запроса при одном и том же активном процессе может указывать на длительную занятость рабочего процесса; при этом проверьте состояние процесса, поскольку в случае неактивного процесса продолжительность относится к его последнему запросу. PID, URI и скрипт помогают в сопоставлении, но не дают полного трассирования.

Именно в случае с фронт-контроллером одно и то же имя скрипта может охватывать множество различных функций приложения. Поэтому дополните это наблюдение отслеживанием приложения и соответствующим образом настроенным Slowlog. Его пороговое значение определяет, какие длительные запросы будут учитываться; отсутствие записи не означает, что все запросы были быстрыми. О том, как более подробно классифицировать результаты, рассказывается в статье о Анализ журнала Slowlog PHP-FPM.

Для сопоставления зафиксируйте временной интервал и соответствующий пул. Так вы сможете, например, проверить, совпадает ли по времени медленный запрос к базе данных с загрузкой рабочих процессов или же очередь начала расти ещё раньше. Корреляция сужает круг поиска, но пока не заменяет проверку конкретного запроса.

Мониторинг и сбои на странице состояния

В случае повторяющихся пиков нагрузки регулярные запросы с защитой дают более достоверные результаты, чем единичные проверки, проводимые время от времени. JSON подходит для автоматизированной обработки; OpenMetrics является альтернативой, если версия PHP и клиент мониторинга совместимы. Сохраняйте для каждой точки измерения время и идентификатор пула, чтобы случайно не сравнивать разные пулы.

Обработай непросмотренные сообщения как отдельные события, а не как нулевые значения. Пробел может быть связан с сетью, защитой доступа или службой состояния; сам по себе он не означает ни пустого пула, ни сбоя приложения. Поэтому сохраняйте также ошибки и превышения времени ожидания при запросе, чтобы пробел оставался видимым при последующем анализе.

Кроме того, учитывай сброс накопленных счетчиков после перезапуска FPM. Отрицательная разница между двумя значениями не означает отрицательной скорости соединения; начните расчёт заново после сброса и учтите прерванный интервал. Время запуска и присвоение пула также помогают определить место такого разрыва в графике.

Если запрос статуса выполняется в том же пуле, что и приложение, он может сам ожидать, если все рабочие процессы заняты. Для такой ситуации предусмотрено pm.status_listen отдельный прослушиватель FastCGI с независимо работающим внутренним пулом. Он может обеспечивать диагностику состояния, когда основной пул занят; однако он не увеличивает его пропускную способность.

Для дополнительного прослушивателя требуется явно назначенная защищенная маршрутизация веб-сервера. Также обеспечь безопасность его доступа по FastCGI и после утверждения изменения проверь, действительно ли запрос возвращает желаемое состояние пула. Таким образом, диагностика останется отделенной от обычного пути приложения, не делая данные о состоянии общедоступными.

Анализ результатов обследования и выбор мер

Команда «ping» для FPM и страница состояния дают ответы на разные вопросы. Команда «ping» показывает, отвечает ли FPM на соответствующий запрос; она не предоставляет аналогичной информации о свободных рабочих процессах или ожидающих запросах. Поэтому успешное выполнение команды «ping» само по себе не означает, что можно не беспокоиться о загрузке пула приложений.

Если показатели процесса не совпадают с данными журналов или другими наблюдениями, сначала проверь привязку к пулу, время вызова и возможность перезапуска. Затем сверьте значения с другими доступными данными о процессе и эксплуатации. Сначала рассматривайте отклонение как невыясненный факт, а не делайте из него сразу вывод о причине или необходимости изменения конфигурации.

Если повторяющиеся запросы «Full» и записи в журнале задержек (Slowlog) демонстрируют одни и те же длительные паттерны запросов, сначала проанализируйте соответствующие пути приложения. Если же задержка возникает на уровне базы данных или внешнего сервиса, их анализ может дать больший эффект, чем изменение количества рабочих процессов. Решающим фактором является то, устраняет ли данная мера наблюдаемую причину, а не просто отдельный симптом.

Корректировка pm.max_children Это вариант можно рассматривать, если доказано, что пул работает на пределе своих возможностей, а ЦП, память и нижестоящие службы способны выдержать дополнительную параллельность. Увеличение количества рабочих процессов требует дополнительных ресурсов и может усилить нагрузку на эти службы. Поэтому универсального числа не существует; при оценке необходимо учитывать режим работы диспетчера процессов.

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