Dive in performance tools. Часть 2️⃣. [top / htop]

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

2️⃣.1️⃣ Про память в Linux

Когда вы смотрите на показатели памяти (например, в top, free или через `cat /proc/meminfo`), важно понимать, что именно подразумевается под «used», «free», «buff/cache» и т. д. На первый взгляд может казаться, что система «съедает» всю память, но зачастую это лишь особенности кэширования и работы ядра.

1. Total — Общий объём оперативной памяти (RAM), который распознаёт ядро Linux.

2. Used — Количество памяти, занимаемой процессами вместе буферами и кэшами.

3. Free — Память, которая прямо сейчас не задействована ни под процессы, ни под кэш.

4. Buff/Cache
- Buffers — память, зарезервированная под буферизацию операций ввода-вывода (I/O). Пример: при копировании большого файла cp bigfile /backup/bigfile часть данных попадает в буферы, прежде чем окончательно записаться на диск. Это помогает оптимизировать операции записи. По окончании записи ядро освобождает или переиспользует буферы.
- Cache — память, используемая для кэширования файловых данных. Пример: когда вы повторно открываете один и тот же лог-файл, чтение во второй раз будет быстрее, так как ядро может брать данные из кэша (без повторных обращений к диску). Если приложению понадобится память, ядро автоматически «отдаст» часть кэша, так что buff/cache не означает «пропавшую» память.

5. Available — Показывает объём памяти, который ядро может отдать под новые процессы без использования swap. При необходимости кэш и буфер освобождаются автоматически.

6. Swap — Когда системе не хватает физической памяти (или при определённой настройке swappiness), неиспользуемые страницы памяти могут выгружаться в swap-раздел (или файл). Если swap активно используется, это может указывать на нехватку RAM, но иногда ядро использует swap и при наличии свободной памяти, если считает, что выгрузка «простаивающих» страниц — более эффективный вариант.

Продолжение следует… ⬇️

Dive in performance tools. Часть 2️⃣ [top / htop]

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 МБ), значит нехватки ОЗУ нет.

Продолжение следует…⬇️

Dive in performance tools. Часть 2️⃣ [top / htop]

2️⃣.3️⃣ Таблица процессов в top

Ниже разберём, что означают поля PR, NI, VIRT, RES, SHR в выводе top (или похожих утилит):

1. PR (Priority) – приоритет, с которым планировщик ядра запускает процесс. В Linux приоритет обычно отображается целым числом, где более высокое число означает более низкий приоритет (несмотря на кажущуюся «логичность» наоборот). Значения PR могут меняться динамически ядром, исходя из нагрузки и «nice»-приоритета процесса.

2. NI (Nice) – «nice»-значение процесса, задающее его базовый приоритет. Диапазон nice: от -20 (самый высокий приоритет) до +19 (низкий приоритет). По умолчанию процессы запускаются с nice = 0. Если запустить процесс с nice -n 10 COMMAND, то процесс получит NI = 10, то есть будет иметь более низкий приоритет при распределении CPU.

3. VIRT (Virtual Memory) – объём виртуального адресного пространства, зарезервированного или видимого для процесса. Большой VIRT не обязательно означает, что процесс реально занимает столько физической памяти; часть из этого может никогда не загружаться в оперативную память (RAM).

4. RES (Resident Memory) – резидентная (фактически используемая) память в физической оперативной памяти (RAM). Это объём памяти, действительно загруженный в ОЗУ для данного процесса. Если часть процесса или библиотеки выгружена в swap (или ещё не загружена), она не считается в RES.

5. SHR (Shared Memory) – объём разделяемой памяти, используемой процессом. Обычно это доля памяти, которую процесс использует вместе с другими (например, разделяемые библиотеки, общие сегменты). Если два процесса используют одну и ту же библиотеку, её часть может отображаться в SHR у обоих, но в действительности она хранится в памяти единоразово.

Таким образом:

- PR и NI определяют, с каким приоритетом планировщик будет выделять CPU для процесса.
- VIRT говорит, сколько адресного пространства потенциально доступно процессу.
- RES показывает, сколько физической памяти реально выделено ему в данный момент.
- SHR указывает, какую часть этой резидентной памяти (RES) процесс делит с другими.

Теперь разберем практический пример. Здесь мы видим группу процессов Redis под пользователем с UID 999, а также системные процессы (root). Пример строк с Redis:

PID      USER  PR NI    VIRT    RES   SHR  %CPU %MEM    TIME+      COMMAND
110005   999   20  0 8182684 3.2g  1524  36.5 10.8   0:14.70   redis-server
110045   999   20  0 8182684 1.1g  1532  28.2  3.6   1:10.86   redis-server
109437   999   20  0 8182292 3.2g  1744   9.6 12.9 111:19.74   redis-server
... и т.д.

- VIRT ~8.1 ГБ Это виртуальное адресное пространство (не значит, что все 8 ГБ реально заняты). В данном случае для Redis нормально поднимать большие VIRT, особенно если включены RDB/AOF-снапшоты.

- RES (фактическая резидентная память): мы видим 3.2G, 1.1G, 3.8G и т. д. У нескольких процессов Redis довольно большие значения. Суммарно они занимают значительную часть из 30 ГБ ОЗУ.

- %CPU по Redis варьируется от 9.3% до ~36%. Если сложить все Redis-процессы, получится внушительный процент — но поскольку система многопроцессорная, это ещё не обязательно «упор» в один CPU.

Продолжение следует… ⬇️

Dive in performance tools. Часть 2️⃣ [top / htop]

2️⃣.4️⃣ Основные выводы в практическом примере

1. Высокий iowait (26.3% wa). Процессор «ждёт» операций ввода-вывода, что может указывать на интенсивные записи/чтения (например, Redis, сбрасывающий данные на диск). Для дальнейшей диагностики можно использовать утилиты вроде iotop, iostat, dstat, чтобы выявить «виновника» I/O. О них мы поговорим в следующих сериях.

2. Память (buff/cache). ~8.9 ГБ в кэше и буферах — это нормально: ядро старается использовать RAM по максимуму, чтобы ускорять операции. При необходимости эта память освобождается, так что free может быть небольшим, но available (9.4 ГБ) ещё даёт большой запас.

3. Нагрузка на CPU (us, sy, si). Суммарный пользовательский и системный процент невысок (около 13%), однако iowait делает общую картину менее радужной. Нужно следить за si (softirq), если оно продолжит расти, возможно, идёт большой сетевой трафик или нуждаются в настройке сетевые стеки.

4. Load average ~6. На сервере с 8 ядрами это не критично, но при дальнейших пиках нагрузка может дойти до очередей на выполнение задач. Необходимо мониторить в динамике - нет ли дальнейшего роста или все подконтролем.


2️⃣.5️⃣. Что еще можно посмотреть в top

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

- SWAP: объём свопа, используемый процессом.
- ENV: перменные окружения которые видит процесс.
- CODE, DATA: размер сегментов кода и данных в памяти.
- MajF, MinF: количество «major» и «minor» ошибок страницы (page faults).
- VolCxt, NonVolCxt: количество переключений контекста (voluntary/involuntary).
- P, CPU: на каком процессоре (или ядре) выполняется процесс.
- Threads: общее число потоков, запущенных процессом.
- И т. д.

Чтобы выбрать и упорядочить столбцы в интерактивном режиме можно нажать F и выбрать интересующую метрику.

И на этом у меня все, всем спасибо и хорошего дня 🦾️️️️️️ Дальше мы будем разбираться с другими тулами

Почитать на habr: https://habr.com/ru/articles/876428/

Бонус: для обучения сделал https://top.tools.devopsbrain.ru