Как отслеживать производительность Linux с помощью инструментов Sysstat?

Sysstat — это набор утилит для мониторинга производительности в Linux, в который входят mpstat, pidstat, iostat и sar; вместе они дают вам возможность отслеживать в режиме реального времени и просматривать историю всех процессов, происходящих в системе.

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

В реальных проблемах с производительностью Linux процессор редко является единственным фактором, но узкие места обычно возникают из-за взаимодействия нескольких подсистем системы:

Интересно: Authelia - сервер аутентификации и авторизации с открытым исходным кодом

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

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

Ключевые инструменты в наборе sysstat:

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

Эти инструменты работают одинаково во всех современных дистрибутивах Linux, включая Ubuntu и RHEL, при условии, что установлена версия sysstat 12.x или более поздней.

Для анализа на уровне диска, такого как пропускная способность, задержка и глубина очереди, iostat используется вместе с vmstat в рамках более глубокого рабочего процесса устранения неполадок производительности.

Установка Sysstat в Linux

Sysstat по умолчанию не поставляется в большинстве дистрибутивов, поэтому перед запуском любой из приведенных ниже команд убедитесь, что он установлен, и проверьте версию, поскольку некоторые флаги, такие как %wait в pidstat и %ifutil в sar, были добавлены в более поздних выпусках и не будут работать в старых пакетах.

Интересно: Автоматизация уведомлений для мониторинга серверов Linux

Чтобы установить Sysstat в Linux, используйте следующую команду, соответствующую вашему конкретному дистрибутиву Linux.

sudo apt install sysstat         [On Debian, Ubuntu and Mint]
sudo dnf install sysstat         [On RHEL/CentOS/Fedora and Rocky/AlmaLinux]
sudo apk add sysstat             [On Alpine Linux]
sudo pacman -S sysstat           [On Arch Linux]
sudo zypper install sysstat      [On OpenSUSE]    
sudo pkg install sysstat         [On FreeBSD]

Проверьте установку с помощью:

mpstat -V

Вывод:

sysstat version 12.6.1
(C) Sebastien Godard (sysstat  orange.fr)

Если вы видите command not found, установка не завершилась или /usr/bin отсутствует в вашем PATH, поэтому запустите which mpstat, чтобы убедиться, что бинарный файл существует. В Ubuntu вам также необходимо включить сбор данных, установив ENABLED="true" в /etc/default/sysstat, который по умолчанию отключен.

mpstat: мониторинг использования процессора в Linux

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

1. Отображение общей статистики ЦП

Запуск mpstat без каких-либо опций выводит один снимок средней загрузки ЦП по всем процессорам с момента загрузки, что дает вам базовые данные перед тем, как углубляться в цифры по ядрам или процессам.

mpstat

Вывод:

Linux 6.8.0-45-generic (web01.tecmint.com)   05/04/2026  _x86_64_  (4 CPU)
14:22:10     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
14:22:10     all   18.43    0.02    3.11    1.24    0.00    0.09    0.00    0.00    0.00   77.11

Столбец %iowait — первый, который нужно проверить, поскольку любое значение, стабильно превышающее 10–15%, означает, что система заблокирована в ожидании чтения или записи с диска, и увеличение загрузки процессора здесь не поможет. Столбец %soft отслеживает время, затраченное на обработку программных прерываний, и всплеск в этом столбце обычно указывает на перегрузку сетевого интерфейса, а не на проблему с вычислениями.

2. Отображение статистики для каждого отдельного процессора

Флаг -P ALL разбивает общую строку сводки на отдельные строки для каждого процессора, что сразу показывает, выполняет ли одно ядро всю работу, пока остальные простаивают.

mpstat -P ALL

Вывод:

Linux 6.8.0-45-generic (web01.tecmint.com)   05/04/2026  _x86_64_  (4 CPU)
14:23:05     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
14:23:05     all   18.51    0.02    3.14    1.26    0.00    0.10    0.00    0.00    0.00   76.97
14:23:05       0   72.14    0.00    5.22    0.00    0.00    0.00    0.00    0.00    0.00   22.64
14:23:05       1   14.32    0.03    2.88    0.52    0.00    0.08    0.00    0.00    0.00   82.17
14:23:05       2   10.44    0.02    2.71    1.98    0.00    0.12    0.00    0.00    0.00   84.73
14:23:05       3    8.11    0.01    1.75    3.52    0.00    0.09    0.00    0.00    0.00   86.52

CPU 0 использует 72% пользовательского времени, в то время как остальные 3 в основном простаивают, что является классическим признаком однопоточного процесса, загружающего одно ядро, и pidstat (описанный ниже) точно покажет, какой именно это процесс. Вы также можете выбрать отдельный процессор по номеру, как в mpstat -P 0, что полезно в системах с большим количеством ядер, когда вы хотите наблюдать только за одним.

3. Мониторинг активности процессора в реальном времени

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

mpstat -P ALL 2 5

Вывод:

Linux 6.8.0-45-generic (web01.tecmint.com)   05/04/2026  _x86_64_  (4 CPU)
14:25:10     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
14:25:12     all   21.34    0.00    2.88    0.00    0.00    0.00    0.00    0.00    0.00   75.78
14:25:12       0   74.50    0.00    2.00    0.00    0.00    0.00    0.00    0.00    0.00   23.50
14:25:12       1   15.22    0.00    3.11    0.00    0.00    0.00    0.00    0.00    0.00   81.67
14:25:12       2   11.04    0.00    2.88    0.00    0.00    0.00    0.00    0.00    0.00   86.08
14:25:12       3    9.12    0.00    1.44    0.00    0.00    0.00    0.00    0.00    0.00   89.44
...
Average:     all   19.87    0.01    3.02    0.88    0.00    0.08    0.00    0.00    0.00   76.14

Строка Average: в конце суммирует все 5 выборок, поэтому вы можете с первого взгляда определить, оставался ли CPU 0 загруженным в течение всего окна или у него был лишь один кратковременный всплеск. Синтаксис 2 5 означает собрать 5 показаний, по одному каждые 2 секунды, и вы можете убрать счетчик, чтобы программа работала бесконечно, пока вы не нажмете Ctrl + C.

4. Мониторинг статистики прерываний по процессорам

Флаг -I показывает количество прерываний в секунду для каждой линии IRQ на всех процессорах, и это подходящий инструмент при отладке перегруженной сетевой Карты или контроллера хранения, которые привязывают все свои прерывания к одному ядру.

mpstat -I

Вывод:

Linux 6.8.0-45-generic (web01.tecmint.com)   05/04/2026  _x86_64_  (4 CPU)
14:27:19     CPU    intr/s
14:27:19     all    742.18
14:27:19     CPU     NET_TX/s   NET_RX/s    BLOCK/s   SCHED/s      RCU/s
14:27:19       0         0.04       1.44       9.22      12.44      41.22
14:27:19       1         0.04       2.01       8.88      11.97      44.11
14:27:19       2         0.05       1.88       9.04      12.11      42.88
14:27:19       3         0.03       1.92       8.76      11.88      43.04

Высокое значение NET_RX/s, сконцентрированное на одном процессоре, в сочетании с высоким значением %soft в примере 1 означает, что ваша сетевая карта привязана к одному ядру, и запуск irqbalance или ручная настройка привязки IRQ с помощью /proc/irq/<n>/smp_affinity распределит эту нагрузку прерываний по ядрам.

5. Отображение всей статистики ЦП и прерываний вместе

Флаг -A эквивалентен одновременному запуску -u -I ALL -P ALL, что дает вам полный однократный дамп использования ЦП и количества прерываний для каждого процессора в одной команде.

mpstat -A

Вывод:

Linux 6.8.0-45-generic (web01.tecmint.com)   05/04/2026  _x86_64_  (4 CPU)
14:30:01     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
14:30:01     all   18.43    0.02    3.11    1.24    0.00    0.09    0.00    0.00    0.00   77.11
14:30:01       0   72.14    0.00    5.22    0.00    0.00    0.00    0.00    0.00    0.00   22.64
14:30:01       1   14.32    0.03    2.88    0.52    0.00    0.08    0.00    0.00    0.00   82.17
...
14:30:01     CPU    intr/s
14:30:01     all    742.18
14:30:01       0    188.14
14:30:01       1    192.44

Чтобы перенаправить вывод в файл журнала с отметкой времени, используйте:

mpstat -A >> /var/log/mpstat-$(date +%F).log

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

pidstat — это инструмент, к которому вы обращаетесь после того, как mpstat выявил «горячий» ЦП, поскольку он точно показывает, какой процесс или поток ответственен за потребление ресурсов.

В отличие от top, он предоставляет исторический контекст, разбивку по вводу-выводу и видимость на уровне потоков в формате, который можно передавать по конвейеру и анализировать без каких-либо дополнительных инструментов.

6. Вывод списка всех активных процессов и использования ЦП

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

pidstat

Вывод:

Linux 6.8.0-45-generic (web01.tecmint.com)   05/04/2026  _x86_64_  (4 CPU)
14:32:44     UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
14:32:44       0         1    0.01    0.08    0.00    0.00    0.09     1  systemd
14:32:44       0       512    0.00    0.04    0.00    0.00    0.04     0  kworker/0:1H
14:32:44    1000      2841   18.44    0.88    0.00    0.00   19.32     0  python3
14:32:44    1000      3102    0.12    0.04    0.00    0.00    0.16     2  nginx

Столбец %wait, добавленный в sysstat 11.5, показывает время, которое процесс потратил на ожидание запуска на ЦП, даже если он был готов к запуску, и устойчивые ненулевые значения здесь означают, что у вас в очереди больше работы, чем доступных ядер, что является перегрузкой ЦП, а не медленным процессом.

Столбец CPU показывает, на каком ядре каждый процесс запускался в последний раз, что напрямую соотносится с «горячим» ядром, которое вы определили в примере 2.

7. Просмотр всех процессов, включая неактивные

По умолчанию в окне просмотра не отображаются процессы с нулевой активностью ЦП с момента загрузки. Добавление -p ALL включает все процессы, в том числе спящие, что полезно, когда вам нужен полный список PID для конкретного приложения или вы хотите убедиться, что служба действительно работает.

pidstat -p ALL

Вывод:

Linux 6.8.0-45-generic (web01.tecmint.com)   05/04/2026  _x86_64_  (4 CPU)
14:33:11     UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
14:33:11       0         1    0.01    0.08    0.00    0.00    0.09     1  systemd
14:33:11       0         2    0.00    0.00    0.00    0.00    0.00     0  kthreadd
14:33:11       0         3    0.00    0.00    0.00    0.00    0.00     0  rcu_gp
14:33:11       0         4    0.00    0.00    0.00    0.00    0.00     0  rcu_par_gp
14:33:11    1000      2841   18.44    0.88    0.00    0.00   19.32     0  python3

Записи kworker и rcu_* — это рабочие потоки ядра, а не пользовательские процессы, и их появление с ненулевым использованием ЦП может указывать на проблемы с драйверами или файловой системой, которые стоит изучить подробнее. Если в этом выводе отсутствует служба, которую вы ожидали увидеть, значит, она вообще не запущена.

8. Мониторинг дискового ввода-вывода по процессам

Флаг -d переключает отображение с ЦП на дисковый ввод-вывод и показывает количество килобайт, прочитанных и записанных в секунду для каждого процесса. Это самый быстрый способ определить, какое приложение перегружает ваше хранилище во время эпизода с высоким iowait.

pidstat -d 2

Вывод:

Linux 6.8.0-45-generic (web01.tecmint.com)   05/04/2026  _x86_64_  (4 CPU)
14:35:22          PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  Command
14:35:24         1221      0.00    148.00      2.00       0  rsyslogd
14:35:24         2841    412.00     88.00      4.00      12  python3
14:35:24         3210      0.00     22.00      0.00       0  postgres

Колонка kB_ccwr/s показывает отменённые байты записи, то есть страницы, которые были поставлены в очередь на запись на диск, но затем были аннулированы до того, как были сброшены, и высокие значения указывают на то, что процесс записывает и сразу же перезаписывает одни и те же данные в плотном цикле.

Колонка iodelay подсчитывает такты, которые процесс потратил в блокировке, ожидая завершения ввода-вывода, и ненулевое значение здесь наряду с высоким значением %iowait из mpstat подтверждает, что именно этот процесс является виновником загрузки ввода-вывода.

9. Показать использование ЦП по потокам

Флаг -t разбивает процесс на отдельные потоки, что необходимо для многопоточных приложений, где один поток отвечает за всю повышенную нагрузку на ЦП, в то время как остальные находятся в режиме ожидания.

pidstat -t -p 2841 2 3

Вывод:

Linux 6.8.0-45-generic (web01.tecmint.com)   05/04/2026  _x86_64_  (4 CPU)
14:37:08     UID      TGID       TID    %usr %system  %guest   %wait    %CPU   CPU  Command
14:37:10    1000      2841         -   18.00    0.88    0.00    0.00   18.88     0  python3
14:37:10    1000         -      2841   17.50    0.50    0.00    0.00   18.00     0  |__python3
14:37:10    1000         -      2844    0.50    0.38    0.00    0.00    0.88     1  |__ThreadPool-1
14:37:10    1000         -      2845    0.00    0.00    0.00    0.00    0.00     2  |__GC-thread

Замените 2841 на PID процесса, который вы хотите проверить; его можно получить из pgrep <process-name>, если у вас его еще нет.

Иерархия, представленная символами «вертикальная черта» и «подчеркивание», показывает все дочерние потоки под главным процессом, поэтому сразу становится ясно, что главный поток выполняет почти всю работу, в то время как ThreadPool-1 и GC-thread практически неактивны.

10. Мониторинг использования памяти по процессам

Флаг -r отображает виртуальный размер, размер резидентного набора и частоту ошибок страниц для каждого процесса, а флаг -h выводит данные в компактном однострочном формате без повторения заголовка в каждой выборке, что упрощает непрерывный Мониторинг.

pidstat -rh 2 3

Вывод:

Time   UID       PID  minflt/s  majflt/s     VSZ    RSS   %MEM  Command
1746353842  1000      2841   3412.00      0.00  812448 312200   7.68  python3
1746353842  1000      3102    128.22      0.00  142312  44820   1.10  nginx
1746353842     0      1201    644.00      0.00  506728 316788   7.80  Xorg

Столбец majflt/s — это то, на что нужно обратить внимание, потому что крупная ошибка страницы означает, что ядру пришлось обратиться к диску, чтобы извлечь страницу памяти из swap, а устойчивые ненулевые значения здесь означают, что система активно использует подкачку и что этот процесс является ее причиной.

Незначительные ошибки, такие как minflt/s, не требуют больших затрат ресурсов — это просто отображение ядром страниц, которые уже находятся в ОЗУ, но серьезные ошибки требуют значительных затрат и заметно ухудшают время отклика приложений.

11. Фильтрация процессов по имени

Флаг -G фильтрует вывод, отображая только те процессы, имя команды которых совпадает с заданной строкой, поэтому вам не нужно пролистывать полный список процессов, чтобы найти приложение, за которым вы наблюдаете.

pidstat -G nginx

Вывод:

Linux 6.8.0-45-generic (web01.tecmint.com)   05/04/2026  _x86_64_  (4 CPU)
14:40:18     UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
14:40:18    1000      3102    0.12    0.04    0.00    0.00    0.16     2  nginx
14:40:18    1000      3103    0.08    0.02    0.00    0.00    0.10     3  nginx

Совместите с -t, чтобы развернуть информацию по потокам, запустив pidstat -t -G nginx, или добавьте интервал для непрерывного мониторинга с помощью pidstat -G nginx 2.

Если -G ничего не возвращает, это означает, что имя процесса не совпадает точно, поэтому проверьте фактическую строку команды с помощью ps aux | grep nginx, прежде чем делать вывод, что служба не запущена.

12. Отображение приоритета и политики планирования в реальном времени

Флаг -R сообщает о политике планирования и приоритете в реальном времени для каждого процесса, и его стоит запустить, когда приложение, чувствительное к задержкам, не получает время процессора, несмотря на низкую общую загрузку системы.

pidstat -R

Вывод:

Linux 6.8.0-45-generic (web01.tecmint.com)   05/04/2026  _x86_64_  (4 CPU)
14:41:33     UID       PID     prio     policy  Command
14:41:33       0         3       99       FIFO  migration/0
14:41:33       0         5       99       FIFO  migration/1
14:41:33       0        14       99       FIFO  watchdog/0
14:41:33    1000      4821       20     NORMAL  java

Потоки миграции ядра всегда работают с приоритетом 99 и планированием FIFO, что является ожидаемым поведением. Если вы видите пользовательский процесс с политикой FIFO или RR и высоким приоритетом, он будет прерывать все остальное на этом процессоре, пока добровольно не уступит, и обнаружение его здесь объясняет, почему другие процессы испытывают дефицит ресурсов.

sar: средство отчетности о системной активности для анализа исторической производительности Linux

sar — это инструмент для анализа истории, в то время как mpstat и pidstat представляют собой моментальные снимки; он непрерывно собирает данные о системной активности через cron и позволяет воспроизвести любой временной интервал из прошлого.

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

13. Сбор статистики ЦП и сохранение в двоичный журнал

Флаг -u сообщает об использовании ЦП, -o сохраняет необработанные данные в двоичный файл для последующего воспроизведения, а аргументы 2 5 собирают 5 выборок с интервалом в 2 секунды, что дает вам короткий интервал записи, который можно сохранить и поделиться во время инцидента.

sar -u -o /tmp/sarfile 2 5

Вывод:

Linux 6.8.0-45-generic (web01.tecmint.com)   05/04/2026  _x86_64_  (4 CPU)
14:44:10        CPU     %user     %nice   %system   %iowait    %steal     %idle
14:44:12        all     22.14      0.00      3.44      0.00      0.00     74.42
14:44:14        all     19.88      0.00      2.98      0.52      0.00     76.62
14:44:16        all     24.32      0.00      3.11      0.00      0.00     72.57
14:44:18        all     21.44      0.00      3.22      0.00      0.00     75.34
14:44:20        all     20.88      0.00      3.08      0.00      0.00     76.04
Average:        all     21.73      0.00      3.17      0.10      0.00     75.00

Чтобы воспроизвести сохраненный файл, запустите sar -u -f /tmp/sarfile, а для преобразования его в CSV для построения графиков используйте sadf -d /tmp/sarfile. Двоичный формат не читается человеком напрямую, поэтому всегда считывайте его через sar -f или sadf.

14. Настройте автоматический сбор с помощью Cron

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

Добавьте эти 2 записи в crontab пользователя root с помощью sudo crontab -e:

Collect system activity every 10 minutes
*/10 * * * * /usr/lib/sysstat/sa1 1 1
Generate daily human-readable report at 23:53
53 23 * * * /usr/lib/sysstat/sa2 -A

Убедитесь, что данные собираются:

ls -lh /var/log/sysstat/

Вывод:

total 2.1M
-rw-r--r-- 1 root root 412K May  3 23:53 sa03
-rw-r--r-- 1 root root 388K May  4 14:45 sa04
-rw-r--r-- 1 root root  44K May  4 14:45 sar04

В Ubuntu/Debian путь к sa1 — /usr/lib/sysstat/sa1, а в RHEL/Rocky Linux он может находиться в /usr/lib64/sa/sa1, поэтому перед добавлением записи в cron убедитесь в правильности пути к sa1.

Если cron запускается, но /var/log/sysstat/ остается пустым в Ubuntu, проверьте, что ENABLED="true" установлен в /etc/default/sysstat, так как в Ubuntu сбор данных по умолчанию отключен.

15. Проверка очереди запуска и истории средней нагрузки

Флаг -q сообщает длину очереди выполнения, общее количество процессов, среднюю загрузку и количество заблокированных процессов, что в совокупности показывает, есть ли у системы больше задач, готовых к выполнению, чем она может обработать, и является ли это проблемой перегрузки ЦП или блокировки ввода-вывода.

sar -q 2 5

Вывод:

Linux 6.8.0-45-generic (web01.tecmint.com)   05/04/2026  _x86_64_  (4 CPU)
14:50:11   runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15   blocked
14:50:13         3       512      2.44      1.88      1.42         0
14:50:15         4       514      2.51      1.90      1.43         1
14:50:17         5       516      2.60      1.91      1.43         2
14:50:19         2       514      2.48      1.90      1.43         0
14:50:21         1       512      2.41      1.89      1.43         0
Average:         3       514      2.49      1.90      1.43         1

На системе с 4 процессорами устойчивое значение runq-sz выше 4 означает, что процессы активно ожидают в очереди на время процессора, а не выполняются, что свидетельствует о перегрузке процессора.

Колонка blocked подсчитывает процессы, заблокированные на диске или в сетевом вводе-выводе, и ненулевое значение здесь наряду с высоким значением %iowait из sar -u подтверждает наличие узкого места в хранении данных, а не проблему с процессором.

16. Проверка использования файловой системы во времени

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

sar -F 2 4

Вывод:

Linux 6.8.0-45-generic (web01.tecmint.com)   05/04/2026  _x86_64_  (4 CPU)
14:52:01  MBfsfree  MBfsused   %fsused  %ufsused     Ifree     Iused    %Iused FILESYSTEM
14:52:03     18240      9760     34.84      0.00  12188422    811578      6.24 /dev/sda1
14:52:03      2048       952     31.74      0.00   1048320    176480     14.40 /dev/sdb1

Столбец %ufsused показывает процент пространства, доступного пользователям, и учитывает зарезервированные блоки, которые root оставляет для себя, поэтому когда %fsused достигает 100%, но %ufsused ниже, обычные пользователи больше не могут записывать данные, но root по-прежнему может.

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

17. Мониторинг пропускной способности сетевого интерфейса

Флаг -n DEV сообщает о пакетах и байтах, полученных и переданных в секунду для каждого интерфейса, а передача через grep -v lo исключает интерфейс loopback, чтобы вывод сосредоточился на реальном трафике.

sar -n DEV 1 3 | grep -v lo

Вывод:

Linux 6.8.0-45-generic (web01.tecmint.com)   05/04/2026  _x86_64_  (4 CPU)
14:54:08     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s   %ifutil
14:54:09      eth0    412.00    388.00     42.14     38.22      0.00      0.00      0.00      0.40
14:54:10      eth0    844.22    812.44     88.22     82.14      0.00      0.00      0.00      0.84
14:54:11      eth0    388.12    366.00     40.44     38.88      0.00      0.00      0.00      0.40

Колонка %ifutil, добавленная в sysstat 11.5, показывает процент используемой пропускной способности интерфейса, и значения выше 80% на интерфейсе 1 Гбит/с означают, что вы приближаетесь к пределу пропускной способности канала и должны выяснить, требуется ли регулирование трафика, объединение каналов или более быстрая сетевая карта. Совместите это с sar -n EDEV, чтобы одновременно проверять наличие ошибок и потерь пакетов.

18. Отчет о задержке ввода-вывода блочных устройств

Флаг -d показывает пропускную способность и задержку для каждого блочного устройства, а сочетание await и svctm является самым прямым индикатором того, имеете ли вы медленный диск или перегруженную очередь ввода-вывода.

sar -d 1 3

Вывод:

Linux 6.8.0-45-generic (web01.tecmint.com)   05/04/2026  _x86_64_  (4 CPU)
14:56:14        DEV       tps     rkB/s     wkB/s   areq-sz    aqu-sz     await     svctm     %util
14:56:15     dev8-0     88.00    412.00   1084.00     17.00      0.88     10.02      4.12     36.22
14:56:16     dev8-0    112.44    488.22   1244.00     15.44      1.12     12.44      4.88     44.12
14:56:17     dev8-0     76.22    344.88    922.00     16.88      0.72      8.88      3.88     29.66

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

Колонка aqu-sz подтверждает это, показывая среднюю глубину очереди, и значения, стабильно превышающие 1 на одном вращающемся диске, указывают на перегрузку ввода-вывода.

19. Отчет об использовании памяти и статистике фиксации

Флаг -r отображает полную картину памяти, включая свободную, используемую, кэшированную и зафиксированную память, а столбец %commit показывает, выделило ли ядро больше памяти, чем физически существует.

sar -r 1 3

Вывод:

Linux 6.8.0-45-generic (web01.tecmint.com)   05/04/2026  _x86_64_  (4 CPU)
14:58:22  kbmemfree kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
14:58:23    2142440   5907560     73.40    288012   2844120   6112448     37.82   3188400   2241644      1224
14:58:24    2138800   5911200     73.45    288016   2844888   6114220     37.83   3190144   2241788       988
14:58:25    2136320   5913680     73.48    288020   2845200   6118400     37.86   3191220   2241900       812
Average:    2139187   5910813     73.44    288016   2844736   6114989     37.84   3189921   2241777      1008

Когда значение %commit превышает 100%, ядро выделило запущенным процессам больше виртуальной памяти, чем может физически обеспечить с помощью ОЗУ и подкачки вместе взятых, что означает, что некоторые выделения памяти завершатся с ошибками нехватки памяти, если каждый процесс одновременно попытается использовать весь выделенный ему объем.

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

sadf -d считывает двоичный файл данных sar и выводит CSV, разделённый точкой с запятой, который можно открыть в табличном процессоре или передать в awk для пользовательского анализа; это лучший способ построить графики производительности на основе данных, которые sar собирает автоматически.

sadf -d /var/log/sysstat/sa04 -- -n DEV | grep -v lo

Вывод:

hostname;interval;timestamp;IFACE;rxpck/s;txpck/s;rxkB/s;txkB/s;rxcmp/s;txcmp/s;rxmcst/s;%ifutil
web01;600;2026-05-04 08:00:02 UTC;eth0;288.44;241.22;29.14;24.08;0.00;0.00;0.00;0.28
web01;600;2026-05-04 08:10:02 UTC;eth0;312.88;288.44;31.82;29.04;0.00;0.00;0.00;0.32
web01;600;2026-05-04 09:00:02 UTC;eth0;1841.22;1724.88;188.44;174.12;0.00;0.00;0.00;1.84

Строка 09:00, показывающая 1841 пакет в секунду по сравнению с 288 в 08:00, — это именно тот вид всплеска трафика, который вы полностью пропустили бы, если бы смотрели только вывод sar в реальном времени, и именно поэтому настройку cron в примере 14 стоит выполнить до того, как произойдет инцидент.

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

sadf -d /var/log/sysstat/sa04 -- -n DEV > /tmp/network-$(date +%F).csv

Заключение

Набор инструментов sysstat лучше всего работает как диагностическая цепочка, и типичный поток действий на медленной системе начинается с sar -u для проверки недавней истории ЦП, переходит к mpstat -P ALL для выявления «горячих» ядер, затем переходит к pidstat -p ALL 2 для определения ответственного процесса и заканчивается pidstat -d или sar -d if I/O.

Самое эффективное, что вы можете сделать прямо сейчас, — это настроить задание cron из примера 14 и дать ему собрать данные за полную неделю до того, как что-то пойдет не так, потому что Диагностика инцидента с использованием исторических данных занимает минуты, а с нуля — часы.

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

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