Как диагностировать медленные запросы WordPress с помощью PHP-FPM slowlog

Когда PHP-FPM slowlog помогает найти причину

Используйте slowlog, когда медленная работа воспроизводится на уровне PHP-запроса, но ее источник не виден в access.log или стандартных логах WordPress. Это особенно полезно, если страница иногда открывается нормально, а иногда зависает на несколько секунд.

В стеке вызовов можно увидеть, остановилась ли обработка в functions.php, файлах конкретного плагина, коде темы, REST API, AJAX-обработчике или во время запуска wp-cron.php. Лог не всегда сразу указывает на точную проблемную операцию, но помогает сузить поиск до конкретной части кода.

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

• страницы имеют высокий TTFB без очевидной нагрузки на фронтенд;
• медленная работа началась после установки или обновления плагина;
• проблема возникает только для REST-, AJAX- или cron-запросов;
• отдельные PHP-FPM workers надолго заняты и исчерпывают пул.

Как включить slowlog в пуле PHP-FPM

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

Добавьте или проверьте следующие директивы:

• request_slowlog_timeout определяет, через какое время для медленного запроса нужно записать stack trace;
• slowlog задает путь к файлу slow log;
• значение 3s является примером для диагностики, а не универсальной нормой для production.

[www]
request_slowlog_timeout = 3s
slowlog = /var/log/php-fpm/www-slow.log

Подготовьте файл и права доступа

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

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

• создайте каталог и файл, если они не создаются автоматически;
• проверьте права пользователя, от имени которого работает PHP-FPM;
• не размещайте лог в публичном каталоге WordPress;
• убедитесь, что на диске достаточно свободного места.

Проверьте конфигурацию и примените изменения

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

Если конфигурация корректна, перезагрузите или перезапустите PHP-FPM. При обычном reload активные запросы обычно не прерываются, а новые workers получают обновленные параметры. Конкретное поведение зависит от init-системы и конфигурации сервера.

• проверьте конфигурацию командой вроде php-fpm -t или соответствующей командой для вашей версии PHP;
• выполните reload службы PHP-FPM, например через systemctl, используя фактическое имя сервиса;
• после применения изменений проверьте статус службы;
• сделайте тестовый запрос и убедитесь, что slowlog действительно обновляется.

php-fpm -t
systemctl reload php-fpm

Как читать stack trace в slow log

В slow log обычно появляется запись о процессе и стек вызовов, который PHP-FPM зафиксировал после превышения request_slowlog_timeout. Анализируйте не только последнюю строку, но и всю цепочку: она показывает, какой callback был вызван, из какого файла он пришел и через какие функции выполнялся.

Если в стеке повторяются пути вроде wp-content/plugins/название-плагина, это серьезный сигнал проверить именно этот плагин. Если видны functions.php или файл темы, сопоставьте проблему с активной темой и недавними изменениями. Для REST-запроса дополнительно сравните время с endpoint и параметрами запроса.

Один stack trace не всегда доказывает, что именно показанный файл является первопричиной. Код может запускать медленный запрос к базе данных, обращаться к внешнему HTTP-сервису или ожидать блокировку в другом компоненте. Повторите тест несколько раз и ищите один и тот же участок стека.

• фиксируйте время возникновения проблемы и URL запроса;
• сравнивайте несколько trace, а не делайте вывод по одному случаю;
• обращайте внимание на повторяющиеся плагины, callback и функции;
• не редактируйте файлы плагина без резервной копии и плана отката.

Сопоставьте slowlog с access.log и логами WordPress

Для корректной диагностики нужно связать stack trace с конкретным HTTP-запросом. Сравнивайте временные метки slowlog и access.log. В access.log полезны URL, HTTP-метод, статус, длительность ответа и, если этот параметр настроен, время ответа upstream.

Например, медленная запись для POST-запроса к wp-json может соответствовать REST endpoint, тогда как длительный GET-запрос к странице может быть следствием работы шаблона или плагина, который добавляет запросы во время рендеринга. Отдельно проверяйте wp-cron.php: фоновая задача может создавать нагрузку без очевидного замедления открытия страницы для пользователя.

Если WordPress или плагин записывает собственные сообщения, сопоставьте их время со slowlog. Так можно проверить, связан ли trace с импортом, синхронизацией, генерацией изображений, отправкой HTTP-запроса или другим процессом.

• Nginx или Apache может завершить соединение раньше, чем PHP-FPM сформирует полный результат;
• время в разных логах должно быть синхронизировано, желательно с использованием одного часового пояса;
• одна медленная cron-задача не обязательно объясняет замедление фронтенда, если запросы обрабатываются разными пулами или в разное время.

Что делать после обнаружения подозрительного участка

Slowlog отвечает на вопрос «где находился процесс», но следующий шаг — подтвердить гипотезу контрольным тестом. Если проблема связана с плагином, проверьте сайт в staging-среде, временно отключив его или изменив конфигурацию. На production не следует без плана деактивировать компонент, отвечающий за заказы, авторизацию или другие критически важные функции.

Для собственного кода проверьте циклы, повторные запросы к базе данных, вызовы внешних API, большие выборки и операции с файлами. Если trace указывает на базу данных, slowlog WordPress не заменяет профилирование SQL: потребуются отдельные инструменты и логи запросов, которые следует включать осторожно.

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

• сравните результат при отключенном или обновленном компоненте;
• проверьте внешние API, DNS, TLS и таймауты, если код выполняет сетевые запросы;
• не увеличивайте таймаут только для того, чтобы скрыть проблему;
• при необходимости обратитесь к разработчику плагина или используйте staging для детального профилирования.

Безопасность, объем логов и отключение slowlog после диагностики

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

После завершения диагностики увеличьте request_slowlog_timeout до значения, которое будет фиксировать только действительно подозрительные запросы, или отключите slowlog, если постоянный контроль не нужен. Настройте logrotate или другой механизм ротации, чтобы файл не заполнил диск.

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

• ограничьте доступ к slowlog на уровне файловой системы;
• настройте ротацию, сжатие и срок хранения;
• контролируйте свободное место на сервере;
• после диагностики выполните reload PHP-FPM и проверьте новое поведение.