В случае большой нагрузки на сервере как проведёте процедуру траблшутинга, что будете смотреть, какие утилиты использовать

Стратегия траблшутинга при высокой нагрузке на сервере

При возникновении высокой нагрузки на сервере я следую структурированному подходу, чтобы быстро локализовать "узкое место" (bottleneck) и устранить проблему. Процедура делится на несколько этапов: сбор метрик, анализ показателей, выявление root cause и принятие решений.

1. Сбор данных и первичная диагностика

В первую очередь, необходимо понять, какой ресурс исчерпан или находится под максимальным давлением. Использую комбинацию утилит для мониторинга в реальном времени:

• top / htop — для быстрого просмотра общей картины: загрузка CPU, память, процессы.
• vmstat 1 — чтобы увидеть динамику использования памяти, свопинга и активности процессов.

vmstat 1 5  # выводит статистику каждую секунду, 5 раз

• iostat -xz 1 — для анализа нагрузки на дисковую подсистему (await, %util).

iostat -xz 1

• dstat — комплексный инструмент, показывающий CPU, память, сеть, диски в одном окне.
• netstat / ss — для просмотра сетевых подключений, особенно состояний TIME_WAIT, CLOSE_WAIT.

ss -tunap | grep -E '(LISTEN|ESTAB)'

2. Анализ конкретных ресурсов

В зависимости от того, что показывают первичные утилиты, углубляюсь в конкретные направления.

Если проблема с CPU:

• pidstat 1 — идентификация процессов, потребляющих CPU.
• perf top — для просмотра "горячих" функций в ядре или пользовательском пространстве.
• sar -P ALL — исторические данные по загрузке CPU (если настроен sysstat).

Если проблема с памятью:

• free -m — использование RAM и swap.
• cat /proc/meminfo — детальная информация.
• Вычисление "реальной" памяти процесса через ps aux или smem.

ps aux --sort=-%mem | head -10

Если проблема с диском I/O:

• iotop — аналог top для дисковых операций.
• Проверка свободного места (df -h) и инодов (df -i).
• Анализ журналов (dmesg | grep -i error) на наличие ошибок диска.

Если проблема с сетью:

• iftop / nethogs — трафик по интерфейсам и процессам.
• tcpdump — глубокий анализ пакетов при подозрении на сетевую аномалию.

3. Анализ приложения и логирования

После выявления ресурса перехожу к прикладному уровню:

• Логи приложения (например, tail -f /var/log/app/error.log) — поиск ошибок, исключений, медленных запросов.
• Логи веб-сервера (Nginx/Apache) — анализ времени ответа, кодов состояния (5xx), URL-ов с высокой задержкой.

tail -f /var/log/nginx/access.log | awk '{print $7, $NF}'  # URL и время ответа

• Метрики базы данных — если используется БД, проверяю медленные запросы (slow_query_log для MySQL), количество соединений, блокировки.

4. Использование комплексных систем мониторинга

В продакшен-средах всегда используются системы типа Prometheus + Grafana, Datadog, New Relic. Они позволяют:

• Видеть исторические тренды и сравнивать текущую нагрузку с нормальной.
• Настроить алертинг на аномалии.
• Анализировать распределение времени ответа по микросервисам (если используется распределенная трассировка, например, Jaeger).

5. Действия по результатам анализа

В зависимости от root cause, действия могут быть:

• Масштабирование (вертикальное/горизонтальное) — если ресурсов объективно не хватает.
• Оптимизация кода/запросов — при обнаружении "тяжелых" процессов или запросов.
• Настройка кэширования (например, Redis) — для снижения нагрузки на БД.
• Изменение конфигурации (например, увеличение ulimit, настройка пула соединений БД).
• Балансировка нагрузки — перераспределение трафика между серверами.

Ключевые принципы:

• Не гадать, а измерять — всегда опираться на метрики, а не интуицию.
• Сравнивать с baseline — понимать, что является "нормальной" нагрузкой для системы.
• Эскалация — если проблема не очевидна, привлекать разработчиков, специалистов по БД, сетям.
• Документирование — фиксировать найденные root cause и действия, чтобы создать knowledge base для будущих инцидентов.

Такой подход позволяет системно подходить к диагностике, сокращая время на восстановление сервиса и снижая риски принятия неверных решений.