Как вы проводите диагностику (troubleshooting) в случае высокой нагрузки на Linux-сервере? Какие метрики и утилиты будете использовать?

«Как вы проводите диагностику (troubleshooting) в случае высокой нагрузки на Linux-сервере? Какие метрики и утилиты будете использовать?» — вопрос из категории Linux, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Мой подход к диагностике высокой нагрузки систематичен: я начинаю с общих метрик и сужаю круг до конкретного узкого места (bottleneck).

1. Быстрый обзор системы (Top-Level View):

  • htop или top — первичный взгляд на загрузку CPU, память и процессы-лидеры.
  • uptime — смотрю load average (1, 5, 15 мин). Значение, превышающее количество ядер CPU, указывает на очередь процессов.

2. Детальный анализ по компонентам:

  • CPU:

    • mpstat -P ALL 1 — загрузка по каждому ядру.
    • pidstat -u 1 — потребление CPU на уровне процессов.
    • perf top — если подозреваю проблему в пользовательском коде, показывает "горячие" функции.
  • Память (RAM и Swap):

    • free -h — общее использование.
    • vmstat 1 — смотрю на колонки si (swap in) и so (swap out). Если они не нулевые — нехватка RAM.
    • smem -s swap — какие процессы используют swap.
  • Дисковый ввод-вывод (I/O):

    • iostat -xz 1 — ключевые метрики: %util (загрузка диска), await (среднее время ожидания I/O, >10-20ms — проблема).
    • iotop — процессы, активно ведущие запись/чтение.
  • Сеть:

    • ss -tunap или netstat -tunap — количество соединений в состояниях (TIME_WAIT, ESTABLISHED), привязка к процессам.
    • iftop или nethogs — трафик в реальном времени по хостам/процессам.
    • sar -n DEV 1 — статистика по интерфейсам (rxkB/s, txkB/s, %util).

3. Логи и процессы:

  • journalctl -xe --since "5 minutes ago" — системные логи.
  • tail -f /var/log/nginx/error.log (или приложения) — логи сервиса.
  • strace -p <PID> — если процесс "висит", смотрю на системные вызовы.

Пример последовательности команд для сбора данных:

# Сбор ключевых метрик за 30 секунд
vmstat 1 30 > vmstat.log &
iostat -xz 1 30 > iostat.log &
sar -n DEV 1 30 > network.log &
wait
# Затем анализирую логи

Цель — найти ограничивающий ресурс (CPU, RAM, I/O, сеть) и идентифицировать процесс или конфигурацию, вызывающую проблему.