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.
Продолжение следует… ⬇️