2️⃣.2️⃣ Про CPU
В строке CPU(s) в top видим восемь основных показателей — проценты от общего времени CPU:
1. us (user) – Время, затраченное на выполнение пользовательских процессов (приложений). Если значение us высокое, значит процессы в userspace активно нагружают процессор. Пример: сложные вычисления в Python, компрессия данных, рендеринг видео.
2. sy (system) – Время, занятое системными вызовами и кодом ядра (kernel space). Если sy растёт, это признак того, что ядро выполняет много работы (обработка I/O, сетевых стэков, драйверов и т. д.). Иногда это бывает из-за большого числа контекстных переключений, или интенсивного чтения-записи на диск.
3. ni (nice) – Время, отведённое процессам с изменённым приоритетом (nice). Если процессы запускаются с nice (пониженным приоритетом) или renice, их CPU-время может отражаться в ni. Редко встречается в большом объёме, если специально не конфигурируете приоритеты.
4. id (idle) – Процент времени, когда CPU простаивает. Если id высок, значит процессор почти без нагрузки. Важно понимать, что часть «простоя» может относиться к iowait, который выделяют отдельно.
5. wa (iowait) – Время, когда CPU простаивает в ожидании операций ввода-вывода (диск, сеть, и т. д.). Если wa велик (например, >10–15%), обычно это говорит, что система не успевает обрабатывать I/O, и процессор «ждёт» данные, вместо вычислять. При высоком iowait стоит проверить диски (
iotop, iostat), подсистему хранения (SSD vs HDD) и сетевые операции (если хранилище находится в сети). Как это диагностировать мы поговорим в следующих статьях данного цикла.6. hi (hardware interrupt) – Время обработки аппаратных прерываний. Например, при поступлении сигнала от сетевой карты или дискового контроллера. Если hi внезапно скачет, есть риск «шторма» прерываний из-за нештатной работы железа.
7. si (software interrupt) – Время обработки программных прерываний (softirqs). Часто связано с сетевыми пакетами, таймерами, межпроцессным взаимодействием. Высокие значения бывают при интенсивном сетевом трафике.
8. st (steal) – «Украденное» время при работе на виртуальной машине. Гипервизор может забирать часть CPU для других виртуалок. Если st высок, значит ваша VM не получает достаточно CPU-ресурсов от хост-сервера.
Важно: Если у вас многоядерный процессор (к примеру, 8 ядер), то проценты показывают агрегированное время по всем ядрам. Можно нажать 1 в top, чтобы увидеть загрузку по каждому ядру отдельно.
Давайте разберем практический пример:
19:48:03 up 403 days, 5:30, 1 user, load average: 6.17, 5.91, 5.64
Tasks: 164 total, 3 running, 161 sleeping, 0 stopped, 0 zombie
%Cpu(s): 7.6 us, 5.7 sy, 0.0 ni, 55.1 id, 26.3 wa, 0.0 hi, 5.2 si, 0.0 st
MiB Mem : 30614.7 total, 846.8 free, 20870.0 used, 8898.0 buff/cache
MiB Swap: 5120.0 total, 5068.7 free, 51.3 used. 9435.4 avail Mem
1. Uptime: up 403 days, 5:30. Сервер не перезагружался более года.
2. Load average: 6.17, 5.91, 5.64. Загрузка за последние 1, 5 и 15 минут. Если на машине, к примеру, 8 ядер, эти значения — не критический показатель. Полезно помнить, что Load Average включает как процессы, использующие CPU, так и те, что ждут ввода-вывода (IO wait).
3. %Cpu(s). us = 7.6% — пользовательские процессы не особо перегружены. sy = 5.7% — умеренная нагрузка на ядро. id = 55.1% — более половины времени CPU простаивает. wa = 26.3% — довольно высокое ожидание I/O. Это может указывать на интенсивную запись/чтение (например, Redis сбрасывает свои данные). si = 5.2% — есть некоторая нагрузка софт-прерываний (сетевой трафик?). st = 0.0% — на данном экземпляре нет «украденного» времени (возможно, это физический сервер).
4. Память. Total: ~30.6 ГБ. Free: ~0.85 ГБ, однако buff/cache = ~8.9 ГБ и avail Mem = ~9.4 ГБ. То есть Linux эффективно использует оставшиеся ~8–9 ГБ под кэш, и при необходимости может её освободить. Swap: практически не используется (51.3 МБ), значит нехватки ОЗУ нет.
Продолжение следует…⬇️