Мониторинг производительности сервера: метрики CPU, памяти, диска и сети в Linux | Практическое руководство

Почему мониторинг производительности — ваша ежедневная практика

Замедление ответа веб-сервисов, рост времени обработки запросов в базе данных, внезапные ошибки 5xx или постоянные жалобы пользователей на «лаги» — все это симптомы одной проблемы: узкого места (bottleneck) в вашей IT-инфраструктуре. За каждым таким симптомом стоят конкретные цифры: загрузка процессора под 100%, активное использование свопа, очередь запросов к диску или переполнение сетевых буферов.

Мониторинг производительности — это не просто сбор данных, а инструмент для принятия оперативных решений. Он отвечает на ключевые вопросы: что именно тормозит, почему это происходит прямо сейчас и какие меры нужно принять — оптимизировать конфигурацию, масштабировать ресурсы или перераспределить нагрузку. В этой статье мы предоставляем четкий алгоритм и набор инструментов командной строки, которые позволят вам за 5-10 минут диагностировать причину проблемы и определить путь ее решения, экономя часы на поисках.

Ключевые метрики операционной системы: что измерять и как понимать

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

CPU: нагрузка на процессор и ее составляющие

Метрики CPU часто путают, но каждая из них указывает на разные аспекты работы системы.

%user: Процент времени, которое CPU тратит на выполнение кода пользовательских приложений. Высокое значение (например, >70% в течение длительного времени) указывает на высокую нагрузку от вашего сервиса или приложения.
%system: Процент времени на выполнение кода ядра ОС (системные вызовы). Рост этого значения может говорить о проблемах с драйверами, частым переключением контекста или активной работой с сетью/диском на низком уровне.
%idle: Процент времени простоя процессора. В здоровой системе под нагрузкой это значение может быть низким, но не должно постоянно находиться на нуле.
%wa (iowait): Критически важная метрика. Показывает процент времени, когда CPU простаивал в ожидании завершения операций ввода-вывода (I/O). Значение выше 5-10% часто является прямым указанием на проблемы с дисковой подсистемой (медленные диски, перегруженный RAID).
Load Average (1, 5, 15 мин): Среднее количество процессов, находящихся в состоянии исполнения или ожидания CPU (в очереди исполнения). Ключевое правило: если Load Average стабильно превышает количество доступных физических или логических ядер CPU — система перегружена, и процессы вынуждены ждать.

Память (RAM): использование, свопинг и давление

Свободная оперативная память (free memory) — не всегда хороший показатель. Современные ОС активно используют свободную память для кэширования дисковых операций.

available: Это ключевая метрика. Она показывает объем памяти, доступный для запуска новых приложений без необходимости вытеснения кэша или использования свопа. Именно на нее нужно ориентироваться в первую очередь.
swap used: Объем используемой области подкачки на диске. Активное чтение/запись в своп (показатели si/so в top) при достаточном объеме available памяти — верный признак проблемы, часто указывающий на утечку памяти (memory leak) в приложении.
memory pressure: В новых версиях Linux (ядро 4.20+) появились метрики давления памяти в /proc/pressure/memory. Они показывают, как часто процессы вынуждены ждать освобождения памяти. Рост этих значений — ранний сигнал о надвигающемся дефиците RAM.

Дисковая подсистема (I/O): скорость, очередь и задержки

Проблемы с дисками определяются не процентом использования пространства, а задержками и длиной очереди запросов.

%util: Процент загрузки устройства. Показывает, какую часть времени устройство было занято обработкой запросов. Значение, близкое к 100%, почти всегда указывает на узкое место.
r/s, w/s (IOPS): Количество операций чтения и записи в секунду. Показывает интенсивность нагрузки.
rkB/s, wkB/s: Скорость чтения и записи в килобайтах в секунду. Полезно для оценки пропускной способности.
avgqu-sz: Средняя длина очереди запросов к устройству. Значение больше 1-2 указывает на то, что запросы начинают накапливаться и ждать.
await: Среднее время (в миллисекундах), которое запрос проводит в очереди и на обслуживании устройством. Это главный показатель задержки.
Критические пороги:
- Для SSD: await > 10-20 ms — повод для детального анализа.
- Для HDD: await > 50-100 ms — вероятная проблема с производительностью.

Высокий %util при низких значениях IOPS (например, 100% util и 50 r/s) часто означает, что устройство тратит основное время не на полезную работу, а на ожидание (например, из-за механического поиска на HDD), что выражается в высоком await.

Сеть: трафик, ошибки и состояние соединений

Сетевые проблемы часто проявляются в потере пакетов или аномальном количестве соединений.

RX/TX bytes/packets, errors, drops: Статистика сетевого интерфейса. Рост ошибок (errors) или сбросов пакетов (drops) больше нуля — прямой сигнал о проблемах с сетевым оборудованием, переполнением буферов или неверными настройками драйвера.
Состояния соединений (ESTABLISHED, LISTEN, TIME_WAIT): Анализируются через netstat или ss.
- Большое количество соединений в состоянии TIME_WAIT (например, тысячи) может указывать на то, что приложение слишком быстро открывает и закрывает соединения, не дожидаясь корректного завершения по TCP. Это может исчерпывать лимиты ядра на доступные порты.
- Необычно высокое число ESTABLISHED-соединений к одному порту может быть признаком DDoS-атаки или ошибки в логике работы приложения (например, не закрывающиеся keep-alive соединения).

Инструменты командной строки: ваш набор для оперативной диагностики

Когда проблема возникает здесь и сейчас, системы вроде Prometheus могут не успеть помочь. На первое место выходят CLI-инструменты, дающие моментальный снимок состояния системы.

top и htop: общая картина нагрузки в реальном времени

Команда top — это отправная точка любой диагностики. Она показывает сводку по системе и список процессов.

Ключевые строки в выводе top:

Первая строка: load average за 1, 5 и 15 минут.
Строка %Cpu(s): детализация загрузки (us, sy, id, wa, st).
Строка MiB Mem / Swap: использование оперативной памяти и свопа.

Практический совет: Запускайте top, а затем нажмите цифру 1, чтобы увидеть загрузку по каждому ядру CPU отдельно. Это помогает выявить проблему с одним ядром, которая может теряться в общей статистике.

htop — это улучшенная, цветная версия top. Она предоставляет те же данные, но в более наглядном виде: вертикальные шкалы загрузки CPU, дерево процессов (tree view), удобную сортировку по любому столбцу. Для ежедневного использования htop часто предпочтительнее. Запустите его командой htop.

Для наблюдения за динамикой запускайте эти инструменты с небольшим интервалом обновления: top -d 2 (обновление каждые 2 секунды).

iostat: детальный анализ дисковой активности и задержек

Когда top показывает высокий %wa, самое время запустить iostat. Эта утилита специализируется на диагностике проблем ввода-вывода.

Рекомендуемая команда для запуска: iostat -xz 2

-x: Показывает расширенную статистику, включая await, avgqu-sz и %util.
-z: Пропускает вывод для неактивных устройств.
2: Интервал обновления в секундах.

Пример вывода и интерпретация:

Device            r/s     w/s     rkB/s     wkB/s   avgqu-sz   await   %util
sda              25.50    0.00   1020.00      0.00      0.85    33.44   85.30

В этом примере для диска sda мы видим: • Умеренные IOPS (25.5 чтений в секунду). • Высокий %util (85.3%) и высокий await (33.44 мс). • Это классическая картина «медленного диска»: даже при небольшой нагрузке запросы долго ждут своей очереди и выполнения, что и приводит к высокой загрузке устройства.

netstat и ss: состояние сети и открытых соединений

Для анализа сетевой активности традиционно использовался netstat, но в современных дистрибутивах его вытесняет более быстрый и функциональный инструмент ss (socket statistics).

Анализ всех TCP-соединений:

Устаревший способ: netstat -tnap
Современный и быстрый способ: ss -tnap

Флаги: -t (TCP), -n (числовые адреса, без DNS), -a (все), -p (показать процесс).

Как анализировать вывод:

State      Recv-Q Send-Q Local Address:Port  Peer Address:Port  Process
ESTAB      0      0      192.168.1.10:22     192.168.1.100:54322 users:(("sshd",pid=1234,fd=3))
TIME-WAIT  0      0      192.168.1.10:80     10.0.0.5:45010     users:(("nginx",pid=5678,fd=15))
LISTEN     0      128    0.0.0.0:22          0.0.0.0:*          users:(("sshd",pid=1234,fd=4))

Сгруппируйте вывод по состоянию, чтобы быстро оценить масштаб: ss -tnap | grep -oP '^\w+' | sort | uniq -c | sort -rn. Это покажет, каких состояний больше всего. Например, тысячи TIME-WAIT потребуют проверки настроек net.ipv4.tcp_tw_reuse и net.ipv4.tcp_fin_timeout в ядре.

Для глубокой диагностики сетевых проблем, таких как обрыв маршрутизации или высокий джиттер, обратитесь к нашему практическому руководству по диагностике сетевой маршрутизации с traceroute и mtr.

Алгоритм диагностики: как найти узкое место за 5 минут

Соберем все метрики и инструменты в единый пошаговый алгоритм действий при поступлении жалобы на низкую производительность.

Шаг 1: Общая картина. Запустите top или htop. Сразу смотрите на три вещи:
- Load Average: сравните с числом ядер CPU.
- Строка %Cpu(s): какая загрузка преобладает (us, sy, wa)?
- Строка памяти: низкий ли показатель available? Есть ли активность si/so (своп)?
Шаг 2: Детализация по выявленному направлению.
- Если высокий %us/%sy: В том же top отсортируйте процессы по %CPU (клавиша P). Определите, какой процесс потребляет ресурсы. Это приложение, база данных, скрипт?
- Если высокий %wa или подозрение на диск: В отдельном терминале запустите iostat -xz 2. Ищите высокие значения await и %util.
- Если проблема с памятью (низкий available, активный swap): В top отсортируйте процессы по %MEM (клавиша M). Выполните free -h для точного объема swap used.
- Если подозрение на сеть: Запустите ss -tnap и проверьте, нет ли аномального количества соединений в каком-либо состоянии. Проверьте статистику интерфейса командой ip -s link show eth0 (замените eth0 на ваш интерфейс).
Шаг 3: Принятие первоочередных мер. В зависимости от найденного узкого места:
- CPU: Оптимизация кода/запросов, ограничение ресурсов (cgroups), вертикальное (более мощный CPU) или горизонтальное (больше серверов) масштабирование.
- Память: Увеличение физической RAM, оптимизация настроек кэша приложения (например, для СУБД), поиск и устранение утечек памяти.
- Диск: Переход с HDD на SSD, оптимизация RAID-массива, проверка корректности работы файловой системы (например, для ZFS), настройка параметров монтирования (noatime).
- Сеть: Настройка сетевых параметров ядра (буферы, TCP-окна), проверка и обновление драйверов, настройка балансировки нагрузки.

Сценарий 1: Высокая загрузка CPU и медленный ответ сервиса

Симптомы: Веб-страницы грузятся минутами, API отвечает с таймаутами. Load Average = 8.0 на сервере с 4 ядрами.

Диагностика: 1. top показывает %us = 95%, %wa = 1%.
2. Сортировка по %CPU выявляет процесс php-fpm, потребляющий 70% CPU.
3. Команда ps auxf | grep php-fpm показывает множество дочерних процессов.

Возможные причины и действия: Неоптимизированный PHP-код (например, тяжелые циклы в скрипте), отсутствие кэширования запросов к БД. Первоочередные меры: анализ slow query log базы данных, включение OPcache для PHP, проверка нагрузки на backend. Для долгосрочного решения — профилирование кода и горизонтальное масштабирование пула php-fpm workers.

Сценарий 2: Активное использование swap и падение производительности

Симптомы: Сервер «подвисает», операции с диском происходят крайне медленно. Пользователи сообщают о полной недоступности.

Диагностика: 1. top показывает available memory ~ 50 MiB, swap used = 4.0G, активные значения si/so > 100.
2. Сортировка по %MEM показывает процесс Java-приложения, занимающий 12G RES при 16G общей памяти.

Возможные причины и действия: Недостаточно выделено памяти для Java Heap (Xmx), либо происходит утечка памяти (memory leak). Первоочередные меры: перезапуск проблемного приложения с увеличенным значением Xmx, анализ дампов памяти. Для долгосрочного решения — увеличение физической RAM на сервере, тщательная настройка параметров сборщика мусора JVM.

Если вы работаете с контейнеризованными приложениями, аналогичные принципы диагностики применимы и к Docker. В нашей полной шпаргалке по командам Docker вы найдете инструкции по мониторингу ресурсов (docker stats) и отладке контейнеров.

От оперативного мониторинга к планированию ресурсов

Данные, полученные с помощью разовых проверок top и iostat, можно и нужно использовать для стратегического планирования. Регулярный сбор ключевых метрик (например, через cron-скрипты, которые раз в минуту записывают вывод iostat и free в лог) позволяет строить графики и видеть тренды.

На что обращать внимание при анализе трендов:

Постепенный рост Load Average при стабильном количестве пользователей может указывать на «раздувание» кода или неэффективность новых функций.
Увеличение среднего await диска со временем — сигнал о том, что дисковое хранилище приближается к пределу своих возможностей и скоро потребует апгрейда (например, переход на NVMe).
Медленный, но неуклонный рост потребления памяти приложениями может предшествовать внезапному исчерпанию RAM и активному свопингу.

Эти данные становятся основанием для обоснования бюджета на IT-инфраструктуру: необходимость покупки более мощного сервера, добавления узлов в кластер или перехода на более производительное сетевое или дисковое оборудование. Для автоматизации такого долгосрочного мониторинга используются специализированные системы, такие как Prometheus с экспортерами node_exporter и Grafana для визуализации, которые логически продолжают принципы, изложенные в этой статье.

Важные предостережения и проверка на актуальность

Информация и команды в этой статье проверены на практике и актуальны для большинства современных дистрибутивов Linux (RHEL/CentOS 7/8, Rocky/AlmaLinux, Ubuntu 20.04/22.04) по состоянию на 2026 год. Однако важно учитывать следующие нюансы:

Различия в выводе инструментов. Названия и расположение некоторых колонок в выводе top или iostat могут незначительно отличаться между версиями пакетов procps и sysstat. Всегда обращайтесь к встроенной справке (man top, man iostat) для вашей конкретной версии.
Тестирование в безопасной среде. Перед использованием любых команд, которые могут потенциально нагрузить систему (например, нагрузочное тестирование диска), или изменением параметров ядра на основе диагностики, обязательно проверяйте их в тестовом окружении, максимально приближенном к продакшн.
Переход на современные аналоги. По возможности используйте ss вместо netstat и ip вместо ifconfig/route. Эти инструменты из пакета iproute2 поддерживаются активнее и предоставляют больше информации.

Для получения самой детальной и точной информации всегда обращайтесь к официальной документации вашего дистрибутива и man-страницам установленных утилит. Помните, что слепая копипаста команд из интернета без понимания контекста — главный риск для стабильности production-среды. Данное руководство призвано дать вам именно это понимание и надежный алгоритм действий.