Мониторинг производительности Linux: полное руководство

Введение / Зачем это нужно

Мониторинг производительности Linux — это не про сложные скрипты, а про быстрое понимание, что именно тормозит систему. Без этого любые «сервер тормозит» — это гадание. Вы научитесь за 60 секунд определить: процессор, память, диск или сеть — источник проблемы. Это базовый навык для администрирования любого Linux-сервера, от домашнего до продакшн.

Требования / Подготовка

Перед началом убедитесь:

1. У вас есть доступ к серверу по SSH с правами sudo (некоторые команды требуют root).
2. Установлены базовые утилиты. Мы начнём с установки sysstat и htop (шаг 1).
3. Вы находитесь в текстовом режиме (без графической оболочки) для чистоты эксперимента. Если используете GNOME/KDE, некоторые утилиты (htop) будут работать, но iostat и vmstat — в терминале.

Шаг 1: Установите базовые утилиты мониторинга

В большинстве минимальных установок Linux (особенно в контейнерах или на серверах) нет удобных инструментов вроде htop. Стандартный набор (top, free, df) даёт только общую картину. Нам нужны детальные данные.

# Для Ubuntu/Debian
sudo apt update
sudo apt install sysstat htop iftop iotop -y

# Для RHEL/CentOS/AlmaLinux
sudo yum install sysstat htop iftop iotop -y

# Для Fedora
sudo dnf install sysstat htop iftop iotop -y

Что устанавливаем:

• sysstat — набор iostat (диски), mpstat (ядра CPU), sar (история).
• htop — улучшенный интерактивный просмотр процессов.
• iftop — мониторинг сетевого трафика по соединениям.
• iotop — мониторинг активности ввода-вывода по процессам (требует root).

Шаг 2: Оцените общую загрузку процессора и процессов

Первое, что нужно понять — не «тормозит ли», а что именно нагружает систему. Запустите:

htop

В htop вас интересует верхняя часть:

• CPU bars (CPU1, CPU2...) — показывают загрузку каждого ядра. Если все красные — процессор загружен.
• Load average (load average 1, 5, 15 min) — средняя длина очереди процессов. Правило: значение_load average_ не должно существенно превышать количество ядер CPU. Например, на 4-ядерном сервере значения 4.0, 3.5, 2.0 — норма. 10.0, 8.0, 6.0 — критическая перегрузка.
• Список процессов — сортируйте по %CPU (нажмите F6 -> PERCENT_CPU). Процесс, постоянно «зажирающий» 80-100% одного ядра — вероятный виновник.

Если htop недоступен, используйте top:

top

Нажмите 1 для показа загрузки каждого ядра. Выход — q.

Шаг 3: Проанализируйте использование памяти и подкачки

Даже если CPU свободен, система может «тормозить» из-за нехватки RAM и активного использования swap-раздела.

В htop смотрите строку Mem и Swp:

• Mem: покажет общий объём, использованный, буферы/кеш.
• Swp: если здесь есть ненулевые значения (особенно «used»), система активно использует диск как память — это очень медленно.

Для точных цифр:

free -h

Ключевые колонки:

• used — сколько памяти занято.
• available — самая важная оценка памяти, которую можно выделить новым процессам без своппинга.
• swap used — если больше 0 и растёт — проблема.

Симптом: приложение работает, но отклик «лагает». Причина: постоянный своппинг.

Шаг 4: Проверьте загрузку дисковых подсистем

Диски (особенно HDD или перегруженные SSD) — частый «бутылочное горлышко». Используем iostat:

iostat -x 1

Ключевые колонки в выводе (-x — расширенный):

• %util — процент времени, когда устройство обрабатывало запросы. Цель: < 70-80%. 100% — диск полностью загружен.
• await — среднее время (в миллисекундах) ожидания завершения I/O-операции. Цель: для SSD < 1-5 мс, для HDD < 20-50 мс. Высокие значения (100+ мс) — признак проблемы.
• svctm — среднее время обслуживания (обычно не так полезно, как await).

Пример вывода:

Device        r/s     w/s     rkB/s     wkB/s   await   svctm  %util
sda           0.00   150.00      0.00   6144.00    5.20    1.20   18.00
nvme0n1       5.00   200.00   1024.00   40960.00   12.50    0.80   16.40

Здесь sda (вероятно, HDD) имеет await 5.2 мс — норма. Но если бы await был 100 мс при %util 90% — диск не справляется.

Совет: Если iostat не показывает нужные устройства, укажите явно: iostat -x 1 /dev/sda /dev/nvme0n1.

Шаг 5: Изучите сетевую активность и ошибки

Сеть может «подводить» из-за перегрузки канала, ошибок на интерфейсе или проблем с приложением.

Быстрый просмотр трафика в реальном времени:

sudo iftop -nP

• -n — не преобразовывать IP в имена (быстрее).
• -P — показывать порты. Сортировка по SENT или RECV (нажмите s или r) покажет, какие соединения грузят канал.

Более детальная статистика по интерфейсам:

ip -s link show eth0  # или ens3, enp0s3 и т.д.

Ищите в выводе:

• rx errors / tx errors — количество ошибок приёма/передачи. Ненулевые значения требуют проверки кабеля, свитча, драйвера.
• rx dropped / tx dropped — пакеты, отброшенные ядром из-за нехватки ресурсов (буферов). Рост этих значений при высокой нагрузке — признак перегрузки.

Шаг 6: Соберите исторические данные для глубокого анализа

Если проблема периодическая (например, «тормозит каждый день в 14:00»), нужно смотреть историю. Для этого служит демон sysstat.

1. Проверьте, работает ли он:

   sudo systemctl status sysstat
   

   
   Если active (running) — данные уже собираются. Если inactive или failed — включите:

   sudo systemctl enable --now sysstat
   

2. Просмотр архивов: Данные хранятся в /var/log/sysstat/ в бинарном формате. Читать их командой sar.
   • CPU за вчера:

     sudo sar -u -f /var/log/sysstat/sa$(date -d yesterday +%d)
     

   • Диски за последние 10 минут (интервал сбора по умолчанию 10 мин):

     sudo sar -d -f /var/log/sysstat/sa$(date +%d) | grep -E "Device|Average"
     

   • Память:

     sudo sar -r -f /var/log/sysstat/sa$(date +%d) | grep -E "kbmemfree|kbmemused|%memused"
     

   
   Чтобы настроить интервал сбора (например, каждую минуту), отредактируйте /etc/default/sysstat (Debian/Ubuntu) или /etc/sysconfig/sysstat (RHEL) и измените параметр SA1_OPTIONS.

Проверка результата

После прохождения шагов вы должны:

1. Определить ресурс-узкое место: CPU (%util близки к 100%, высокий load average), Memory (available низкий, активен swap), Disk (await и %util высокие), Network (ошибки/dropped, 100% utilisation).
2. Найти «виновника»: конкретный процесс (htop), тип операций (iotop — много ли записей?), конкретное сетевое соединение (iftop).
3. Получить данные для дальнейших действий: например, «Процесс java с PID 1234 потребляет 300% CPU» или «Диск /dev/nvme0n1 имеет await 150 мс при %util 95%».

Если проблема локализована на уровне приложения (например, конкретный Java-процесс), дальнейшая диагностика будет зависеть от него (анализ логов, профилирование).

Возможные проблемы

• iostat: command not found — не установлен пакет sysstat. См. Шаг 1.
• Permission denied при запуске iostat или sar — некоторые команды требуют root. Используйте sudo или логируйтесь как root.
• Нулевые значения в iostat — возможно, диск не используется или система использует виртуальные блок-устройства (в контейнерах). Проверьте lsblk и df -h.
• iftop не показывает интерфейс — укажите явно: sudo iftop -i eth0.
• Нет данных sar за прошлые дни — демон sysstat не был запущен ранее. Данные собираются только с момента запуска службы.
• Высокий await при низком %util — может указывать на проблемы с контроллером диска, драйвером или аппаратные сбои. Проверьте dmesg | grep -i error.
• top/htop показывает 100% CPU, но нет процесса с высоким %CPU — это может быть системные прерывания (si) или процессы в состоянии D (uninterruptible sleep, обычно ожидание I/O). В htop нажмите F2 -> Display options -> включите Show custom thread names и Detailed для просмотра. Для I/O-зависших процессов используйте iotop.