Proxmox: I/O wait 100% — знайдіть галасливу VM/контейнер і зупиніть зависання хоста

October 6, 2025 • February 3, 2026 • Читання: 7 хв • Views: 7

Було корисно?

Ваш вузол Proxmox “увімкнений”, але ніби не живий. Веб‑інтерфейс повільний. SSH довго віддає натиснуту клавішу. Віртуальні машини «завмирають», ніби обмірковують своє життя. top каже, що CPU «простий», але сервер непридатний для роботи, бо wa зафіксоване на 100%.

Це класична ситуація, коли сховище тримає систему в заручниках. Завдання не в тому, щоб пильно дивитися на load average в надії, що воно покаже істину. Завдання — ідентифікувати, яка VM/контейнер б’є по сховищу (або який диск вмирає), підтвердити це доказами та застосувати виправлення, яке зупинить зависання хоста — без гадань і без «перезавантаження як стратегії моніторингу».

Що насправді означає I/O wait 100% (і чого це не означає)

I/O wait — це спосіб, яким CPU каже: «Я готовий виконуватися, але заблокований в очікуванні завершення вводу/виводу.» На вузлі Proxmox це зазвичай означає, що ядро чекає завершення блочного I/O (диски, SSD, NVMe, SAN, Ceph, ZFS vdevs), і все верхнього рівня (процеси QEMU, навантаження LXC, journald, pvestatd, навіть веб‑UI) застрягає за одним і тим же вузьким місцем.

Велике iowait не обов’язково «погане» під час великої послідовної записи на здоровий масив. Проблема — у поєднанні високого iowait і затримок, видимих для користувачів. Це зазвичай викликано одним із цього:

Вибух латентності: попит на IOPS перевищує те, що сховище може віддати, глибина черги зростає, і все починає чекати.
Патологія пристрою: диск починає таймаутити, скидати з’єднання або ремапити сектора; блочний шар чекає, і ваш гіпервізор теж.
Ампліфікація записів: дрібні випадкові записи плюс copy‑on‑write‑шари (ZFS, QCOW2, thin provisioning) і синхронні семантики призводять до болю.
Конкурентні навантаження: задачі резервного копіювання, scrub, resilver та «хтось запустив fio в проді» (таке буває).

Дві важливі уточнення:

100% iowait не означає, що CPU «завантажений». Це означає, що готові для виконання потоки блокуються на I/O. CPU може виглядати спокійним, а вузол — повністю завислим.
Load average може різко зрости, поки використання CPU залишається низьким. Завдання, що очікують у незмінному сні (часто в стані D), все одно враховуються в load.

Груба реальність: якщо латентність сховища зростає з 1–5 ms до 500–5000 ms, ваш вузол стає однопотоковою драмою, незалежно від кількості ядер, за які ви платили.

Швидкий план діагностики (перший/другий/третій)

Це потік дій «припинити кровотечу». Його можна виконати за 5–15 хвилин, навіть якщо вузол пригальмовує.

Перший: підтвердьте, що це латентність сховища, а не CPU чи RAM

Перевірте iowait і чергу виконання (top або vmstat).
Перевірте латентність і завантаження по дисках (iostat -x). Якщо один пристрій близький до ~100% util з великим await — ви знайшли точку тиску.
Пошукайте заблоковані задачі (dmesg з повідомленнями «blocked for more than» або ps за станом D). Це підпис I/O‑wait, що фіксує систему.

Другий: визначте галасливого гостя (VM/CT), який створює навантаження

Знайдіть, який PID QEMU виконує I/O (pidstat -d, iotop).
Зіставте цей PID з VMID (командний рядок QEMU містить -id, або qm list + аргументи процесу).
Перевірте статистику I/O на рівні Proxmox для гостя (pvesh get /nodes/..., qm monitor статистики та метрики сховища).

Третій: оберіть найменш ризиковане обмежувальне діяння

Обмежте I/O (переважно): встановіть ліміти на диск VM (qm set) або використайте cgroup I/O ліміти для LXC.
Поставте гостя на паузу/припиніть (швидко, можна відкотити): qm suspend або qm stop --skiplock, якщо потрібно.
Завбийте конкретну задачу резервного копіювання/scrub/resilver: зупиніть роботу, що спалює масив, а не весь вузол.

Правило великого пальця: якщо вузол зависає, ваша перша мета — відновити контроль, а не бути філософськи «правильним».

Цікаві факти й контекст (що пояснює дивакуватість)

Linux iowait — це категорія обліку CPU, а не метрика сховища. Вона залежить від того, що планувальник вважає, що CPU міг би робити в той час, тому це не прямий показник «завантаження диска».
Стан D (uninterruptible sleep) — давній «чорний лиходій» Unix. Процеси, що чекають I/O, можуть стати практично не вбиваними, поки I/O не завершиться або пристрій не скине з’єднання.
ZFS спроєктовано для цілісності даних в першу чергу. Його модель copy‑on‑write робить «дрібні синхронні записи на фрагментованих пулах» типовою темою в постмортемах про продуктивність.
QCOW2‑снапшоти зручні, але можуть множити латентність. Кожен запис може проходити через дерево метаданих, а довгі ланцюги снапшотів «старіють» як молоко.
Ceph‑повільні операції часто — ранній попереджувальний знак. Коли OSD або мережа незадоволені, латентність росте задовго до повного відмовлення; ігнорувати slow ops — означає погоджуватися на простій.
Бар’єри запису та flush‑і існують, бо втрата даних гірша за повільність. Якщо ваше сховище бреше про надійність (неправильно сконфігурований кеш, відсутній захист при втраті живлення), воно буде швидким до дня, коли це обернеться катастрофою.
Події «відновлення» — це події з продуктивності. RAID resilver, ZFS scrub і Ceph backfill змінюють патерни I/O і можуть позбавити foreground‑завантаження ресурсів, якщо не налаштовані.
Гіпервізори посилюють проблеми зі сховищем. Один вмираючий SSD може застопорити десятки гостей, бо їх I/O йде через одне ядро та одну блочну чергу.
Блочний шар сильно еволюціонував. Multi‑queue (blk‑mq) і сучасні планувальники підвищують пропускну здатність, але не виправлять пристрій, що повертає латентність у 2 секунди.

Практичні завдання: команди, виводи, рішення (12+)

Ось реальні команди, які можна виконати на вузлі Proxmox. Кожне завдання включає на що дивитися і яке рішення приймати далі.

Завдання 1: Швидко підтвердити iowait і заблоковані задачі

cr0x@server:~$ top -b -n1 | head -n 15
top - 11:24:31 up 47 days,  3:12,  2 users,  load average: 54.12, 49.88, 41.03
Tasks: 412 total,   3 running, 409 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.2 us,  0.6 sy,  0.0 ni,  0.1 id, 98.0 wa,  0.0 hi,  0.1 si,  0.0 st
MiB Mem : 128642.5 total,  12211.7 free,  44210.2 used,  72220.6 buff/cache
MiB Swap:  8192.0 total,   8170.5 free,     21.5 used.  84044.3 avail Mem

Що це означає: CPU переважно чекає. Load величезний. Це відповідає латентності сховища або завислим I/O.

Рішення: Перейдіть до латентності по пристроях (iostat -x) і I/O по процесах (pidstat/iotop). Не гнатись за налаштуваннями CPU.

Завдання 2: Подивитися чергу виконання і тренд iowait

cr0x@server:~$ 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
 2 38      0 1249876  89244 72133840 0    0   118  9432  712 1843  1  1  0 98  0
 1 41      0 1249804  89244 72133912 0    0   104 10288  680 1721  1  1  0 98  0
 2 39      0 1249812  89244 72133980 0    0   112  9816  705 1802  1  1  0 98  0
 1 40      0 1249820  89244 72134012 0    0    96 11024  690 1760  1  1  0 98  0

Що це означає: Стовпець b (заблоковані процеси) величезний. Це числове відображення зависання хоста.

Рішення: Перевірте завантаження дисків і await. Якщо один пристрій — горло пляшки, ізолюйте його. Якщо навантаження розподілене — підозрівайте насичення бекенда (Ceph/мережа) або шаблон навантаження (sync‑записи, резервні копії).

Завдання 3: Знайти гарячий пристрій за допомогою розширеного iostat

cr0x@server:~$ iostat -x 1 3
Linux 6.8.12-4-pve (server) 	12/26/2025 	_x86_64_	(32 CPU)

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz  rareq-sz wareq-sz svctm  %util
nvme0n1         12.0  2100.0   512.0 89200.0     0.0   220.0   0.0    9.5    3.2  740.5  1555.2     42.7     42.5  0.45  99.9
nvme1n1         10.0    14.0   480.0   620.0     0.0     1.0   0.0    6.7    2.8    4.1     0.1     48.0     44.3  0.18   0.4

Що це означає: nvme0n1 зафіксований на 99.9% util з ~740 ms write await і величезною чергою. Це не просто «завантажений» — це «страждає».

Рішення: Виявіть навантаження, що генерує ці записи. Перевірте журнали ядра і SMART для проблем з пристроєм. Така латентність може бути перевантаженням, але також і ознакою помираючого диска.

Завдання 4: Підтвердити, чи ядро повідомляє про помилки I/O або скидання

cr0x@server:~$ dmesg -T | tail -n 30
[Thu Dec 26 11:23:12 2025] nvme nvme0: I/O 332 QID 4 timeout, aborting
[Thu Dec 26 11:23:12 2025] nvme nvme0: Abort status: 0x371
[Thu Dec 26 11:23:13 2025] nvme nvme0: resetting controller
[Thu Dec 26 11:23:16 2025] EXT4-fs warning (device dm-3): ext4_end_bio:351: I/O error 10 writing to inode 262148 starting block 11534336)
[Thu Dec 26 11:23:18 2025] task jbd2/dm-3-8:219 blocked for more than 120 seconds.
[Thu Dec 26 11:23:18 2025]       Tainted: P           O       6.8.12-4-pve #1

Що це означає: Таймаути й скидання контролера — не питання налаштування навантаження. Це проблеми апаратного забезпечення або прошивки. Повідомлення про заблоковані задачі пояснює зависання.

Рішення: Якщо бачите таймаути/скидання — ставте пристрій під підозру негайно: зменште I/O, мігруйте гостів, і плануйте заміну. Не витрачайте годину на налаштування планувальників черги на диску, який активно таймаутиться.

Завдання 5: Перевірити SMART/NVMe (швидка триаж)

cr0x@server:~$ smartctl -a /dev/nvme0n1 | egrep -i 'critical_warning|media_errors|num_err_log_entries|percentage_used|power_on|temperature'
Critical Warning:                   0x00
Temperature:                       73 Celsius
Percentage Used:                   89%
Power On Hours:                    31211
Media and Data Integrity Errors:   18
Error Information Log Entries:     294

Що це означає: Великий знос (Percentage Used), помилки носія і зростаючий журнал помилок вказують на пристрій, що наближається до виходу з ладу.

Рішення: Пріоритезуйте евакуацію критичних VM. Плануйте вікно заміни. Якщо це дзеркало ZFS/RAID — почніть контрольовану заміну, а не чекати драматичного відмовлення в пікові години.

Завдання 6: Визначити, які процеси зараз виконують дисковий I/O

cr0x@server:~$ pidstat -d 1 5
Linux 6.8.12-4-pve (server) 	12/26/2025 	_x86_64_	(32 CPU)

11:25:44 AM   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  Command
11:25:45 AM     0      2911      0.00  68420.00  11200.00   98765  qemu-system-x86
11:25:45 AM     0      4187      0.00  10240.00   1800.00   12001  vzdump
11:25:45 AM     0      1332      0.00    220.00     12.00     210  pvestatd

Що це означає: Один процес QEMU — головний записувач; також активний vzdump (резервне копіювання). iodelay величезний — процес багато часу проводить у чеканні завершення I/O.

Рішення: Зіставте PID 2911 з VMID. Якщо запущено резервні копії, вирішіть, чи призупинити/зупинити їх, щоб відновити чуйність хоста.

Завдання 7: Зіставити PID QEMU з VMID

cr0x@server:~$ ps -p 2911 -o pid,cmd --no-headers
2911 /usr/bin/kvm -id 113 -name vm113-db01,debug-threads=on -m 16384 -smp 8,sockets=1,cores=8 -drive file=/dev/zvol/rpool/data/vm-113-disk-0,if=none,id=drive-scsi0,cache=none,aio=io_uring,discard=on,format=raw

Що це означає: Це VM 113. Диск — ZVOL. Режим кешу — none, async I/O — io_uring. Це не має значення, якщо пристрій таймаутить, але важливо, якщо ви просто насичуєте ресурс.

Рішення: Подивіться статистику VM 113 і вирішіть: обмежити, призупинити чи мігрувати. Тим часом підтвердіть, чи VM 113 також бере участь у резервному копіюванні.

Завдання 8: Перевірити показники диска VM на рівні Proxmox

cr0x@server:~$ qm status 113 --verbose
status: running
name: db01
cpus: 8
memory: 16384
uptime: 192773
net0: virtio=DE:AD:BE:EF:11:30,bridge=vmbr0
diskread: 0.00
diskwrite: 68.42
diskread_bytes: 0
diskwrite_bytes: 73408602112

Що це означає: Proxmox показує високий запис. Він не відображає латентність, але підтверджує «хто».

Рішення: Обмежити VM 113. Якщо це база даних або конвеєр логів, вона може генерувати fsync‑важкі записи, які мучать деградований пул.

Завдання 9: Перевірити, чи резервне копіювання — другорядний винуватець

cr0x@server:~$ pgrep -af vzdump
4187 /usr/bin/perl /usr/bin/vzdump --all 1 --mode snapshot --compress zstd --storage backup-nfs --mailnotification failure
4231 /usr/bin/pigz -p 4

Що це означає: Запущено node‑wide vzdump. Режим snapshot все ще може створювати великі читання і метадані‑записи, особливо з QCOW2 або зайнятими ZFS dataset‑ами.

Рішення: Якщо вузол зависає — зупиніть резервне копіювання першим (це дискретне навантаження), перед тим як вбивати production‑гості.

Завдання 10: Акуратно зупинити або призупинити резервне копіювання (контейнмент)

cr0x@server:~$ kill -TERM 4187
cr0x@server:~$ tail -n 5 /var/log/vzdump/vzdump.log
INFO: vzdump job finished
ERROR: job aborted by signal
INFO: cleanup temporary directory '/var/tmp/vzdumptmp4187'

Що це означає: Ви перервали резервне копіювання. Це має швидко знизити тиск I/O, але якщо масив/пристрій нездоровий — проблема може залишитись.

Рішення: Повторно перевірте iostat -x. Якщо await впаде і вузол відновиться — ви купили час для розслідування без скарг у чаті.

Завдання 11: Обмежити галасливу VM (переважне карантинування)

cr0x@server:~$ qm set 113 --scsi0 rpool:vm-113-disk-0,iops=800,mbps=40
update VM 113: -scsi0 rpool:vm-113-disk-0,iops=800,mbps=40

Що це означає: Ви обмежуєте швидкість диска VM, даючи хосту і іншим гостям можливість «подихати». Це не «виправлення продуктивності», це контроль радіуса ураження.

Рішення: Якщо ліміти стабілізують латентність, залиште їх, поки розбираєтесь з робочим навантаженням гостя (наприклад, runaway logging, DB checkpoint storm) і станом сховища.

Завдання 12: Для LXC знайти топ‑записувача I/O і зіставити з CTID

cr0x@server:~$ iotop -oPa -n 5
Total DISK READ:         0.00 B/s | Total DISK WRITE:      92.15 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN  IO>    COMMAND
 8432 be/4 root        0.00 B/s   68.42 M/s  0.00 % 99.99 % [kvm]
 9211 be/4 root        0.00 B/s   18.11 M/s  0.00 % 95.00 % [kworker/u64:3]
10222 be/4 root        0.00 B/s    4.10 M/s  0.00 % 60.00 % [lxcfs]

Що це означає: QEMU — монстр. Але якби тут був процес контейнера, далі ви зіставили б його через cgroups або кореляцію монтувань і PID.

Рішення: Якщо це контейнер — використайте pct status і pct config плюс cgroup I/O статистику для локалізації й обмеження.

Завдання 13: Перевірити стан ZFS пула і поточні обслуговування, що можуть красти I/O

cr0x@server:~$ zpool status -v
  pool: rpool
 state: DEGRADED
status: One or more devices has experienced an unrecoverable error.  An attempt was made to correct the error.
action: Replace the device using 'zpool replace'.
  scan: scrub in progress since Thu Dec 26 09:12:02 2025
        2.31T scanned at 652M/s, 1.98T issued at 559M/s, 6.12T total
        0B repaired, 32.35% done, 2:11:44 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        rpool                       DEGRADED     0     0     0
          mirror-0                  DEGRADED     0     0     0
            nvme0n1                 FAULTED      2    18     0  too many errors
            nvme1n1                 ONLINE       0     0     0

errors: No known data errors

Що це означає: Пул деградований, scrub виконується, один NVMe faulted. Ідеальний рецепт для латентності та зависань хоста.

Рішення: Зупиніть або відкладіть scrub, якщо він шкодить доступності, потім замініть збійний пристрій. Доступність перш за все; перевірка цілісності відновиться, коли система зможе «дихати».

Завдання 14: Подивитися, які ZFS dataset/zvol найгарячіші

cr0x@server:~$ zfs iostat -v rpool 1 3
                  capacity     operations     bandwidth
pool            alloc   free   read  write   read  write
--------------  -----  -----  -----  -----  -----  -----
rpool           5.01T  1.11T    120   2200  4.8M  89.2M
  rpool/ROOT    18.2G  97.8G      2     18   64K  2.1M
  rpool/data    4.99T  1.01T    118   2182  4.7M  87.1M
    vm-113-disk-0  420G  80.0G     12   1620 512K  68.4M
    vm-105-disk-0  210G  30.0G      8    260 384K  11.2M

Що це означає: Ви бачите найгарячіший zvol: vm-113-disk-0. Це підтверджує галасливого гостя на рівні сховища.

Рішення: Зосередьтесь на навантаженні VM 113 і розгляньте переміщення його диска на менш навантажений пул, налаштування записів бази даних або застосування тривалих обмежень I/O.

Завдання 15: Якщо задіяний Ceph — перевірити health і slow ops

cr0x@server:~$ ceph -s
  cluster:
    id:     3f0c2c2d-7f8b-4d17-9e21-2a7d3c3b2a91
    health: HEALTH_WARN
            2 osds down
            154 slow ops, oldest one blocked for 37 sec, osd.12 has slow ops

  services:
    mon: 3 daemons, quorum mon1,mon2,mon3
    mgr: mgr1(active)
    osd: 12 osds: 10 up, 10 in

  data:
    pools:   6 pools, 256 pgs
    objects: 4.12M objects, 15 TiB
    usage:   46 TiB used, 18 TiB / 64 TiB avail
    pgs:     12 pgs degraded, 9 pgs undersized

Що це означає: Ceph попереджає про slow ops і down OSD. Це проявляється як iowait на вузлах‑гіпервізорах, що використовують RBD, бо операції блокуються на кластері.

Рішення: Проблема Ceph важливіша, ніж проблема VM. Стабілізуйте кластер (OSD, мережа, ліміти backfill), перш ніж звинувачувати гостя.

Як реально знайти галасливу VM або контейнер

«Галасливий сусід» — ввічливий термін для «один гість їсть підсистему сховища, а всі інші платять рахунок». У Proxmox є три практичні підходи, щоб його знайти:

Кут процесів: який PID робить I/O? (qemu-system-x86, інструменти бекапу, zfs, ceph-osd).
Кут об’єкта сховища: який том найгарячіший? (ZVOL ім’я, RBD image, LVM LV, qcow2 файл).
Кут гостя Proxmox: який VMID/CTID відображає високий disk throughput?

Кут процесів: QEMU зазвичай — винуватець

На типовому вузлі кожна VM відповідає одному процесу qemu-system-x86. Якщо цей процес записує 60–200 MB/s на пристрій, який не може цього витримати, iowait росте. Якщо пристрій починає таймаутити, хост зависає. Ваша ціль — якнайшвидше прив’язати I/O до VMID.

Коли вузол пригальмовує, уникайте дорогих «широких» команд. Віддавайте перевагу вузьким запитам:

pidstat -d 1 5 дешево і дає ранжований список.
ps -p PID -o cmd швидко дає VMID.
iostat -x скаже, чи це насичення, чи патологія.

Жарт на додачу: якщо ваш хост на 100% iowait, ваш CPU не «байдикує». Він практикує майндфулнес, поки диски панікують.

Кут об’єкта сховища: зіставляємо гарячі томи з гостями

Залежно від бекенда сховища «гарячий об’єкт» виглядає по‑різному:

ZFS zvol: rpool/data/vm-113-disk-0 (дуже очевидно).
QCOW2 в директорії: файл як /var/lib/vz/images/113/vm-113-disk-0.qcow2.
LVM-thin: LV як /dev/pve/vm-113-disk-0.
Ceph RBD: image як vm-113-disk-0 у пулі.

Трюк — працювати назад: знайти гарячий пристрій → гарячий логічний том → VMID → навантаження всередині гостя.

Кут гостя Proxmox: швидка статистика по гостю

Proxmox може показати throughput по гостях, що корисно, але недостатньо. Throughput не є головним ворогом; латентність — це. Проте throughput по гостю — чудовий список «кого інтерогувати».

cr0x@server:~$ qm list
 VMID NAME         STATUS     MEM(MB)    BOOTDISK(GB) PID
 105  app01        running     8192              120  2144
 113  db01         running     16384             500  2911
 127  ci-runner01  running     4096               80  3382

Що це означає: У вас є VMID і PID; тепер можна зіставити це з виводом pidstat/iotop.

Рішення: Виберіть гостя з найгарячішим QEMU PID, потім підтвердіть на рівні сховища, який том він чіпає. Не «вбивайте випадково найбільшу VM», якщо вам не подобається зайвий простій.

Режими відмов сховищ: ZFS, Ceph, LVM-thin, NFS/iSCSI

ZFS на Proxmox: типові підозрювані

ZFS чесно говорить про дані. Він менш поблажливий до навантажень, що інтенсивно роблять sync‑записи і рандомні записи на споживчих SSD. На Proxmox інциденти продуктивності ZFS зазвичай потрапляють у ці категорії:

Деградований vdev або несправний пристрій: спайки латентності і таймаути, особливо під навантаженням запису.
Конфлікт scrub/resilver: фонові роботи конкурують з гостями за I/O і можуть позбавити продуктивність чутливих навантажень.
Тиск на синхронні записи: бази даних і деякі ФС часто викликають часті flush; без SLOG або з нерозумними очікуваннями записи серіалізуються.
Фрагментація та дрібні блоки: старі пули з великою кількістю churn погіршують рандомний I/O, особливо на HDD.

Операційно ZFS корисний, бо дає вам zpool status і zfs iostat, які дійсно допомагають під час інциденту. Використовуйте їх.

Ceph: коли мережа — частина вашого диска

У Ceph високий iowait на гіпервізорі може не мати нічого спільного з локальними дисками. Це може бути:

OSD down або флап, що викликає деградовані PG та slow ops.
Backfill/recovery шторми, що насичують мережу або диски.
Нерівномірне використання OSD (hotspotting) через CRUSH або кілька великих image.
Проблеми мережі (дропи, невідповідний MTU, вичерпання буферів), що перетворюють «сховище» на місто повторних передач.

Якщо Ceph каже «slow ops», слухайте. iowait — лише посланець. Не стріляйте в нього; лагодьте кластер.

LVM-thin: біль метаданих реальний

LVM‑thin може бути швидким і простим. Але він також може зіпсувати вам день, коли метадані thin‑pool стають щільними або пул заповнюється. Коли thin provisioning близький до повного, ви бачите раптові затримки, паузи на алокацію і стрибки латентності гостя.

Практичне правило: тримайте thin‑pool помірно заповненим, нижче 80–85%, якщо у вас немає надійного моніторингу й протестованої процедури розширення.

NFS/iSCSI: «диск працює на чужому хості»

Збої мережевого сховища зручні тим, що дозволяють сперечатися з іншою командою, поки ваш вузол зависає.

Слідкуйте за:

Насиченням одного монтажного вузла: один NFS‑сервер стає горлом пляшки.
Мережевою конгестією: мікро‑вибухи можуть драматично підняти латентність.
Таймаутами HBA/драйвера на iSCSI/Fibre Channel, що з’являються в журналах ядра і як заблоковані задачі.

Три корпоративні міні‑історії з фронту

Міні‑історія 1: Інцидент, спричинений хибним припущенням

Вони мали скромний кластер Proxmox із мішаниною веб‑додатків і однієї «важливої» бази даних VM. Сховище було локальними ZFS дзеркалами на NVMe. Все працювало стабільно місяцями, тож припущення перетворилося на догму: «NVMe означає, що сховище не може бути горлом.»

Одного понеділка вузол почав зависати. Команда гналася за CPU, потім за RAM, потім за мережею. Перезапустили кілька сервісів. Навіть звинуватили версію ядра. Тим часом iowait тримався на 90–100% і VM сіпалися. Ніхто рано не подивився dmesg, бо «залізо нове».

Коли хтось нарешті запустив dmesg -T, це був стінопис NVMe‑таймаутів і скидань контролера. Диск не був «повільним». Він фактично зникав і з’являвся під навантаженням, створюючи довгі I/O‑паузи, що клинили задачі в стані D. База даних VM не була кореневою причиною; вона лише спровокувала відмову.

Виправлення було нудним: евакуювати критичні VM, замінити NVMe і оновити прошивку на решті дисків. Постмортем був цікавіший: моніторинг дивився лише на throughput і місце, а не на латентність і кількість помилок. Вони прийняли «швидкий інтерфейс» за «надійний пристрій».

Міні‑історія 2: Оптимізація, що обернулася проти них

Інша організація захотіла швидших резервних копій. Вони змінили графік vzdump, щоб запускати частіше, і підняли ступінь стиснення до «максимум», бо сховище дороге. Також увімкнули більше снапшотів на QCOW2, бо це полегшувало відкат для розробників.

Спочатку все здавалося виграшем: об’єми резервних копій впали, відновлення «було ок». Потім, через кілька тижнів, з’явилися скарги на продуктивність у робочі години. Не постійно, але достатньо, щоб дратувати. Графіки показували періодичні спайки латентності, і кожен спайк збігався з бекапом.

Що сталося: поєднання snapshot‑насиченості QCOW2 і агресивного стиснення створило ідеальний шторм рандомних читань і метаданих‑чарів. Робота бекапу була не лише читанням; вона змушувала сховище долати складну структуру метаданих снапшотів, поки інші VM робили записи. Під навантаженням хост проводив більше часу в очікуванні I/O, ніж у роботі.

Виправлення: відступити від «оптимізації»: зменшити ланцюги снапшотів, перевести ключові VM на raw там, де це доречно, обмежити одночасність бекапів і планувати важкі бекапи поза робочими годинами. Стиснення залишилося, але не ціною продуктивності продукту. Вони вчилися жорстко: «оптимізувати під розмір бекапу» може бути не відрізнити від «оптимізувати під відмови».

Міні‑історія 3: Боротьба без героїзму, що врятувала день

Команда, що керувала внутрішнім кластером Proxmox, мала просте правило: будь‑які зміни бекенду сховища вимагали базової замірної бази й плану відкату. Не довгого документу. Односторінковий опис з «до» числами, «після» числами і «як відкотити».

Одного дня iowait на вузлі піднявся. On‑call не сперечався. Вони виконали ті самі базові команди, що завжди: iostat -x, zpool status, zfs iostat і швидку перевірку бекапів. За п’ять хвилин побачили: scrub, який виконується; один vdev з підвищеною латентністю; і один zvol, що домінує у записах.

Вони обмежили VM, призупинили scrub і мігрували два чутливі до латентності гості з вузла. Хост одразу відновився. Потім у спланованому вікні замінили підозрілий SSD.

Ніяких героїчних вчинків. Ніяких гадань. Нудна частина — звичка тримати базу і короткий інцидент‑чекліст — запобігла спіралі «давайте перезапустимо його» і обмежила вплив на користувачів.

Поширені помилки: симптом → причина → виправлення

Симптом: iowait 100%, вузол «завис», load average величезний.
Причина: Заблоковані задачі через таймаути/скидання диска (апарат/прошивка).
Виправлення: Перевірте dmesg, запустіть smartctl, евакуюйте гостей, замініть/оновіть прошивку пристрою. Зупиніть scrub/resilver під час інциденту.
Симптом: Вузол стає не відповідним лише під час бекапів.
Причина: Надмірна паралельність vzdump, snapshot‑насичені QCOW2, повільне сховище бекапу або вузьке місце NFS.
Виправлення: Зменшіть паралельність бекапів, рознесіть задачі, обмежте I/O, розгляньте raw‑диски для «гарячих» VM, переконайтеся, що ціль бекапу має достатні IOPS і мережеву пропускну здатність.
Симптом: Одна VM повільна, інші теж деградують.
Причина: Галасливий сусід насичує спільну чергу сховища (один vdev, один SSD або metadata thin‑pool).
Виправлення: Обмежте VM, перемістіть її на швидше/ізольоване сховище, виправте навантаження гостя (шторм логів, DB checkpoints).
Симптом: VMs на Ceph мають випадкові паузи в секундах.
Причина: Ceph slow ops через down OSD, backfill/recovery або мережеві проблеми.
Виправлення: Вирішіть питання Ceph: відновіть OSD, налаштуйте recovery/backfill, перевірте MTU і дропи мережі, тимчасово зменшіть клієнтський I/O.
Симптом: Спайки латентності під час ZFS scrub/resilver.
Причина: Фонова робота конкурує з I/O гостів; деградований mirror/RAID посилює це.
Виправлення: Плануйте scrub поза робочими годинами, розгляньте налаштування пріоритету scrub і не запускайте scrub на деградованому пулі без крайньої потреби.
Симптом: Достатньо вільного місця, але I/O жахливий; дрібні записи особливо погані.
Причина: Синхронні записи (fsync) без відповідного дизайну; споживчі SSD можуть «задихнутися» під постійним sync‑навантаженням; тиск транзакцій ZFS.
Виправлення: Перевірте налаштування додатків гостя (журналювання, налаштування стійкості БД), забезпечте відповідне апаратне забезпечення для sync‑навантажень і уникайте «просто вимкнути sync=disabled», якщо ви не готові навмисно ризикувати втратою даних.

Чек‑лісти / покроковий план

Чек‑ліст ізоляції інциденту (10–30 хвилин)

Запустіть top і vmstat, щоб підтвердити високий iowait і заблоковані задачі.
Запустіть iostat -x 1 3, щоб визначити найгарячіший пристрій і подивитися await/util.
Перевірте dmesg -T | tail на таймаути, скидання, помилки I/O.
Визначте топ‑I/O процеси за допомогою pidstat -d або iotop.
Зіставте важкий QEMU PID з VMID через ps і/або qm list.
Спочатку зупиніть дискреційне навантаження: резервні копії (vzdump), scrub/resilver, пакетні задачі.
Обмежте галасливу VM/CT (I/O limits), замість її вимкнення, якщо можливо.
Якщо є помилки апаратури: мігруйте критичні гості з вузла, позначте пристрій для заміни.
Перевірте iostat -x: await має швидко впасти, якщо тиск знято.
Запишіть, що ви зробили і чому. Майбутній ви — зацікавлена сторона.

Чек‑ліст встановлення кореневої причини (той самий день)

Це була відмова пристрою, насичення бекенда чи сплеск навантаження?
Який гість або процес зробив найбільший внесок?
Що змінилося недавно (бекапи, снапшоти, ядро/прошивка, нове навантаження)?
Чи є у вас метрики латентності (не лише throughput) по пристрою та бекенду?
Чи відповідає розклад сховища потребам (один vdev для багатьох VM, thin pool майже повний, Ceph деградований)?
Чи потрібні за замовчуванням пер‑VM ліміти I/O для спільного сховища?

Чек‑ліст запобігання (на цьому тижні)

Встановіть розумні I/O ліміти для «недовірених» навантажень (CI‑ранери, збирачі логів, все, чим керують розробники).
Плануйте резервні копії і scrubs поза піковими годинами; обмежте одночасність.
Моніторьте латентність і помилки: await по диску, SMART‑помилки, Ceph slow ops, ZFS degraded стани.
Тримайте під контролем спалах снапшотів; очищуйте QCOW2 снапшоти і уникайте довгих ланцюгів.
Плануйте запас потужності сховища (IOPS і місткість). Працювати «на межі» — це не економія, а вибір на користь ненадійності.

FAQ

1) Чому Proxmox «зависає», коли сховище повільне?: Тому що хост і гості ділять одне ядро і I/O‑шляхи. Коли блочний I/O стопориться, критичні сервіси (включно з QEMU і системними демонами) блокуються в стані D, і вузол стає нечутливим.
2) Чи завжди 100% iowait — проблема диска?: Ні. Це проблема «завершення I/O відбувається пізно». Це може бути локальний диск, RAID‑контролер, Ceph‑кластер, NFS‑сервер, iSCSI‑шлях або навіть серйозний тиск пам’яті з активним swap. Але майже завжди це латентність шляху сховища.
3) Який найшвидший спосіб знайти галасливу VM?: Використайте pidstat -d або iotop, щоб знайти топ‑I/O QEMU PID, потім зіставте його з VMID через командний рядок процесу (-id) або qm list.
4) Чи варто просто перезавантажити вузол Proxmox?: Тільки якщо ви готові до даунтайму гостей і не можете відновити контроль іншими способами. Перезавантаження ховає докази і не виправляє несправні пристрої або насичені бекенди. Якщо в dmesg є таймаути — перезавантаження може дати хвилини, але не вирішення.
5) Чи можна вирішити це зміною I/O‑планувальника?: Іноді це допомагає на краях. Але це не виправить таймаути, несправне обладнання або бекенд, що не витримує потрібних IOPS/латентності. Спочатку діагностуйте. Налаштовуйте пізніше.
6) Чи безпечно ставити ZFS sync=disabled, щоб зменшити iowait?: Це «безпечно» лише якщо ви готові ризикувати втратою останніх записів при відключенні живлення або падінні. Для багатьох баз даних і файлових систем це неприйнятний ризик. Якщо ви це робите — зафіксуйте це як усвідомлений компроміс щодо стійкості даних.
7) Чому резервні копії створюють стільки болю?: Резервні копії обманливо важкі: вони багато читають, зачіпають метадані і можуть погано взаємодіяти зі снапшотами та copy‑on‑write шарами. Якщо ціль бекапу повільна, об’єкт джерела теж може застрягнути.
8) Як запобігти тому, щоб одна VM зупинила вузол?: Використовуйте I/O‑тротлінг на диск для кожної VM, винесіть високонавантажені робочі навантаження на окреме сховище і контролюйте графік бекапів/scrub. Також моніторьте латентність і помилки, щоби виявити деградацію до того, як вона перетвориться на зависання.
9) Що робити, якщо кілька пристроїв показують високий await?: Тоді вузьке місце може бути вище блочного рівня: спільний контролер, thin pool, Ceph/мережа або загальна система writeback. Підтвердіть за допомогою бекенд‑специфічних інструментів (ZFS/Ceph) і перевірте, чи є один домінуючий процес.
10) Як визначити, насичення це чи вмираючий диск?: Насичення зазвичай показує високий util і високий await без таймаутів/скидань у dmesg. Вмираючий диск часто супроводжується таймаутами, скиданнями, помилками I/O і SMART‑помилками, що зростають.

Висновок: наступні кроки, що реально зменшують інциденти

Ви не «виправляєте iowait». Ви виправляєте шлях сховища і поведінку навантаження, яка створила неприйнятну латентність. Почніть зі швидкого плану: доведіть, що це латентність I/O, знайдіть галасливого гостя, обмежте радіус ураження, а потім вирішіть — це насичення чи відмова.

Практичні кроки далі:

Додайте пер‑VM I/O ліміти для підозрілих навантажень (CI, зборщики логів, все batch‑подібне).
Зробіть латентність видимою: iostat await/util, стан ZFS пула, Ceph slow ops, рахунки SMART помилок.
Не вважайте резервні копії «безкоштовними». Обмежте їх одночасність і плануйте як технічне обслуговування — бо воно фізично є обслуговуванням.
Заміна пристроїв раніше, ніж вони повністю відкажуть. Чекати повної відмови — не хоробрість, а зайвий клопіт.

Останній жарт: єдине гірше за галасливу сусідню VM — тиха — бо вона може вже бути в стані D і мовчки тримати ваш хост у заручниках.

Цитата (перефразована ідея): Gene Kranz: «Be tough and competent.» В термінах опс: спочатку заміряйте, потім дійте рішуче.

Схожі статті

Сплески затримки диска в Debian/Ubuntu: доведіть, що справа в сховищі, а не в додатку (інструменти + виправлення) Docker IOPS Starvation: чому один контейнер БД уповільнює все Proxmox pveperf показує нісенітницю: як правильно тестувати продуктивність