#Симптом и границы применимости
При росте входящего потока ожидание запросов увеличивается, но общая загрузка CPU остаётся небольшой. Часто упираются в лимиты соединений, очередь upstream, диск или приложение, а не в нехватку процессорной мощности.
#Возможные причины и как их отличить
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Ограничение числа соединенийКороткие запросы могут ждать соединения при низком CPU. | Ошибки worker_connections are not enough или слишком много соединений | Посчитать активные сокеты и лимиты |
| Ожидание backend/БДNginx ждёт ответ, не занимая процессор. | Большое upstream_response_time при малом request_time самого прокси | Сопоставить задержки в Nginx и приложении |
| Лимит очереди в приложенииНе все очереди относятся к Nginx; коммерческая upstream queue недоступна в бесплатной сборке. | Рост listen backlog или запросов, ожидающих PHP-FPM | Проверить пул и метрики очереди |
#Пошаговая диагностика и исправление
- Уточните, где именно очередьОткройте панель мониторинга и посмотрите отдельно число активных соединений Nginx, время ответа сайта, ожидание PHP-FPM или базы. Если метрика называется queue, уточните источник: очередь балансировщика, backlog TCP и очередь PHP-FPM имеют разные причины.
- Снимите состояние соединений во время нагрузкиПодключитесь к серверу через SSH. Воспроизведите обычный пользовательский запрос и одновременно проверьте открытые слушающие сокеты и текущие соединения. Не создавайте искусственную массовую нагрузку на рабочем сервере без согласования.
- Только наблюдение; ss -s показывает общую сводку TCP-соединенийLinux · Терминал (Bash)КомандаНужен sudoТолько наблюдение; ss -s показывает общую сводку TCP-соединений.
ss -ssudo ss -lntp
- Сравните задержку сервера и приложенияНайдите действующий log_format через nginx -T. Если там есть $request_time и $upstream_response_time, сравните строки для медленных и быстрых запросов. Если их нет, согласуйте отдельный диагностический формат логов на тестовом сайте; не заменяйте действующий access_log и учитывайте персональные данные.Linux · Терминал (Bash)КомандаНужен sudoВывод может включать конфиденциальную конфигурацию.
sudo nginx -T 2>&1 | grep -nE "log_format|access_log|proxy_pass|fastcgi_pass"
- Проверьте ограничения NginxВ полной конфигурации найдите worker_processes, worker_connections, limit_conn и limit_req. Сообщение worker_connections are not enough в error_log важнее догадок. Если ограничение подтверждено, рассчитывайте память и лимит файловых дескрипторов до увеличения числа соединений.Linux · Терминал (Bash)КомандаНужен sudoКоманда не меняет лимиты.
sudo nginx -T 2>&1 | grep -nE "worker_processes|worker_connections|limit_conn|limit_req"
- Исследуйте upstream отдельноЕсли Nginx проксирует PHP-FPM, проверьте pm.max_children и его журнал; если приложение на TCP-порту — очередь и число рабочих процессов; для базы — длительные запросы. Не включайте директиву queue из коммерческого Nginx в бесплатной сборке: она не является универсальным решением.
- Меняйте по одному параметруСохраните исходные конфигурации и контрольные показатели за один интервал. При подтверждённом лимите измените один параметр, выполните nginx -t и reload; повторно измерьте задержки и ошибки. Если лимит не подтверждён, верните настройки и исследуйте I/O/БД.Linux · Терминал (Bash)С осторожностьюНужен sudoПроверка синтаксиса перед плановым reload; нельзя вслепую увеличивать все лимиты.
sudo nginx -tКоманда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
#Как проверить результат
После выбранного исправления среднее и максимальное время ответа под сопоставимым потоком должны уменьшиться, очередь — перестать расти. Сравнивайте одинаковые часы и типы запросов.
#Если проблема не устранена
Если CPU низок, но растут iowait и дисковая очередь, требуется исследование накопителя и БД; если ошибки upstream, изучайте backend. Не называйте любую очередь параметром Nginx upstream queue.