Выявление и устранение узких мест производительности Nginx: руководство по устранению неполадок

Проблемы с производительностью Nginx обычно проявляются просто: страницы загружаются медленно, вызовы API начинают превышать тайм-ауты, растет загрузка CPU, или пользователи начинают видеть ошибки 502 и 504. Сложность заключается в том, чтобы понять, является ли Nginx узким местом или он просто первый сервис, который громко жалуется.

Когда я устраняю неполадки Nginx, я стараюсь не начинать с изменения директив. Сначала я задаю несколько простых вопросов. Увеличилась ли задержка для всех маршрутов или только для тех, которые обращаются к одному апстриму? Медленно ли загружаются статические файлы? Начались ли ошибки после развертывания, скачка трафика, смены сертификата или изменения логирования? Этот контекст обычно экономит больше времени, чем копирование блока настроек из старой статьи.

Понимание метрик производительности Nginx

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

Ключевые метрики для мониторинга включают:

Активные соединения: Количество клиентских соединений, обрабатываемых в данный момент Nginx.
Запросов в секунду (RPS): Скорость, с которой Nginx обслуживает запросы.
Задержка запроса: Время, необходимое Nginx для ответа на клиентский запрос.
Использование CPU: Процент ресурсов CPU, потребляемых рабочими процессами Nginx.
Использование памяти: Объем оперативной памяти, используемой процессами Nginx.
Сетевой ввод/вывод: Скорость передачи данных на сервер Nginx и с него.
Дисковый ввод/вывод: Актуально, если Nginx напрямую обслуживает статические файлы или ведет интенсивное логирование.

Встроенные инструменты Nginx для диагностики

Nginx предлагает несколько функций для мониторинга его рабочего состояния и сбора данных о производительности.

Использование модуля `stub_status`

Модуль stub_status предоставляет базовую, но важную информацию о текущем состоянии Nginx. Это отличная первая остановка для быстрого обзора активности сервера.

Включение `stub_status`

Чтобы включить stub_status, добавьте следующий блок конфигурации в ваш nginx.conf (обычно в блоке server для вашей конечной точки мониторинга):

server {
    listen 80;
    server_name monitoring.example.com;

    location /nginx_status {
        stub_status on;
        access_log off;
        allow 127.0.0.1; # Разрешить доступ только с localhost
        deny all;
    }
}

После изменения конфигурации перезагрузите Nginx:

sudo nginx -t # Проверка конфигурации
sudo nginx -s reload # Перезагрузка Nginx

Интерпретация вывода `stub_status`

Откройте страницу состояния (например, http://localhost/nginx_status), чтобы увидеть вывод, похожий на этот:

Active connections: 291
server accepts handled requests
 1162447 1162447 4496426
Reading: 6 Writing: 17 Waiting: 268

Вот что означает каждая метрика:

Active connections: Текущее количество активных клиентских соединений, включая соединения в состоянии Reading, Writing и Waiting.
accepts: Общее количество соединений, принятых Nginx.
handled: Общее количество соединений, обработанных Nginx. В идеале accepts и handled должны быть равны. Если handled значительно меньше, это может указывать на ограничения ресурсов (например, лимит worker_connections).
requests: Общее количество клиентских запросов, обработанных Nginx.
Reading: Количество соединений, в которых Nginx в данный момент читает заголовок запроса.
Writing: Количество соединений, в которых Nginx в данный момент записывает ответ обратно клиенту.
Waiting: Количество неактивных клиентских соединений, ожидающих запроса (например, keep-alive соединения). Большое число здесь может указывать на эффективное использование keep-alive, но также и на то, что рабочие процессы заняты ожиданием, что может быть проблемой, если активных соединений мало, а ресурсы ограничены.

Использование API Nginx Plus для расширенных метрик

Для пользователей Nginx Plus API Nginx Plus предоставляет более детальный JSON-интерфейс реального времени для мониторинга. Этот API предлагает детальные метрики для зон, серверов, апстримов, кэшей и многого другого, что делает его бесценным для углубленного анализа производительности и интеграции с панелями мониторинга.

Включение API Nginx Plus

Настройте местоположение для API в вашей конфигурации Nginx Plus:

http {
    server {
        listen 8080;

        location /api {
            api write=on;
            allow 127.0.0.1; # Ограничить доступ для безопасности
            deny all;
        }

        location /api.html {
            root /usr/share/nginx/html;
        }
    }
}

Перезагрузите Nginx и откройте http://localhost:8080/api, чтобы просмотреть вывод JSON. Этот API предоставляет обширные данные, включая детальную статистику соединений, время обработки запросов, состояние апстримов и производительность кэша, что позволяет проводить гораздо более тонкую диагностику, чем stub_status.

Журналы доступа и ошибок Nginx

Журналы Nginx — это кладезь информации для устранения неполадок производительности. Они записывают каждый запрос и все возникающие ошибки.

Настройка детального логирования

Вы можете настроить свой log_format, включив полезные метрики производительности, такие как время обработки запроса ($request_time) и время ответа апстрима ($upstream_response_time).

http {
    log_format perf_log '$remote_addr - $remote_user [$time_local] "$request" ' 
                        '$status $body_bytes_sent "$http_referer" ' 
                        '"$http_user_agent" "$http_x_forwarded_for" ' 
                        'request_time:$request_time upstream_response_time:$upstream_response_time ' 
                        'upstream_addr:$upstream_addr';

    access_log /var/log/nginx/access.log perf_log;
    error_log /var/log/nginx/error.log warn;

    # Пример для логирования запросов, медленнее порога
    # Это немного сложнее и может потребовать пользовательского модуля или отдельного инструмента для парсинга.
    # Часто проще парсить основной access_log для поиска медленных запросов.
}

Выявление медленных запросов и ошибок

Медленные запросы: Используйте такие инструменты, как grep или awk, для парсинга ваших журналов доступа на предмет запросов, превышающих определенный порог $request_time или $upstream_response_time. Это помогает выявить проблемные приложения или внешние сервисы.
```
awk 'match($0, /request_time:([0-9.]+)/, m) && m[1] > 1.0 {print $0}' /var/log/nginx/access.log
```
Это позволяет избежать зависимости от фиксированного номера поля в журнале, который нарушается, как только путь запроса, user-agent или referer содержат пробелы.
Ошибки: Отслеживайте error.log на предмет критических проблем, таких как "upstream timed out", "no live upstreams" или "too many open files". Эти ошибки напрямую указывают на проблемы с бэкендом или ограничения ресурсов Nginx.

Внешние инструменты мониторинга системы

Производительность Nginx часто связана с ресурсами базового сервера. Мониторинг на уровне системы предоставляет важный контекст.

Использование CPU (top, htop, mpstat): Высокая загрузка CPU рабочими процессами Nginx может указывать на сложную конфигурацию (регулярные выражения, SSL-рукопожатия), неэффективный код или просто высокую нагрузку.
```
top -c # Показывает процессы, отсортированные по использованию CPU
```
Использование памяти (free -h, htop): Чрезмерное потребление памяти может указывать на большие размеры буферов (proxy_buffers), утечки памяти или необычно большое количество активных соединений.
```
free -h # Отображает использование памяти в удобочитаемом формате
```
Дисковый ввод/вывод (iostat, iotop): Актуально, если Nginx интенсивно обслуживает статический контент или ведет обширное логирование. Высокий дисковый ввод/вывод может означать узкое место в хранилище или чрезмерное логирование.
```
iostat -x 1 10 # Показывает расширенную статистику диска каждую секунду 10 раз
```
Сетевой ввод/вывод (netstat, ss, iftop): Отслеживайте сетевой трафик на предмет насыщения или чрезмерных повторных передач, что может указывать на сетевые узкие места или проблемы между Nginx и клиентами/апстримами.
```
netstat -antp | grep nginx # Показать соединения Nginx
```

Распространенные узкие места производительности Nginx и их устранение

Имея данные мониторинга, давайте рассмотрим распространенные проблемы и способы их решения.

1. Высокая загрузка CPU

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

Причины:

Слишком мало рабочих процессов для многоядерных CPU: Nginx может не использовать все доступные ядра.
Сложные операторы if или регулярные выражения: Чрезмерно сложные регулярные выражения или множество операторов if в конфигурации могут быть интенсивными по CPU.
Неэффективная конфигурация SSL/TLS: Использование слабых шифров, требующих больше ресурсов CPU, или отсутствие аппаратного ускорения, если оно доступно.
Чрезмерное логирование: Запись слишком большого объема данных на диск, особенно со сложными правилами log_format.
Накладные расходы на TLS, сжатие или обработку запросов: Дорогие SSL-рукопожатия, высокие уровни сжатия, тяжелые правила перезаписи или очень большие заголовки запросов могут увеличить загрузку CPU.

Решения:

Оптимизируйте worker_processes: Установите worker_processes auto; (рекомендуется) или равным количеству ядер CPU. Каждый рабочий процесс является однопоточным и может полностью использовать одно ядро CPU.
```
worker_processes auto;
```
Упростите конфигурацию: Пересмотрите операторы if и регулярные выражения. Рассмотрите возможность использования директив map или try_files для более простой логики.
Оптимизируйте SSL/TLS: Используйте современные настройки TLS и включите ssl_session_cache и ssl_session_timeout, где это уместно, чтобы уменьшить повторную работу по рукопожатию.
Контролируйте логирование: Используйте буферизованные журналы доступа или отключите журналы доступа для шумных статических ресурсов, если вам не нужны записи о каждом запросе там.
Исследуйте бэкенд: Если Nginx ожидает, узким местом является апстрим. Оптимизируйте бэкенд-приложение.

2. Медленное время ответа

Симптомы: Высокое $request_time или $upstream_response_time в журналах; страницы загружаются медленно.

Причины:

Проблемы с сервером апстрима (бэкенда): Наиболее распространенная причина. Сервер приложений медленно генерирует ответы.
Передача больших файлов без надлежащей оптимизации: Обслуживание больших статических файлов без sendfile или gzip.
Сетевая задержка: Медленная сеть между клиентом и Nginx или между Nginx и апстримом.
Отсутствие кэширования: Повторная загрузка динамического контента.

Решения:

Оптимизируйте проверки состояния и тайм-ауты апстрима: Настройте proxy_read_timeout, proxy_connect_timeout и proxy_send_timeout. Внедрите проверки состояния для серверов апстрима.
```
location / {
    proxy_pass http://backend_app;
    proxy_read_timeout 90s; # Настройте по мере необходимости
    proxy_connect_timeout 5s;
}
```
Включите сжатие gzip: Для текстового контента gzip значительно уменьшает объем передаваемых данных.
```
gzip on;
gzip_comp_level 5;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
```
Включите sendfile и tcp_nodelay: Для эффективного обслуживания статических файлов.
```
sendfile on;
tcp_nodelay on;
```
Внедрите кэширование: Используйте proxy_cache для динамического контента или установите заголовки expires для статических ресурсов.
```
# Пример для статических ресурсов
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
    expires 30d;
    log_not_found off;
}
```

3. Ошибки соединения / Исчерпание соединений

Симптомы: Клиенты получают ошибки соединения, ответы 502 или 504 или периодические тайм-ауты. stub_status может показывать быстрое увеличение принятых соединений, а журнал ошибок может упоминать worker_connections are not enough, too many open files или ошибки соединения с апстримом.

Причины:

Достигнут лимит worker_connections: Nginx не может принимать новые соединения.
Слишком много открытых файлов (ulimit): Достигнут лимит операционной системы на файловые дескрипторы.
Насыщение бэкенда: Серверы апстрима перегружены и не принимают соединения.
DDoS или необычно высокий легитимный трафик.

Решения:

Увеличьте worker_connections: Установите эту директиву на высокое значение (например, 10240 или выше) в блоке events. Это максимальное количество соединений на один рабочий процесс.
```
events {
    worker_connections 10240;
}
```
Настройте лимиты файловых дескрипторов: Увеличьте лимит открытых файлов операционной системы. Добавьте worker_rlimit_nofile 65535; в nginx.conf, если это уместно, и установите лимит службы через systemd с помощью LimitNOFILE=65535 в большинстве современных дистрибутивов Linux.
Оптимизируйте keepalive_timeout: Длинные тайм-ауты keep-alive могут без необходимости занимать рабочие процессы, если клиенты не используют повторно соединения. Сократите его, если количество соединений Waiting велико, а requests мало.
```
keepalive_timeout 15s; # По умолчанию 75s
```
Внедрите балансировку нагрузки и масштабирование: Распределите трафик между несколькими серверами бэкенда. Рассмотрите возможности балансировки нагрузки Nginx (round-robin, least-connected, ip-hash).
Ограничение скорости: Используйте модули limit_req или limit_conn, чтобы защитить ваш сервер от чрезмерных запросов или соединений от отдельных клиентов.

4. Высокое использование памяти

Симптомы: Рабочие процессы Nginx потребляют значительный объем оперативной памяти; сервер может активно использовать свопинг.

Причины:

Большие размеры буферов: proxy_buffers, client_body_buffer_size, fastcgi_buffers настроены слишком высоко.
Обширное кэширование: Большие размеры proxy_cache_path.
Много активных соединений: Каждое соединение требует некоторого объема памяти.

Решения:

Настройте размеры буферов: Увеличивайте размеры буферов только тогда, когда журналы показывают реальную проблему с буфером, например, заголовки ответов слишком велики для настроенного буфера прокси или FastCGI. 413 Request Entity Too Large контролируется лимитами тела запроса, такими как client_max_body_size, а не буферами ответов прокси.
```
proxy_buffer_size 4k;
proxy_buffers 8 8k;
```
Оптимизируйте кэширование: Управляйте размерами кэша и политиками вытеснения (параметры proxy_cache_path).
Пересмотрите keepalive_timeout: Как упоминалось ранее, чрезмерно длинный keepalive_timeout может удерживать рабочие процессы и связанную с ними память активными для неактивных соединений.

Процесс и стратегия устранения неполадок

Сталкиваясь с проблемой производительности, следуйте структурированному подходу:

Определите базовый уровень: Поймите нормальные рабочие метрики (CPU, память, соединения, RPS, задержка) в периоды нормальной работы.
Отслеживайте симптомы: Определите конкретные симптомы (например, высокая загрузка CPU, медленные запросы, ошибки соединения) и используйте инструменты (stub_status, журналы, top), чтобы подтвердить их.
Выдвиньте гипотезу: Основываясь на симптомах, сформулируйте гипотезу о коренной причине (например, "Высокая загрузка CPU вызвана неэффективными регулярными выражениями").
Тестируйте и анализируйте: Внесите изменение (например, упростите регулярное выражение) и отследите его влияние на метрики. Проанализируйте новые записи в журнале или вывод stub_status.
Повторяйте: Если проблема не устранена, уточните гипотезу и повторите процесс.
Документируйте: Ведите записи о внесенных изменениях и их эффектах для будущего использования.

Лучшие исправления производительности Nginx обычно скучны: докажите, где находится задержка, измените одну вещь и снова посмотрите на ту же метрику. Если $upstream_response_time высок, настройте путь приложения, прежде чем винить Nginx. Если статические файлы медленные, а время апстрима пустое, посмотрите на настройки диска, сети, сжатия и статических файлов. Если ошибки упоминают файловые дескрипторы или соединения рабочих процессов, исправьте эти лимиты в паре. Эта привычка держит устранение неполадок основанным на доказательствах, а не на фольклоре.

Выявление и устранение узких мест производительности Nginx: руководство по устранению неполадок

Понимание метрик производительности Nginx

Встроенные инструменты Nginx для диагностики

Использование модуля stub_status

Включение stub_status

Интерпретация вывода stub_status

Использование API Nginx Plus для расширенных метрик

Включение API Nginx Plus

Журналы доступа и ошибок Nginx

Настройка детального логирования

Выявление медленных запросов и ошибок

Внешние инструменты мониторинга системы

Распространенные узкие места производительности Nginx и их устранение

1. Высокая загрузка CPU

2. Медленное время ответа

3. Ошибки соединения / Исчерпание соединений

4. Высокое использование памяти

Рекомендации по конфигурации Nginx для производительности

Процесс и стратегия устранения неполадок

Использование модуля `stub_status`

Включение `stub_status`

Интерпретация вывода `stub_status`