Linux під навантаженням: як за 60 секунд зрозуміти, що гальмує сервер

«Сервер гальмує» — найнеконкретніша скарга з можливих. Перш ніж перезапускати сервіси, варто за хвилину зібрати факти: що саме перевантажено — процесор, пам'ять, диск чи мережа. Ось послідовність, з якої я починаю на будь-якому Linux-сервері.

1. uptime — загальна картина

uptime
# 10:42:17 up 41 days,  3:12,  2 users,  load average: 12.31, 8.04, 3.15

Load average — середня кількість процесів, які виконуються або чекають на CPU чи диск, за 1, 5 і 15 хвилин. Порівнюйте з кількістю ядер (nproc): load 12 на 16 ядрах — нормально, на 4 ядрах — черга.

Три числа показують тренд: 12 / 8 / 3 — навантаження наростає прямо зараз.

Примітка

У Linux load average враховує і процеси в стані D (непереривне очікування, зазвичай диск або NFS). Високий load при низькому CPU — типова ознака проблем з I/O.

2. dmesg — чи не вбивало ядро процеси

dmesg -T | tail -20
# [Mon Oct 13 10:39:51 2026] Out of memory: Killed process 23110 (java) ...

OOM killer, помилки диска, проблеми мережевої карти — ядро пише про це сюди.

3. vmstat — CPU, пам'ять і черги щосекунди

vmstat 1 5
# procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
#  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
# 14  0      0 412308  91240 5212044   0    0     2    45 4210 9120 88 10  2  0  0
#  3  9      0 398112  91240 5208120   0    0  8120  2210 2210 4410 12  5 30 53  0

Перший рядок вище — CPU-bound навантаження (us 88, черга 14). Другий — диск (wa 53, b 9).

4. Хто саме їсть CPU

top -o %CPU          # або htop
pidstat 1 5          # CPU по процесах щосекунди (пакет sysstat)
mpstat -P ALL 1 3    # по ядрах: одне ядро на 100% — однопотокове вузьке місце

5. Пам'ять: free бреше, якщо читати неправильно

free -h
#                total   used   free   shared  buff/cache  available
# Mem:            31Gi   12Gi   1.1Gi   210Mi       18Gi        18Gi

Дивіться на available, а не на free. Linux використовує вільну пам'ять під кеш файлів (buff/cache) і віддає її застосункам за потреби. 1 ГБ «free» при 18 ГБ «available» — абсолютно здоровий стан.

Проблема — коли available мала і росте swap (si/so у vmstat).

6. Диск

iostat -xz 1 3
# Device   r/s    w/s   rkB/s   wkB/s  r_await w_await aqu-sz  %util
# nvme0n1  820.0  95.0  52480   3040    18.40    2.10   15.6   99.2

• r_await/w_await — середній час операції в мс. Для NVMe нормально < 1–2 мс, для HDD — < 10–20 мс.
• aqu-sz — довжина черги до пристрою.
• %util близько 100% на HDD означає насичення (для NVMe цей показник менш показовий — вони обробляють багато запитів паралельно).

Хто саме читає/пише:

iotop -oPa          # процеси з активним I/O
df -h && df -i      # місце і inode: диск може бути «повним» через inode

7. Мережа

ss -s                          # загальна статистика сокетів
ss -tan state time-wait | wc -l
ss -ltnp                       # хто слухає які порти
sar -n DEV 1 3                 # трафік по інтерфейсах
sar -n TCP,ETCP 1 3            # ретрансміти TCP — ознака проблем у мережі

Порада

Встановіть пакет sysstat заздалегідь і ввімкніть збір історії. Тоді sar покаже, що відбувалось о 3:15 ночі, коли все впало, — а не лише поточний момент.

Підсумкова схема

load високий?
├─ так, vmstat: us/sy високі, r > ядер     → CPU: top/pidstat, хто їсть
├─ так, vmstat: wa високий, b > 0          → диск: iostat, iotop
├─ si/so ненульові, available мала         → пам'ять: хто росте, OOM у dmesg
└─ load нормальний, а сервіс повільний     → мережа, залежності (БД, API), блокування в застосунку