vmstat и sar: классические инструменты анализа производительности

vmstat и sar — две классические утилиты Linux для анализа производительности сервера. Они не рисуют красивые графики, не требуют агента с веб-интерфейсом и не заменяют полноценный мониторинг, зато быстро отвечают на главный вопрос во время инцидента: система упирается в CPU, память, диск, swap или планировщик?

vmstat удобен для мгновенной диагностики «здесь и сейчас». Одна команда показывает очередь процессов, использование процессора, память, swap и базовую дисковую активность. sar, наоборот, полезен как «чёрный ящик»: он хранит исторические метрики и позволяет посмотреть, что происходило на сервере утром, ночью или за несколько минут до падения.

Эти инструменты особенно полезны, когда внешний мониторинг доступности уже сообщил о проблеме, но причина не очевидна. Например, Statuser может проверять сайт с заданным интервалом и прислать уведомление о сбое, а дальше администратор заходит на сервер и с помощью vmstat и sar выясняет, была ли проблема в нехватке ресурсов, дисковом I/O или системной нагрузке.

Когда использовать vmstat и sar

vmstat и sar решают близкие, но разные задачи.

vmstat показывает текущее состояние системы. Его запускают, когда сервер уже «тормозит», выросла задержка API, начали сыпаться 502, 503 или база отвечает медленно. Команда компактная, доступна почти везде и хорошо подходит для первого среза.

Пример:

vmstat 1

Такой запуск выводит статистику каждую секунду. Через несколько строк уже видно, где искать проблему: в очереди CPU, swap, диске или контекстных переключениях.

sar входит в пакет sysstat и собирает статистику в фоне. Его используют, когда нужно ответить на вопрос «что было раньше?». Например, приложение уже восстановилось, но ночью был всплеск ошибок. Если сбор sar был включён заранее, можно посмотреть CPU, память, диск, сеть и load average за нужный период.

Пример:

sar -u -s 03:00:00 -e 04:00:00

Команда покажет статистику CPU с 03:00 до 04:00.

Практическое разделение простое:

1) vmstat для live-диагностики — когда вы прямо сейчас подключились к серверу и хотите понять, что происходит.

2) sar для ретроспективы — когда инцидент уже прошёл или нужно сравнить текущую картину с обычным поведением.

3) Оба инструмента вместе — когда sar показывает исторический всплеск, а vmstat помогает проверить, сохраняется ли проблема сейчас.

Если вы выстраиваете мониторинг системно, полезно сочетать такие утилиты с метриками приложения и внешними проверками. Об общей логике метрик можно почитать в статье про четыре золотых сигнала в мониторинге.

Установка и базовый запуск

На многих Linux-серверах vmstat уже установлен, потому что входит в пакет procps или procps-ng. Проверить можно так:

vmstat --version

Если команды нет, установите пакет стандартным менеджером.

Для Debian и Ubuntu:

sudo apt update
sudo apt install procps sysstat

Для RHEL, AlmaLinux, Rocky Linux, CentOS:

sudo dnf install procps-ng sysstat

Для старых систем может использоваться yum:

sudo yum install procps-ng sysstat

После установки vmstat сразу готов к работе. Самые полезные варианты запуска:

vmstat
vmstat 1
vmstat 1 10
vmstat -S M 1

Что они делают:

1) vmstat — выводит один снимок статистики. Первый вывод часто содержит усреднённые значения с момента загрузки системы, поэтому для текущей диагностики он не всегда показателен.

2) vmstat 1 — обновляет данные каждую секунду до остановки через Ctrl+C.

3) vmstat 1 10 — делает 10 замеров с интервалом 1 секунда.

4) vmstat -S M 1 — показывает память в мегабайтах, что удобнее для чтения на больших серверах.

С sar есть важный нюанс: пакет sysstat нужно не только установить, но и включить сбор статистики.

В Debian/Ubuntu проверьте файл:

cat /etc/default/sysstat

Если там указано ENABLED="false", поменяйте на:

ENABLED="true"

Затем перезапустите сервис:

sudo systemctl enable --now sysstat
sudo systemctl restart sysstat

На системах с systemd сбор может быть организован через таймеры:

systemctl status sysstat
systemctl list-timers | grep sysstat

Проверить, появились ли данные, можно командой:

sar

Если статистика ещё не накопилась, подождите несколько минут. Исторические файлы обычно лежат в /var/log/sysstat/ или /var/log/sa/ — зависит от дистрибутива.

Как читать вывод vmstat

Типичный вывод vmstat 1 выглядит так:

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 524000 120000 1800000    0    0     1    20  900 1800 15  5 78  2  0
 8  1      0 300000 110000 1700000    0    0   120   800 2500 9000 70 15  5 10  0

Разберём основные группы.

1) procs: очередь процессов

Колонки:

• r — процессы, готовые выполняться и ожидающие CPU;
• b — процессы в непрерываемом ожидании, чаще всего I/O.

r нужно сравнивать с числом CPU-ядер или потоков. Если на сервере 4 vCPU, а r стабильно держится на уровне 8–12, CPU может быть узким местом. Разовый скачок не страшен, важна устойчивость во времени.

b показывает процессы, которые ждут не процессор, а обычно диск или блочное устройство. Если b растёт вместе с wa, стоит смотреть дисковую подсистему.

Подробнее о том, как интерпретировать общую нагрузку, полезно читать вместе со статьёй что такое load average в Linux. vmstat не заменяет load average, но помогает понять, из чего эта нагрузка состоит.

2) memory: память

Колонки:

• swpd — объём используемого swap;
• free — свободная память;
• buff — память под буферы;
• cache — page cache.

Новички часто пугаются малого free, но в Linux это нормально: свободная память используется под кэш. Смотреть нужно не только на free, а на поведение swap и давление на память.

Если free маленький, но si и so равны нулю, система может работать нормально. Если же активно растут si и so, начинается обмен со swap — это уже сигнал.

3) swap: обмен со swap

Колонки:

• si — сколько данных читается из swap;
• so — сколько записывается в swap.

Сам факт ненулевого swpd не всегда проблема. Сервер мог когда-то выгрузить неактивные страницы в swap и больше их не трогать. Опасны постоянные ненулевые si и so, особенно если одновременно растёт latency приложения.

Активный swap часто даёт «вязкие» симптомы: CPU может быть не загружен полностью, но приложение отвечает медленно, запросы копятся, health check иногда проходит, иногда нет.

4) io: блочный ввод-вывод

Колонки:

• bi — блоки, прочитанные с блочных устройств;
• bo — блоки, записанные на блочные устройства.

Эти показатели дают только грубую картину. Они полезны как индикатор: есть ли вообще активный дисковый I/O. Для детальной диагностики лучше подключать iostat, iotop и метрики latency. На эту тему есть отдельный разбор: iostat и iotop для диагностики дисковой нагрузки.

5) system: прерывания и переключения контекста

Колонки:

• in — interrupts, прерывания;
• cs — context switches, переключения контекста.

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

6) cpu: распределение процессорного времени

Колонки:

• us — пользовательское время;
• sy — системное время ядра;
• id — простой CPU;
• wa — ожидание I/O;
• st — stolen time, время, «украденное» гипервизором.

Если us высокий, CPU занят приложением. Если sy высокий, много времени уходит в ядро: сеть, файловая система, системные вызовы, контейнеризация, firewall, драйверы. Если высокий wa, CPU ждёт диск. Если высокий st, проблема может быть на уровне виртуализации: соседние VM на хосте, перепроданные ресурсы или ограничения провайдера.

Практические сценарии с vmstat

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

1) CPU насыщен

Признаки:

• r стабильно выше числа CPU;
• us + sy близко к 100%;
• id почти нулевой;
• wa низкий.

Команда:

vmstat 1 20

Если картина держится все 20 секунд, CPU действительно насыщен. Следующий шаг — найти процессы:

top
htop
ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | head

Для интерактивного просмотра удобнее использовать htop; подробный гайд есть в статье htop: мониторинг процессов.

2) Сервер ждёт диск

Признаки:

• высокий wa;
• заметный b;
• активные bi или bo;
• приложение тормозит, хотя CPU не полностью занят.

Такое часто бывает при тяжёлых запросах к базе, массовой записи логов, бэкапах, нехватке IOPS на VPS, медленном сетевом диске.

Следующие команды:

iostat -xz 1
iotop -oPa

Если проблема в latency диска, одного vmstat мало. Смотрите await, %util, очередь и процессы, которые генерируют I/O. Подробнее о диагностике задержек диска — в материале I/O latency: как измерять и находить узкие места.

3) Начался swap storm

Признаки:

• si и so постоянно ненулевые;
• free низкий;
• wa может расти;
• latency приложения резко увеличивается;
• иногда появляется OOM Killer.

Проверка:

free -h
vmstat -S M 1
dmesg -T | grep -i -E 'oom|killed process'

Дальше нужно искать, кто съел память:

ps -eo pid,ppid,cmd,%mem,rss --sort=-rss | head -20

Если процесс периодически умирает от нехватки памяти, полезно разобраться, как работает OOM Killer в Linux.

4) Высокий st на виртуальной машине

Признаки:

• st заметно выше нуля и держится;
• приложение тормозит без явного упора в собственный CPU;
• r может расти, но процессы фактически не получают процессорное время.

На bare metal st должен быть нулевым. Если он растёт на VPS, значит гипервизор отдаёт CPU другим гостевым машинам. Варианты ограничены: сменить тариф, перенести нагрузку, обратиться к провайдеру, проверить лимиты CPU.

5) Много переключений контекста

Признаки:

• резко вырос cs;
• sy выше обычного;
• много потоков или процессов;
• возможна высокая сетевая активность.

Сначала проверьте процессы:

pidstat -w 1
pidstat -t -p ALL 1

pidstat тоже входит в sysstat и помогает увидеть context switches по процессам и потокам.

sar: как смотреть историю системных метрик

sar хранит собранную статистику в бинарных файлах, которые потом можно просматривать разными ключами — в этом его главное отличие от vmstat. Если сайт был недоступен пять минут, а сейчас всё нормально, live-команды уже ничего не покажут, а sar подскажет, был ли всплеск CPU, swap, I/O или сети.

Базовые команды:

sar
sar -u
sar -r
sar -S
sar -b
sar -d
sar -n DEV
sar -q

Что они показывают:

1) sar -u — CPU: пользовательское время, системное время, ожидание I/O, простой, stolen time.

Пример:

sar -u 1 5

Это похоже на CPU-блок в vmstat, но sar также умеет читать историю:

sar -u -s 10:00:00 -e 11:00:00

2) sar -r — память: свободная память, used memory, buffers, cache, commit.

sar -r

Эта команда полезна для поиска плавных утечек памяти. Если kbmemused растёт часами, а затем процесс падает или начинается swap, есть повод смотреть приложение.

3) sar -S — swap.

sar -S

Показывает использование swap во времени. Но для активности обмена лучше смотреть paging:

sar -W
sar -B

-W покажет swap in/out, а -B — paging-активность.

4) sar -b и sar -d — дисковая активность.

sar -b
sar -d -p

-b даёт общую статистику I/O, -d — по устройствам. Ключ -p делает имена устройств более читаемыми, например sda, nvme0n1.

5) sar -n DEV — сетевые интерфейсы.

sar -n DEV

Можно увидеть входящий и исходящий трафик по интерфейсам. Для ошибок и дропов полезны дополнительные сетевые отчёты:

sar -n EDEV
sar -n TCP,ETCP

Если проблема похожа на сетевую, sar даст базовую историю, а дальше стоит использовать специализированные инструменты. Например, для анализа сетевого трафика есть tcpdump, а для мониторинга пропускной способности — iftop, nload и vnstat.

6) sar -q — load average и очередь.

sar -q

Команда показывает runq-sz, plist-sz, load average за 1, 5 и 15 минут. Это удобно для сравнения с vmstat r: sar показывает историю очереди, vmstat — текущую динамику.

Как посмотреть данные sar за нужный период

sar по умолчанию показывает данные за текущий день. Можно ограничивать интервал:

sar -u -s 14:00:00 -e 14:30:00

Если нужно открыть файл за конкретный день, используйте -f.

На Debian/Ubuntu:

sar -u -f /var/log/sysstat/sa27

На RHEL-подобных системах:

sar -u -f /var/log/sa/sa27

Где sa27 — файл за 27-е число месяца.

Полезные шаблоны:

sar -u -f /var/log/sysstat/sa27 -s 02:00:00 -e 03:00:00
sar -r -f /var/log/sysstat/sa27 -s 02:00:00 -e 03:00:00
sar -d -p -f /var/log/sysstat/sa27 -s 02:00:00 -e 03:00:00
sar -n DEV -f /var/log/sysstat/sa27 -s 02:00:00 -e 03:00:00

Для расследования инцидента удобно идти по слоям:

1) Начните с CPU

sar -u -s 02:00:00 -e 03:00:00

Смотрите iowait, %idle, %steal, соотношение %user и %system.

2) Проверьте очередь и load average

sar -q -s 02:00:00 -e 03:00:00

Если load вырос, но CPU был свободен, причина может быть в I/O или блокировках.

3) Проверьте память и swap

sar -r -s 02:00:00 -e 03:00:00
sar -W -s 02:00:00 -e 03:00:00

Активный swap в момент деградации — сильный сигнал.

4) Посмотрите диск

sar -d -p -s 02:00:00 -e 03:00:00

Если виден всплеск операций или загрузки устройства, сопоставьте его с бэкапами, cron-задачами, ротацией логов, тяжёлыми SQL-запросами.

5) Посмотрите сеть

sar -n DEV -s 02:00:00 -e 03:00:00
sar -n TCP,ETCP -s 02:00:00 -e 03:00:00

Это помогает отличить локальную нехватку ресурсов от всплеска трафика, retransmits или ошибок сетевого уровня.

Если внешний мониторинг показал недоступность сайта, а пользователи жаловались на таймауты, полезно сопоставить время уведомления с системными метриками. Сервис вроде Statuser фиксирует факт недоступности снаружи, а sar помогает понять, что происходило внутри сервера в тот же момент.

Связка vmstat, sar и других инструментов

vmstat и sar хороши как первый и второй уровень диагностики. Но они не должны быть единственными инструментами.

Рабочая схема может выглядеть так:

1) Получили сигнал о проблеме

Это может быть алерт от внешней проверки, жалоба пользователя, рост 5xx, медленные запросы в APM или падение health check. Если вы ещё не используете внешние проверки, базовые принципы описаны в статье что такое uptime monitoring и как он работает.

2) Сняли текущий срез через vmstat

vmstat -S M 1 30

За 30 секунд видно, есть ли устойчивый паттерн: CPU, диск, swap, stolen time.

3) Проверили историю через sar

sar -u -s 12:00:00 -e 12:30:00
sar -q -s 12:00:00 -e 12:30:00
sar -r -s 12:00:00 -e 12:30:00
sar -d -p -s 12:00:00 -e 12:30:00

Так вы понимаете, проблема началась внезапно или нарастала.

4) Уточнили виновника специализированными утилитами

• CPU и процессы: top, htop, pidstat, perf;
• диск: iostat, iotop, pidstat -d;
• сеть: ss, tcpdump, iftop;
• память: free, smem, pmap, логи OOM;
• сервисы: journalctl, логи приложения.

5) Сопоставили с изменениями

Проверьте деплой, cron, бэкапы, миграции, ротацию логов, обновления пакетов, изменение трафика, действия в базе. Метрики без контекста часто показывают симптом, но не причину.

Если расследование не ограничивается одним сервером, полезен пошаговый подход из материала как расследовать деградацию производительности по метрикам.

Типичные ошибки при интерпретации

У vmstat и sar простой интерфейс, но ошибиться в выводах легко.

1) Делать вывод по первой строке vmstat

Первый вывод vmstat часто отражает средние значения с момента загрузки, а не текущую секунду. Для диагностики запускайте vmstat 1 10 или vmstat 1 30 и анализируйте последующие строки.

2) Считать любой swap проблемой

Ненулевой swpd не означает катастрофу. Проблема — активный обмен: ненулевые si и so, рост задержек, падение производительности.

3) Оценивать CPU без iowait и steal

Если %idle низкий, это ещё не всегда «приложение съело CPU». Смотрите us, sy, wa, st. Высокий wa ведёт к диску, высокий st — к гипервизору, высокий sy — к ядру и системным операциям.

4) Игнорировать базовую линию

Значение cs, in, bi, bo само по себе мало что говорит. Для одного сервера 5000 context switches в секунду нормально, для другого — аномалия. История sar помогает понять норму.

5) Путать причину и следствие

Высокий load average может быть следствием дискового ожидания, а не нехватки CPU. Рост сетевого трафика может быть не атакой, а результатом ретраев клиентов после деградации базы. Всегда проверяйте несколько метрик вместе.

6) Ждать от sar детализации уровня APM

sar показывает системные метрики, но не скажет, какой SQL-запрос медленный или какой endpoint генерирует нагрузку. Для этого нужны логи, трассировки, профилировщики, метрики приложения и базы.

FAQ

Что лучше использовать: vmstat или sar?

Для текущей диагностики — vmstat. Для анализа прошлых событий — sar. На практике они дополняют друг друга.

Почему первый вывод vmstat отличается от следующих?

Первая строка часто показывает средние значения с момента загрузки системы. Для актуальной картины запускайте vmstat 1 и смотрите последующие строки.

Нужно ли постоянно держать включённым sar?

Обычно да. Он создаёт небольшую нагрузку и даёт полезную историю для расследования инцидентов. Без заранее включённого сбора прошлые метрики восстановить нельзя.

Может ли vmstat показать, какой процесс тормозит сервер?

Нет, напрямую не может. vmstat показывает состояние системы в целом. Для поиска процесса используйте top, htop, pidstat, iotop, ps и логи приложения.