Освоение производительности: практическое руководство по использованию набора инструментов Sysstat

Работа с производительностью становится запутанной, когда у вас есть только текущий момент. Сервер медленный сейчас, но был ли он медленным десять минут назад? Начала ли дисковая подсистема отставать до того, как выросла загрузка ЦП? Началась ли проблема после задания cron, развертывания или окна резервного копирования? Набор инструментов sysstat полезен тем, что предоставляет как показатели в реальном времени, так и историческую запись, с которой можно сравнивать.

Основной инструмент — sar, Reporter системной активности. Я обращаюсь к нему, когда top слишком краток, когда инцидент уже прошел, или когда мне нужно показать, что проблема была в хранилище, давлении на память, сетевом трафике или насыщении ЦП, а не гадать по симптомам. Остальная часть пакета, особенно iostat и mpstat, заполняет детали, когда sar указывает на вероятное узкое место.

Это не замена полной наблюдаемости. Вам все еще нужны метрики приложений, журналы, трассировка и внешние проверки. Но на хосте Linux sysstat — один из самых быстрых способов ответить на первый практический вопрос: что на самом деле делала машина?

1. Установка и начальная настройка Sysstat

Пакет sysstat обычно доступен в стандартных репозиториях всех основных дистрибутивов Linux.

1.1 Команды установки

Используйте соответствующую команду менеджера пакетов для вашей системы:

Debian/Ubuntu:

sudo apt update
sudo apt install sysstat

RHEL/CentOS/Fedora:

sudo yum install sysstat
# или используйте dnf для более новых систем
sudo dnf install sysstat

1.2 Включение сбора исторических данных

Чтобы sar был действительно полезен, он должен собирать данные исторически. По умолчанию установка часто настраивает задание cron или таймер systemd, но проверка имеет решающее значение.

На современных системах убедитесь, что служба sysstat активна:

sudo systemctl enable --now sysstat

Файл конфигурации

Частота сбора данных контролируется файлами конфигурации, обычно расположенными в /etc/default/sysstat (Debian/Ubuntu) или /etc/sysconfig/sysstat (RHEL/CentOS). Найдите настройку ENABLED или HISTORY. Установка ENABLED="true" обеспечивает ежедневный сбор данных.

Совет: По умолчанию файлы данных sysstat хранятся в /var/log/sa/ с именами файлов, такими как saXX, где XX — день месяца. Некоторые системы на основе Debian также предоставляют отчеты в /var/log/sysstat/. Проверьте значения по умолчанию вашего пакета, прежде чем предполагать путь.

После включения сбора подождите хотя бы один интервал и убедитесь, что файлы появляются:

ls -lh /var/log/sa/

Если каталог пуст, проверьте таймеры systemd:

systemctl list-timers | grep sysstat
systemctl status sysstat-collect.timer

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

2. Основная утилита: Reporter системной активности (sar)

sar — это основной интерфейс для просмотра статистики. Он может отображать данные в реальном времени или анализировать ранее собранные исторические данные.

2.1 Базовый синтаксис для мониторинга в реальном времени

Базовый синтаксис предназначен для отчета по определенным метрикам с заданным интервалом и заданным количеством раз.

sar [опции] [интервал] [количество]

Пример: Для отчета общей статистики ЦП каждые 3 секунды, 10 раз:

sar -u 3 10

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

Опция	Описание
-u	Загрузка ЦП (по умолчанию)
-r	Статистика памяти и подкачки
-d	Активность блочных устройств (дисковый ввод-вывод)
-n	Сетевая статистика (например, -n DEV для статистики интерфейсов)
-q	Очередь выполнения и средняя нагрузка
-W	Активность свопинга (подкачка страниц)
-A	Все метрики (полезно для всесторонних снимков)

Для исторических файлов форма тот же. Вы добавляете -f, чтобы выбрать файл данных, и часто -s и -e, чтобы ограничить временной диапазон. Это важно, потому что чтение целого дня вывода во время сбоя медленно и шумно.

3. Ключевые метрики производительности и практические примеры sar

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

3.1 Загрузка ЦП (sar -u)

Загрузка ЦП часто является первым местом для поиска узких мест. Высокая загрузка в определенных категориях указывает на характер рабочей нагрузки.

sar -u 5 3

Метрика	Описание	Индикатор узкого места
%user	Время ЦП, затраченное на выполнение пользовательских процессов.	Высокое значение указывает на насыщение приложения/службы.
%system	Время ЦП, затраченное на выполнение задач ядра/системы.	Высокое значение предполагает интенсивные системные вызовы или проблемы с драйверами.
%iowait	Время ЦП, простаивающего в ожидании операций ввода-вывода (диск/сеть).	Высокое значение указывает на узкое место ввода-вывода, а не на нехватку ЦП.
%idle	Время ЦП, проведенное в ожидании ничего (доступно).	Низкое (например, < 5%) указывает на насыщение ЦП.

Будьте осторожны с %iowait. Его часто неправильно понимают как "ЦП занят диском". На самом деле это означает, что ЦП простаивал, пока был активен по крайней мере один запрос ввода-вывода. Высокое значение может указывать на задержку хранилища, но требует подтверждения с помощью метрик диска. На сервере базы данных, например, высокий %iowait в сочетании с высоким await диска является гораздо более сильным сигналом, чем %iowait сам по себе.

Другой полезный вид ЦП — очередь выполнения:

sar -q 5 5

runq-sz показывает, сколько задач ожидают выполнения. Если средняя нагрузка высока, но runq-sz скромен, а %iowait высок, возможно, вы имеете дело с заблокированным вводом-выводом, а не с чистым давлением на ЦП. Если runq-sz остается высоким, а %idle близок к нулю, машине, вероятно, нужно меньше выполняемых процессов, более быстрый код или больше мощности ЦП.

3.2 Память и подкачка (sar -r и sar -W)

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

Использование памяти (sar -r):

sar -r 1 5

Сосредоточьтесь на kbavail (доступная память). Если kbmemfree низок, но kbcached и kbbuffers высоки, память используется эффективно механизмом кэширования ядра.

Активность свопинга (sar -W):

sar -W 1 5

Посмотрите на pswpin/s (страницы, подкачанные в память) и pswpout/s (страницы, выгруженные из памяти). Любые значительные ненулевые значения здесь указывают на то, что система активно свопирует, что сигнализирует о давлении на память (сильное узкое место).

Вывод памяти Linux может выглядеть тревожно, пока вы не вспомните, что кэш — это не потраченная впустую память. Сервер с очень малым kbmemfree может быть здоров, если kbavail комфортен, а активность свопинга отсутствует. Опасный паттерн другой: доступная память падает, появляется активность подкачки и выгрузки, а задержка приложения растет. Это говорит о том, что процессы обращаются к памяти, которая больше не помещается в ОЗУ.

Для веб-сервера это может произойти после развертывания, которое случайно удваивает количество рабочих процессов. Для пакетного хоста это может произойти, когда перекрываются две большие задачи. sar не скажет вам, какой процесс это вызвал, но даст временную шкалу. Сопоставьте ее с ps, top, журналами служб или метриками cgroup, чтобы определить владельца.

3.3 Активность дискового ввода-вывода (sar -d)

Мониторинг активности диска имеет решающее значение для серверов баз данных или систем с интенсивным использованием хранилища.

sar -d 3 5

Этот вывод требует идентификации конкретных устройств (например, sda, vda). Ключевые метрики включают:

• tps: Количество передач в секунду (высокое значение указывает на высокую нагрузку запросов ввода-вывода).
• rd_sec/s и wr_sec/s: Количество данных, прочитанных/записанных в секунду.
• %util: Процент времени, в течение которого устройство было занято обслуживанием запросов. Если %util остается около 100% на традиционном блочном устройстве, хранилище может быть насыщено.

На современных SSD и виртуальных дисках %util требует контекста. Некоторые устройства хорошо обрабатывают параллельный ввод-вывод, а облачные тома могут быть ограничены предоставленными IOPS, пропускной способностью или кредитами burst. Относитесь к %util как к приглашению присмотреться, а не как к полному диагнозу. Подтвердите с помощью iostat -xd, задержки приложения и метрик хранилища на уровне платформы, если вы работаете в AWS, Azure, GCP или другой виртуализированной среде.

Один практический рабочий процесс:

sar -d -f /var/log/sa/sa24 -s 09:00:00 -e 10:00:00
iostat -xd 2 5

Используйте sar, чтобы найти плохой час, затем используйте iostat во время повторения в реальном времени для проверки задержки на уровне устройства.

3.4 Сетевая статистика (sar -n)

sar может сообщать об активности на различных сетевых уровнях. Наиболее распространенная проверка — активность интерфейса (DEV).

sar -n DEV 5 1

Эта команда показывает метрики, такие как rxpk/s (полученные пакеты в секунду) и txkB/s (переданные килобайты в секунду) для каждого сетевого интерфейса. Используйте это для идентификации интерфейсов, испытывающих высокую нагрузку или потенциальные ошибки.

Для счетчиков ошибок добавьте EDEV:

sar -n EDEV 5 3

Это может показать ошибки приема, ошибки передачи, сбросы и коллизии, где это поддерживается драйвером. Сбросы особенно полезны, когда служба жалуется на периодические тайм-ауты, но ЦП и диск выглядят нормально. Если сбросы растут во время пиков трафика, возможно, вам нужно проверить очереди NIC, настройки сетевого ядра, контейнерную сеть или путь балансировщика нагрузки.

Для поведения на уровне TCP попробуйте:

sar -n TCP,ETCP 5 3

Повторные передачи, сбросы и неудачные попытки подключения могут превратить расплывчатый отчет "сайт медленный" в более конкретную сетевую проблему или проблему вышестоящего сервера.

4. Исторический анализ и создание базовых показателей

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

4.1 Анализ предыдущих дней

Чтобы просмотреть данные, собранные за предыдущий день, используйте флаг -f, чтобы указать путь к ежедневному файлу saXX.

Пример: Для просмотра статистики ЦП за 10-й день текущего месяца:

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

Чтобы просмотреть статистику за определенный временной интервал в этот день, добавьте флаги -s (время начала) и -e (время окончания) (используя 24-часовой формат).

# Просмотр сетевой статистики с 14:00 до 16:30 10-го числа
sar -n DEV -f /var/log/sa/sa10 -s 14:00:00 -e 16:30:00

4.2 Установление базовых показателей

1. Сбор данных: Запустите sysstat в периоды нормальной высокой и низкой нагрузки.
2. Определение норм: Проанализируйте исторические данные (sar -f), чтобы определить среднюю загрузку ЦП (%user, %system), пиковую задержку ввода-вывода (%util) и среднее использование памяти.
3. Определение порогов: Относитесь к устойчивым отклонениям от вашего собственного базового уровня как к триггерам для расследования. Занятой хост базы данных и тихая перемычка не должны иметь одинаковые пороги.

Базовые показатели более полезны, когда они привязаны к реальным бизнес-ритмам. Пакетный импорт в понедельник утром, ночное резервное копирование и запуск продукта создают разные "нормальные" формы. Делайте заметки, когда проводите расследование: "резервное копирование началось в 01:00", "новый релиз в 14:30", "маркетинговое письмо в 09:05". Эти заметки сделают исторический вывод sar гораздо более легким для интерпретации в будущем.

5. Вспомогательные инструменты Sysstat

Хотя sar является основным инструментом, пакет sysstat включает специализированные утилиты, которые предоставляют целенаправленные, детализированные отчеты.

5.1 iostat (Статистика ввода-вывода)

iostat предоставляет подробные метрики, специально ориентированные на использование устройств, особенно полезные при диагностике узких мест хранилища.

# Отчет статистики диска каждые 2 секунды, 4 раза, включая расширенную статистику (x)
iostat -xd 2 4

Ключевые метрики iostat:

• %util: Процент времени ЦП, в течение которого запросы ввода-вывода отправлялись на устройство (важный индикатор насыщения).
• await: Среднее время ожидания (в миллисекундах) для запросов ввода-вывода, отправленных на устройство. Высокий await указывает на медленную реакцию хранилища.

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

5.2 mpstat (Статистика многопроцессорных систем)

Если вы подозреваете проблемы с планированием ЦП или неравномерное распределение рабочей нагрузки между ядрами, mpstat предоставляет статистику использования на процессор, которую sar -u агрегирует.

# Показать использование для всех ЦП (A) каждые 2 секунды
mpstat -P ALL 2 1

Это бесценно для выявления однопоточных приложений, которые насыщают одно ядро, пока другие простаивают, или для диагностики эффективности гиперпоточности.

5.3 sadf (Экспорт данных Sysstat)

sadf читает те же собранные данные, что и sar, но может выводить их в форматах, которые легче потребляются скриптами и панелями мониторинга.

sadf -d /var/log/sa/sa24 -- -u
sadf -j /var/log/sa/sa24 -- -r

Вывод -d полезен для обработки текста с разделителями. Вывод -j полезен, когда вам нужен JSON. Это удобно, когда вам нужно прикрепить доказательства к обзору инцидента или сравнить два хоста без ручного копирования вывода терминала.

6. Практический разбор инцидента

Представьте сервер API, который начал выдавать тайм-ауты в 10:15. Журналы приложения показывают накопление запросов, но не объясняют почему. Начните с исторического представления ЦП:

sar -u -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

Если %user высок, а %idle низок, приложение может быть ограничено по ЦП. Проверьте использование на ядро:

sar -P ALL -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

Если одно ядро загружено на 100%, а другие простаивают, подозревайте однопоточный рабочий процесс, горячую блокировку или неравномерное распределение процессов. Если все ядра заняты, посмотрите на частоту запросов, недавние развертывания и дорогие участки кода.

Если ЦП в основном простаивает, но %iowait растет, переключитесь на диск:

sar -d -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

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

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

sar -r -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00
sar -W -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00
sar -n DEV,EDEV,TCP,ETCP -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

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

Простая рабочая привычка

Лучший способ изучить sysstat — использовать его до того, как что-то сломается. Проверьте здоровый сервер во время нормального трафика. Проверьте его во время резервного копирования. Проверьте его после развертывания. Сохраните несколько шаблонов команд, которые соответствуют вашей среде.

Когда произойдет инцидент, вы уже будете знать, как выглядит норма. В этом и заключается реальная ценность набора инструментов. sar, iostat, mpstat и sadf не диагностируют приложение магическим образом, но они удерживают разговор на основе доказательств: когда началась проблема, какой ресурс изменился и был ли хост на самом деле под давлением.