#Симптомы и область применимости
Панель хостинга показывает, что у сайта накапливаются ожидающие запросы, хотя загрузка процессора невысокая. Это характерно для ожидания базы данных, свободных рабочих процессов PHP-FPM, сетевого API или диска; увеличение мощности процессора не устраняет первопричину.
#Причины и диагностические признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| PHP-FPM исчерпал процессыНовые веб-запросы ждут освобождения обработчика. | В журнале есть reached pm.max_children, очередь продолжает расти | Проверьте активные запросы и реальное потребление памяти. |
| Приложение ждёт блокировку базыЗапрос ожидает блокировку, диск или внешний ресурс. | CPU почти свободен, а обработка занимает секунды | Сопоставьте медленные запросы и состояние базы. |
| Ограничения отдельного аккаунтаПанель может задавать лимиты процессов/соединений на отдельный сайт. | Другие сайты быстрые, один сайт медленный | Проверьте ограничения именно этого домена. |
#Пошаговая диагностика и исправление
- 1. Сравните проблему на разных сайтахОткройте один медленный и один быстрый сайт на сервере. Зафиксируйте время ответа, час, URL и количество параллельных посетителей. Если медленный только один сайт, не перезапускайте веб-сервер сразу для всех пользователей.
- 2. Откройте показатели ресурсов в панелиВ разделе сайта найдите статистику обращений и использования CPU, памяти, процессов и диска; перечень зависит от версии панели и тарифа. Сопоставьте время очереди с фактическим временем ответа страниц, а не только с общим графиком CPU.
- 3. Проверьте уровни очередиЕсли панель показывает очередь веб-сервера, выясните, где она измерена: входящие соединения Nginx, ожидание PHP-FPM или очередь фоновых задач. Эти величины не взаимозаменяемы; они требуют разных способов диагностики.
- 4. Посмотрите предупреждения пула PHP-FPMОткройте журнал назначенного обработчика PHP; при SSH ищите reached pm.max_children и slow request. Не включайте подробный журнал на неопределённый срок и не размещайте его в публичном каталоге.
- Linux с systemd; чтениеLinux · Терминал (Bash)КомандаНужен sudoLinux с systemd; чтение. Отсутствие строки в journalctl не исключает отдельный журнал PHP-FPM.
sudo journalctl --since "20 minutes ago" --no-pager | grep -i "max_children"
- 5. Проверьте, не упирается ли сайт в базуВ диагностике приложения и журнале базы найдите долгие запросы и блокировки в то же время. Не выполняйте массовый ANALYZE/OPTIMIZE на рабочей базе без понимания движка. По возможности измерьте один медленный SQL на тестовой копии.
- 6. Оцените задержки внешних ресурсовЕсли медленные страницы зависят от API платежей, авторизации или внешнего хранилища, посмотрите их таймауты в журналах приложения. Не увеличивайте общие тайм-ауты по умолчанию: так можно ещё сильнее занять очередь обработчиков.
- 7. Рассчитайте запас ресурсов перед настройкой пулаДля PHP-FPM узнайте среднюю память одного рабочего процесса под типичной нагрузкой и доступную память всей машины. Увеличивать pm.max_children допустимо только если хватает RAM и устранён медленный участок. Сохраните старое значение для отката.
- 8. Внесите одну точечную правку и измерьте повторноПосле резервного копирования конфигурации настройте конкретный пул или оптимизируйте причину ожидания. Применяйте изменения штатным механизмом панели, затем повторите тест нескольких страниц и сравните длину очереди, задержку и потребление памяти. При ухудшении верните исходное значение.
#Как убедиться, что проблема устранена
Очередь уменьшается при штатной нагрузке, время ответа стабилизировалось, память не уходит в подкачку, журналы не фиксируют новых предупреждений по пулу и другим сайтам.
#Если проблема осталась
Если очередь растёт при низком CPU и свободных PHP-процессах, ищите ожидание базы, диска, внешних API или блокировок приложений. Передайте специалисту графики и один обезличенный пример медленного запроса.