Proxmox став повільнішим після оновлення: перші перевірки, які зазвичай виявляють причину

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

Якщо у вас є година, щоб зупинити кровотечу, зробіть це. Не занурюйтесь у двадцять зайвих глибоких тем. Оберіть верхній рівень вузького місця спочатку, потім заглиблюйтеся.

Перший: ідентифікуйте, який ресурс зараз насичується

• CPU хоста: перевірте load у порівнянні з використанням CPU і часом %steal. Високий load при невисокому використанні CPU кричить «I/O wait» або contention через блокування.
• I/O хоста: перевірте затримку диска та глибину черги. Невелика затримка — нормально; постійні десятки мілісекунд при випадковому I/O — це злочин щодо продуктивності.
• Мережа: перевірте дропи, помилки та невідповідність MTU/offloads. Тиха втрата пакетів — це «в тестовому середовищі працює» для продакшену.

Другий: вирішіть, чи проблема на всьому хості, чи специфічна для VM

• Якщо всі VMs уповільнились однаково після оновлення, підозрюйте ядро хоста, бекенд зберігання, драйвер NIC/offload або сервіси кластера.
• Якщо лише підмножина уповільнилась, підозрюйте конкретні апаратні налаштування VM (virtio/scsi контролер, режим кешу), драйвери гостя або обмеження на рівні VM.

Третій: порівняйте «до vs після» з найпростішою базовою лінією

• Запустіть мікротест I/O на хості (обережно), щоб перевірити, чи регресія в підсистемі зберігання.
• Запустіть перевірку CPU й I/O всередині однієї VM, щоб підтвердити, що межа гіпервізора — не винуватець.
• Перевірте, чи оновлення змінило kernel, версії ZFS/Ceph, IO scheduler або значення за замовчуванням QEMU.

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

Що змінюють оновлення (і чому це важливо)

Оновлення Proxmox вводять в оману як «одне натискання». Під цим натиском: нове ядро, новий QEMU, оновлені стекі зберігання (ZFS, клієнти/демони Ceph, якщо ви їх використовуєте), нові NIC драйвери, нові значення за замовчуванням і інколи нова поведінка щодо cgroups, планування та управління живленням.

Регресії продуктивності після оновлень зазвичай потрапляють у ці категорії:

• Зміни ядра/драйверів: інший за замовчуванням IO scheduler, поведінка NIC offload, обробка IRQ, governor частоти CPU або регресія драйвера.
• Зміни стека зберігання: зміни версії ZFS, що впливають на поведінку ARC або обробку sync write; зміни версії Ceph, що змінюють поведінку recovery/backfill.
• Дріфт конфігурації апаратного забезпечення VM: типи контролерів, режими кешу, iothreads, ballooning або зміни моделі CPU.
• Сервіси кластера: чутливість corosync до затримок, проблеми синхронізації часу або «корисна» поведінка watchdog.
• Нові фонові роботи: scrubs/resilvers, перевантаження Ceph при ребалансі, SMART-сканування, підвищене опитування pvestatd, буря логів.

Оновлення також виявляють вже наявні гріхи. Ваша платформа могла виживати завдяки вдалому кешуванню, низькому завантаженню або випадковій вигідній поведінці драйвера. Оновлення забирають цю вдачу.

Одна цитата, яку варто мати на стіні:

«Сподівання — не стратегія.» — James Cameron

Це стосується й оновлень: ставтеся до них як до управління змінами, а не як до настрою.

Цікавинки та історичний контекст

1. KVM з’явився в Linux у 2007 році, і він переміг здебільшого тому, що це була «просто» віртуалізація в ядрі Linux, а не окремий світ гіпервізора.
2. Virtio створили, щоб уникнути емулювання повільного застарілого апаратного забезпечення. Коли драйвери virtio відсутні або неузгоджені, ви можете бачити 10× різниці в пропускній здатності диска та NIC.
3. ZFS прийшов до Linux через порт (OpenZFS), і він відомий своєю цілісністю даних — але також чутливістю до RAM, шаблонів sync write і неправильно налаштованих dataset.
4. Продуктивність Ceph може виглядати «добре», навіть якщо він не здоровий, бо він продовжує обслуговувати IO, поки тихо виконує recovery та backfill у фоні.
5. Linux з часом перемикав багато систем на cgroup v2 за замовчуванням; зміни в обліку та плануванні можуть вплинути на хости Proxmox із великою кількістю контейнерів.
6. Сучасні NVMe диски швидкі, але не магічно стабільні: прошивка, стани енергозбереження і термальне дроселювання можуть створювати «зубчасті» патерни затримок після перезавантажень.
7. Філософія IO scheduler-ів змінилася: для швидких пристроїв часто виграє «none»; для повільніших дисків планувальники, що зливають запити, можуть зменшити стрибки затримки.
8. Масштабування частоти CPU — це змінна продуктивності, а не галочка заради енергоощадності. Інше ядро за замовчуванням може перевести вас від передбачуваного до повільного під різкими навантаженнями.
9. Corosync покладається на вчасну доставку мережі. Невелике збільшення затримки або джитеру може викликати flapping членства, що виглядає як «випадкова повільність» в інших місцях.

Почніть з першопринципів: як правильно визначити «повільніше»

«Повільніше» — це скарга. Потрібен симптом, який можна виміряти.

Оберіть одне-дві репрезентативні робочі навантаження і визначте регрес у числах:

• База даних: 95-й процентиль latency commit, коефіцієнт влучань у буферний кеш, час fsync.
• Веб/API: латентність запитів за процентилями, рівень помилок, насичення CPU, run queue.
• Файловий сервер: пропускна здатність SMB/NFS, латентність операцій з метаданими, створення дрібних файлів.
• Резервні копії: MB/s і час виконання, а також затримка запису в періоди резервного копіювання.

Потім визначте, де саме відбувається очікування. Зазвичай це одне з наступного:

• I/O wait на хості: стрибки затримки зберігання, черги накопичуються, VMs затримуються.
• Затримка планування CPU: забагато runnable задач, помилки pinning, IRQ-шторм.
• Мережеві втрати/джитер: повторні передачі й таймаути, коросинк незадоволений, лаги при реплікації зберігання.
• Несумісність драйверів у гостьовій ОС: застарілі virtio-драйвери, неправильний тип контролера, дивні режими кешу.

Жарт #1: регресії продуктивності схожі на «ще одну зустріч» — ніхто її не планує, але всі на ній присутні.

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

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

Завдання 1: Підтвердіть, що саме змінилося (kernel, pve, qemu)

cr0x@server:~$ pveversion -v
pve-manager/8.2.2/bb2d... (running kernel: 6.8.12-3-pve)
proxmox-ve: 8.2-1 (running kernel: 6.8.12-3-pve)
qemu-server/8.2.4/...
libpve-storage-perl/8.2.2/...

Значення: Ви тепер знаєте версії ядра та стека. «Стало повільніше» часто відповідає «змінено kernel» або «змінено QEMU».

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

Завдання 2: Перевірте, чи хост зв’язаний CPU, I/O або просто спантеличений

cr0x@server:~$ uptime
 14:02:11 up 12 days,  3:45,  3 users,  load average: 18.21, 16.77, 15.90

Значення: Load average рахує runnable задачі та задачі в неперервному сні (часто I/O). Високий load не обов’язково означає високе використання CPU.

Рішення: Поєднайте це з використанням CPU за ядрами та наступною перевіркою iowait. Якщо load високий, але CPU використання помірне, підозрюйте затримку зберігання або contention у ядрі.

Завдання 3: Пошукайте iowait і steal time на хості

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.8.12-3-pve (server)  12/26/2025  _x86_64_  (32 CPU)

Average:     CPU   %usr   %nice    %sys %iowait   %irq  %soft  %steal  %idle
Average:     all   12.40    0.00    4.10   18.70   0.00   0.80    0.00  64.00
Average:       0   10.00    0.00    3.00   22.00   0.00   0.50    0.00  64.50

Значення: Постійний %iowait у десятках означає, що CPU чекає на зберігання. %steal зазвичай 0 на bare metal, але важливий при nested virtualization.

Рішення: Якщо iowait високий — припиніть «налаштування CPU». Перейдіть до перевірки затримки зберігання та глибини черги негайно.

Завдання 4: Визначте топ-процеси і чи заблоковані вони на IO

cr0x@server:~$ top -b -n 1 | head -25
top - 14:02:33 up 12 days,  3:45,  3 users,  load average: 18.21, 16.77, 15.90
Tasks: 812 total,   5 running, 807 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.3 us,  4.1 sy,  0.0 ni, 64.0 id, 18.7 wa,  0.0 hi,  0.9 si,  0.0 st
MiB Mem : 256000.0 total,  84000.0 free,  42000.0 used, 130000.0 buff/cache
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
8421 root      20   0 11.8g   2.1g  10500 S  180.0  0.8  90:12.22 kvm
9211 root      20   0 10.2g   1.9g   9700 D   40.0  0.7  15:44.01 kvm

Значення: Стан D означає неперервний сон — часто блок на I/O. Побачити KVM-потоки в стані D — класичний індикатор «зберігання гальмує VMs».

Рішення: Перейдіть до перевірки затримок на рівні пристроїв (iostat, nvme smart-log, здоров’я ZFS/Ceph) перед змінами конфігурації VM.

Завдання 5: Виміряйте затримку диска та черги по пристроях

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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.35    0.00    4.12   18.69    0.00   64.84

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
nvme0n1         120.0  980.0   4200.0 128000.0    240.0     9.80    9.60     2.10    10.50   0.35  38.0
sda               2.0   80.0     40.0   1800.0     46.0     3.20   45.00     8.00    46.00   1.20  95.0

Значення: Дивіться на await та avgqu-sz. Повільний пристрій із високим utilization і великим await (як sda вище) може тягнути весь шлях зберігання, якщо він частина пулу/масиву або використовується для логів.

Рішення: Якщо один пристрій зайнятий на високий %util з великим await — визначте, для чого він використовується (спеціальний vdev ZFS? диск для завантаження? Ceph WAL/DB?) і виправте цей шлях.

Завдання 6: Підтвердіть стан пулу ZFS і чи виконується фонове відновлення

cr0x@server:~$ zpool status -v
  pool: rpool
 state: ONLINE
status: One or more devices is currently being resilvered.
action: Wait for the resilver to complete.
 scan: resilver in progress since Thu Dec 26 12:11:09 2025
        1.22T scanned at 1.80G/s, 220G issued at 320M/s, 3.45T total
        220G resilvered, 6.2% done, 02:45:12 to go
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            nvme0n1 ONLINE       0     0     0
            nvme1n1 ONLINE       0     0     0

Значення: Resilver або scrub може сильно навантажувати I/O. Після оновлення/перезавантаження ці завдання можуть стартувати або відновитися.

Рішення: Якщо у вас екстрена ситуація з продуктивністю, розгляньте планування scrubs/resilvers більш обережно (не «ніколи»), і зменшіть конкуренцію за ресурси під час вікон відновлення.

Завдання 7: Перевірте властивості dataset ZFS, що впливають на затримку (sync, compression, recordsize)

cr0x@server:~$ zfs get -o name,property,value -s local,received sync,compression,recordsize,logbias,primarycache rpool/data
NAME        PROPERTY     VALUE
rpool/data  sync         standard
rpool/data  compression  zstd
rpool/data  recordsize   128K
rpool/data  logbias      latency
rpool/data  primarycache all

Значення: Оновлення зазвичай не змінюють ці параметри самі по собі, але міграції та «корисні налаштування» інколи роблять це. sync і logbias — це важелі латентності для sync-насичених робочих навантажень.

Рішення: Якщо бачите sync=always несподівано, очікуйте повільніших баз даних. Виправляйте корінь проблеми (NFS експорти? успадковані dataset?) замість сліпого відключення sync.

Завдання 8: Спостерігайте за тиском ARC (пам’ять vs кеш)

cr0x@server:~$ arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  size     c
14:03:51   812   120     14    28    3    70    8    22    3  96.1G  108G
14:03:52   790   140     17    31    4    81   10    28    4  95.9G  108G
14:03:53   840   160     19    35    4    91   11    34    4  95.8G  108G

Значення: Зростаючий miss% і зменшення ARC змушують більше читань йти на диск. Після оновлень патерни використання пам’яті можуть змінитися (контейнери, сервіси, використання пам’яті ядром).

Рішення: Якщо ARC постійно стискається, перевірте виділення RAM на хості, ballooning і чи не з’явилися нові сервіси (наприклад, Ceph демони), які конкурують за пам’ять.

Завдання 9: Підтвердіть стан Ceph і чи він відновлюється/ребаланситься

cr0x@server:~$ ceph -s
  cluster:
    id:     9e2a...c6
    health: HEALTH_WARN
            1 osds down
            Degraded data redundancy: 24/1024 objects degraded
            Reduced data availability: 8 pgs inactive
  services:
    mon: 3 daemons, quorum pve1,pve2,pve3
    mgr: pve1(active), standbys: pve2
    osd: 11 osds: 10 up, 11 in
  data:
    pools:   4 pools, 256 pgs
    objects: 1.2M objects, 4.1 TiB
    usage:   12 TiB used, 24 TiB / 36 TiB avail
    pgs:     8 inactive, 24 degraded
  io:
    client:   220 MiB/s rd, 45 MiB/s wr, 1.8k op/s rd, 0.6k op/s wr

Значення: Стан «WARN» з degraded PGs і recovery означає, що клієнтський IO конкурує з recovery IO. Продуктивність буде нестабільною.

Рішення: Виправте стан здоров’я спочатку. Налаштовувати хворий Ceph — це як переставляти стільці під час турбулентності.

Завдання 10: Перевірте, чи recovery/backfill споживає кластер

cr0x@server:~$ ceph tell 'osd.*' perf dump | head
{
    "filestore": {
        "journal_queue_max_ops": 500,
        "op_queue_max_ops": 1000
    },
    "throttle-msgr_dispatch_throttler": {
        "val": 0
    }
}

Значення: Це груба перевірка. Насправді ви будете дивитися на recovery rates, backfill і лічильники продуктивності OSD, щоб зрозуміти, чи кластер зайнятий «самовідновленням».

Рішення: Якщо recovery важкий і бізнес потребує продуктивності зараз, тимчасово налаштуйте параметри recovery (обережно) і заплануйте ремонт. Але не залишайте їх постійно підтиснутими з боязні.

Завдання 11: Перевірте помилки NIC, дропи і стан лінку

cr0x@server:~$ ip -s link show dev bond0
4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes  packets  errors  dropped  missed  mcast
    91234567890  81234567  0       124      0       0
    TX:  bytes  packets  errors  dropped  carrier collsns
    78123456789  73456789  0       0        0       0

Значення: RX-пакети, що дропаються після оновлення, можуть бути пов’язані з offload-налаштуваннями, розміром кільця, регресією драйвера або невідповідністю MTU, що призводить до фрагментації/чорних дір.

Рішення: Якщо дропи зростають постійно — трактуйте це як мережевий інцидент. Перевірте offloads, MTU наскрізь, лічильники на комутаторі та драйвер/прошивку.

Завдання 12: Перевірте, чи bridge і VLAN конфігурація збігаються з тим, що ви вважали застосували

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto bond0
iface bond0 inet manual
        bond-slaves eno1 eno2
        bond-miimon 100
        bond-mode 802.3ad
        mtu 9000

auto vmbr0
iface vmbr0 inet static
        address 10.10.0.11/24
        gateway 10.10.0.1
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0
        mtu 9000

Значення: Після оновлення інколи відбувається перейменування інтерфейсу, відсутній модуль або неправильно застосована конфігурація, що створює «майже робочий» але деградований шлях (наприклад, bond деградував до одного лінку, MTU неузгоджений).

Рішення: Якщо конфігурація не відповідає вашому задуму — виправте її перш ніж проводити бенчмарки хаосу.

Завдання 13: Перевірте затримку corosync («повільний» кластер може бути проблемою комунікацій)

cr0x@server:~$ corosync-cfgtool -s
Printing ring status.
Local node ID 1
RING ID 0
        id      = 10.10.0.11
        status  = ring 0 active with no faults
RING ID 1
        id      = 10.20.0.11
        status  = ring 1 active with no faults

Значення: Це показує статус кілець, а не продуктивність. Якщо бачите faults або ring flaps — ваша «повільність» може бути спричинена турбулентністю стану кластера.

Рішення: Якщо кільця нестабільні — зупиніться і виправте мережу/синхронізацію часу. HA, міграції та координація зберігання стануть гіршими.

Завдання 14: Пошукайте підказки в логах ядра (скидання драйверів, таймаути NVMe, soft lockups)

cr0x@server:~$ journalctl -k -p warning --since "2 hours ago" | tail -20
Dec 26 12:44:10 server kernel: nvme nvme0: I/O 123 QID 6 timeout, reset controller
Dec 26 12:44:11 server kernel: nvme nvme0: controller reset succeeded
Dec 26 12:58:22 server kernel: ixgbe 0000:3b:00.0: Detected Tx Unit Hang

Значення: Таймаути та скидання — вбивці продуктивності, що часто маскуються під «випадкову повільність». Після оновлення поведінка драйвера може виявити маргінальне апаратне або баг прошивки.

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

Завдання 15: Перевірте governor частоти CPU та налаштування живлення

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave

Значення: «powersave» може бути прийнятним на деяких платформах, але жахливим на інших. Після оновлень значення за замовчуванням може змінитися, або оновлення мікрокоду може змінити поведінку boost.

Рішення: Якщо чутливі до латентності навантаження постраждали і у вас виставлено powersave — випробуйте перехід на performance (з контролем змін) і виміряйте ефект.

Завдання 16: Перевірте конфіг VM на предмет контролера диска та режимів кешу

cr0x@server:~$ qm config 104 | egrep 'scsi|virtio|cache|iothread|cpu|balloon'
balloon: 4096
cpu: x86-64-v2-AES
scsi0: rpool/data/vm-104-disk-0,cache=writeback,iothread=1,discard=on,size=200G
scsihw: virtio-scsi-single

Значення: Режими кешу і типи контролерів мають значення. cache=writeback може бути швидким і небезпечним без гарантій зберігання; інші режими безпечніші, але повільніші. virtio-scsi-single з iothread допомагає паралельності.

Рішення: Якщо лише певні VMs уповільнились, порівняйте їхні конфіги. Змінена модель CPU або відсутній iothread може виглядати як «все стало повільним» для конкретного навантаження.

Регресії зберігання: ZFS, Ceph і «куди поділися мої IOPS?»

Більшість інцидентів «Proxmox повільний після оновлення» насправді пов’язані з затримкою зберігання. Гіпервізор отримує звинувачення, бо він загальний шар. Зберігання — це місце, де дрібні зміни стають помітним болем.

ZFS на Proxmox: класичні шаблони регресії

ZFS чудовий, якщо поважати його потреби: RAM, розумне розташування vdev і чітка політика для sync writes. Він також безжальний, якщо ви експлуатуєте його як ext4 з відчуттям.

1) Sync-записи стали дорогими

Бази даних і диски VM виконують sync-записи. Якщо підлягаюче сховище не може швидко їх підтвердити — усе зупиняється. Загальні тригери після оновлення:

• Пристрій, що використовувався як SLOG (separate log), тепер повільний, падає або відсутній.
• Оновлення ядра змінило поведінку NVMe або чергування.
• Навантаження змістилося і перетнуло межу, де стрибки латентності стали постійними.

Перевірте, чи маєте SLOG і чи він здоровий:

cr0x@server:~$ zpool status
  pool: rpool
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            nvme0n1 ONLINE       0     0     0
            nvme1n1 ONLINE       0     0     0
        logs
          nvme2n1   ONLINE       0     0     0

Рішення: Якщо існує виділений лог-пристрій, підтвердіть, що він не є вузьким місцем. Повільний SLOG може перетворити sync-записи на повільний сироп.

2) Special vdev і «гарячі» точки метаданих

Якщо ви використовуєте special vdevs (metadata/small blocks), регресія на тому пристрої шкодить всьому. Перевірте нерівномірну латентність у iostat і SMART/здоров’я пристроїв.

3) Поведінка ARC змінилася через зміну тиску пам’яті

Після оновлень ви можете запускати більше сервісів (модулі Ceph mgr, експортери, додаткові демони) або змінилося облік пам’яті в контейнерах. ARC стискається, читальна латентність зростає, і з’являється «випадкова повільність», яка насправді — «шторм пропусків кешу».

4) Неспівпадіння recordsize ZFS і робочого навантаження

Recordsize — це не іграшка для налаштування; це рішення щодо розташування даних. Більшість VM-образів нормально працюють із 128K, але деякі випадкові I/O навантаження виграють від менших блоків. Оновлення не змінюють recordsize, але змінюють середовище настільки, що ви нарешті помічаєте невідповідність.

Ceph на Proxmox: здоров’я перш за все, налаштування потім

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

• OSD, що флапають через мережеві проблеми або таймаути
• Recovery/backfill, що споживає IO і мережу
• Невідповідний MTU або NIC offloads, що викликають втрати пакетів і повторні передачі
• Зміни CRUSH або reweight, що запускають ребаланс
• Зміни клієнтського ядра (якщо використовуєте RBD), що впливають на латентність

Якщо у вас уповільнення і Ceph не у стані HEALTH_OK, вважайте попередження коренем проблеми, поки не доведете протилежне.

Бенчмаркуйте обережно, або ви протестуєте власну помилку

Використовуйте fio тільки коли розумієте blast radius. Не запускайте випадковий write-бенчмарк на продакшен-пулі опівдні й не називайте це «діагностикою». Ви діагностуєте себе в інциденті.

Тим не менш, контрольований невеликий бенчмарк може підтвердити, чи фундаментально змінилася продуктивність хоста:

cr0x@server:~$ fio --name=latcheck --filename=/rpool/data/latcheck.bin --size=2G --direct=1 --rw=randread --bs=4k --iodepth=16 --numjobs=1 --runtime=20 --time_based=1 --group_reporting
latcheck: (groupid=0, jobs=1): err= 0: pid=18821: Thu Dec 26 14:10:12 2025
  read: IOPS=52.1k, BW=203MiB/s (213MB/s)(4062MiB/20001msec)
    slat (nsec): min=920, max=112k, avg=2450.1, stdev=2100.4
    clat (usec): min=60, max=7800, avg=286.2, stdev=120.4
    lat  (usec): min=63, max=7805, avg=289.0, stdev=121.0

Значення: Ви дивитеся на розподіл латентності: середнє й максимум. Кілька мс максимум зазвичай нормально; десятки/сотні мс максимум під невеликим навантаженням означають затримки зберігання.

Рішення: Якщо це значно гірше за вашу відому базу (або гірше за інші хости), зосередьтеся на здоров’ї пристроїв, логах ядра, фонoвих роботах ZFS/Ceph і змінах конфігурації зберігання.

CPU і планування: вкрадений час, pinning і сюрпризи ядра

Коли зберігання в порядку, наступною найпоширенішою регресією є планування CPU. Proxmox — це Linux; Linux чудовий; Linux також цілком здатний запрограмувати вас у кут, якщо дати йому неправильні обмеження.

Поширена CPU-регресія після оновлення: масштабування частоти

Деякі оновлення змінюють драйвер CPUfreq (intel_pstate vs acpi-cpufreq) або скидають налаштований governor. Симптом передбачуваний: однопотокова продуктивність падає, латентність зростає, а загальне використання CPU може виглядати помірним.

Перевірте поточну політику:

cr0x@server:~$ grep . /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor 2>/dev/null | head
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:powersave
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:powersave

Рішення: Якщо ви очікуєте стабільної продуктивності — розгляньте встановлення політики явно (і документуйте це). Міряйте до і після; не просто перемикайте і не оголошуйте перемогу.

IRQ-шторм і високе навантаження softirq

Після оновлень драйвера NIC може змінитися поведінка переривань. Симптоми:

• Високе %soft у mpstat
• Пропускна здатність мережі падає, а CPU зростає
• Збільшення дропів пакетів

Подивіться на переривання:

cr0x@server:~$ cat /proc/interrupts | head -15
           CPU0       CPU1       CPU2       CPU3
  0:         42          0          0          0   IO-APIC   2-edge      timer
 24:   81234567   79234561   80123455   81111222   PCI-MSI  524288-edge  ixgbe
 25:       1024       1100       1008       990    PCI-MSI  524289-edge  ixgbe

Рішення: Якщо один або два ядра забиті перериваннями після оновлення — дослідіть IRQ affinity і конфігурацію черг NIC. Не «виправляйте» це, даючи VM більше vCPU.

Pinning CPU: чудово, коли правильно, і жорстоко, коли ні

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

Перевірте зафіксовані VMs і їхні CPU маски. У Proxmox це часто в конфігурації VM (cores, cpulimit, cpuunits) і в інструментах хоста для тюнінгу.

Оновлення ядра також можуть змінити, як CFS балансує задачі по CPU. Якщо ви зафіксовані надто щільно й маєте інтенсивні обробники I/O на тих же ядрах — ви просто воюєте із собою.

Мережеві регресії: bridge, offloads, MTU і corosync

Мережеві регресії після оновлення хитрі. Тести пропускної здатності можуть виглядати нормально, але трафік, чутливий до латентності (реплікація зберігання, corosync, дрібні RPC), страждає.

Невідповідність MTU: класичне «працює, але повільно»

Якщо ви використовуєте jumbo frames (MTU 9000) на bond/bridge, потрібно забезпечити послідовність по всьому шляху: NIC, bond, bridge, порти комутатора, VLAN і кінцеві точки (включно з мережею зберігання). Невідповідність може призвести до фрагментації або дропів залежно від шляху і поведінки DF bit.

Перевірте MTU на кожному рівні:

cr0x@server:~$ ip link show vmbr0 | grep mtu
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000

Рішення: Якщо деякі вузли показують MTU 9000, а інші — 1500, виправте невідповідність перед тим, як звинувачувати зберігання.

Offloads і зміни драйверів

Після оновлень значення offload NIC можуть змінитись. Інколи offloads допомагають, інколи створюють дивну поведінку з bridge/VLAN або з певною прошивкою комутатора. Якщо бачите дропи й повторні передачі — перевірте offload-настройки і тестуйте зміни обережно.

cr0x@server:~$ ethtool -k eno1 | egrep 'tcp-segmentation-offload|generic-segmentation-offload|generic-receive-offload'
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

Рішення: Якщо підозрюєте проблеми, пов’язані з offload — тестуйте по одному зміненню й вимірюйте. Не вимикайте все підряд без аналізу.

Чутливість corosync

Corosyncу не потрібна велика пропускна здатність. Йому потрібні низький джитер і мінімальні втрати. Невелика мережева регресія може спричинити нестабільність кластера, що потім викликає вторинний вплив на продуктивність: неуспішні міграції, churn у HA і затримки операцій зберігання.

Шукайте скарги corosync:

cr0x@server:~$ journalctl -u corosync --since "24 hours ago" | tail -20
Dec 26 09:15:22 server corosync[1482]: [TOTEM ] Token has not been received in 2500 ms
Dec 26 09:15:22 server corosync[1482]: [TOTEM ] A processor failed, forming new configuration.

Рішення: Якщо бачите таймаути токена — сприймайте це як мережеву/часову проблему. Виправте її перед тим, як займатися налаштуванням продуктивності в інших місцях.

Зміни в QEMU/VM, що тихо шкодять

Іноді хост у порядку, а регресія специфічна: тільки Windows VMs, тільки одна база даних VM, тільки VMs на одному сховищі, тільки VMs, створені після оновлення.

Virtio драйвери і інструментар гостя

Windows-гості без сучасних virtio-драйверів можуть погіршити показники після змін у гіпервізорі. Linux-гості частіше справляються краще, але старі ядра все ще можуть мати проблеми з новими можливостями virtio.

Перевірте, чи QEMU guest agent флапає або працює некоректно:

cr0x@server:~$ qm agent 104 ping
{"return":{}}

Значення: Агент швидко відповідає. Якщо це таймаутиться для багатьох VMs після оновлення, можлива ширша проблема хоста або несумісність QEMU/агента.

Рішення: Якщо agent зависає — перевірте логи QEMU і навантаження хоста. Не припускайте, що це «просто агент» — це може бути симптом значніших зависань.

Режими кешу диска і бар’єри

Налаштування кешу — місце, де люди намагаються «прискорити». Це може спрацювати. Але також може дуже погано завершитися, коли хост впаде і ваш «швидкий» режим стане «корумпованим».

Після оновлення перевірте, що режим кешу і стек зберігання відповідають вашим очікуванням щодо надійності:

• Якщо ви покладаєтесь на writeback кеш, потрібен надійний захист при відключенні живлення і чітке розуміння ризиків.
• Якщо ви використовуєте ZFS, не боріться з ним дивними налаштуваннями, які створюють подвійне кешування і непередбачувану поведінку записів.

Зміни моделі CPU

Зміна моделі CPU може спричинити регресію всередині гостя (відсутність розширень крипто, векторних інструкцій, таймінг). Оновлення Proxmox можуть змінити значення за замовчуванням або виявити старі вибори.

Порівняйте налаштування моделі CPU між «швидкою» VM і «повільною» VM (qm config). Якщо одна використовує дуже загальну модель, вона може втратити набір інструкцій, що приносить вигоду вашому навантаженню.

Жарт #2: Найшвидший спосіб покращити продуктивність VM — перестати називати все «мережею». Це не мережа — поки не стане.

Три міні-історії з корпоративного життя (анонімізовані, правдоподібні і болючі)

Міні-історія 1: Інцидент через неправильне припущення

Вони оновили три-вузловий кластер Proxmox у тиху п’ятницю ввечері. Тікет змін був чистий: оновлення ядра, мала точкова версія Proxmox, перезавантаження кожного вузла. У неділю вдень дежурний отримав сповіщення: ERP-система «раптом зависає» на 5–20 секунд кілька разів на годину.

Перше припущення було класичним: «ZFS повільний, бо ARC скинувся під час перезавантаження, він прогріється». Вони чекали. Зависання продовжувались, а тепер і резервні копії теж таймаутили. Хтось почав правити tunables ZFS у продакшені, бо нічого не каже «неділя», як редагування /etc/modprobe.d під тиском.

Зрештою хтось подивився journalctl -k і побачив періодичні скидання контролера NVMe. Після оновлення драйвер NVMe змінився трохи з тією версією прошивки. Раніше пристрій був маргінальним, але «достатньо стабільним». Після — ні. Результат не був явним збоєм — просто періодичні зависання, що збігались з скаргами користувачів.

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

Урок: неправильне припущення було не «ZFS прогріється». Воно було «оновлення змінюють лише софт». Вони також змінюють спосіб, яким софт говорить з апаратурою, а апаратура завжди слухає.

Міні-історія 2: Оптимізація, що далася боком

Інша команда боролась з повільними записами баз даних у VMs. Хтось прочитав, що встановлення диска VM у cache=writeback прискорює роботу. І це спрацювало. Графіки засяяли. Латентність впала, пропускна здатність зросла, і всі відчули себе storage-інженерами на день.

Потім вони оновили Proxmox. Після оновлення хост почав виконувати більш агресивне фонове I/O під час scrubs, і writeback-cache це ховав — до моменту, коли не приховав. Під піковим навантаженням стрибки латентності стали частими. Вони «оптимізували» далі, збільшивши iodepth VM і додавши більше vCPU. Тепер VM могла генерувати хвилі записів швидше, ніж storage міг їх надійно записати. Стрибки латентності погіршались. База даних почала тригерити свої таймаути.

Вони звинувачували оновлення. Оновлення було співучасником, а не головним винуватцем. Реальна проблема полягала в тому, що вибір кешування змінив режими відмов і маскував справжню поведінку сховища під навантаженням sync write. Прискорення було реальним, але нестабільним за операційних умов.

Кінцеве виправлення полягало в узгодженні очікувань щодо надійності та продуктивності: перемістити VM бази даних на рівень сховища з належною продуктивністю sync write, переконатися, що SLOG не вузьке місце, і використовувати безпечніші режими кешування. Вони все ще отримали хорошу продуктивність — просто без рулетки.

Міні-історія 3: Нудна, але правильна практика, що врятувала ситуацію

Одна велика компанія використовувала Proxmox з Ceph і мала ритуал: перед будь-яким оновленням вони записували три базових показники на кожному вузлі — latency I/O хоста (iostat -x), стан здоров’я і recovery Ceph (ceph -s) та невеликий fio-профіль на виділеному тестовому томі. Вони також мали план поетапного оновлення з паузою після кожного вузла для спостереження.

Під час одного циклу оновлення, одразу після перезавантаження другого вузла, fio latency profile подвоївся. Не катастрофа, але чітка відмінність. Оскільки вони мали базу з попереднього тижня, це було не «можливо так завжди». Це було новим.

Вони зупинили оновлення. Без героїки. Порівняли логи ядра і знайшли повідомлення драйвера NIC, що корелювало зі зростанням дропів на мережі зберігання. Вузол піднявся з іншим offload-налаштуванням. Ceph був здоровий, але клієнтська латентність зросла через повторні передачі пакетів під навантаженням.

Виправлення було простим: уніфікувати NIC-налаштування по вузлах, перевірити лічильники комутатора, повторити базові тести, потім продовжити. Користувачі цього не помітили. Єдину драму викликав звіт на обговоренні змін, де хтось спитав, чому вони «зупинилися через таку малу різницю». Відповідь була проста: малі відмінності стають великими інцидентами о 2-й ночі.

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

Цей розділ спеціально конкретний. «Перевірте логи» — це не виправлення.

1) Симптом: високий load average, але CPU виглядає вільним

• Корінь: задачі заблоковані на I/O (високий iowait), часто затримки зберігання після оновлення.
• Виправлення: підтвердьте mpstat і iostat -x; потім ідентифікуйте пристрій/пул, що повільний; перевірте ZFS scrub/resilver або recovery Ceph; перевірте журнали ядра на таймаути.

2) Симптом: тільки Windows VMs стали повільнішими, особливо I/O

• Корінь: невідповідність драйверів virtio або VM змінила модель контролера; гостю бракує потрібних драйверів.
• Виправлення: перевірте контролер VM (qm config) і оновіть virtio-драйвери в гості; уникайте випадкових змін контролерів під час оновлень.

3) Симптом: випадкові зависання 5–30 секунд у кількох VMs

• Корінь: таймаути NVMe/скидання контролера, проблеми SATA link або регресія прошивки/драйвера, виявлена новим ядром.
• Виправлення: перевірте journalctl -k на предмет скидань/таймаутів; оновіть прошивку; протестуйте інше ядро, якщо доступне; мігруйте гарячі VMs з ураженого пристрою.

4) Симптом: Ceph-backed VM повільний «іноді», гірше після оновлення

• Корінь: Ceph у стані HEALTH_WARN, recovery/backfill конкурує з клієнтським I/O; або мережеві дропи на storage-мережі.
• Виправлення: приведiть Ceph до HEALTH_OK; перевірте статус OSD; перевірте дропи NIC; підтвердіть MTU і offloads; тільки потім налаштовуйте recovery rates.

5) Симптом: міграції повільні, дії HA затримуються, кластер відчувається нестабільним

• Корінь: таймаути corosync через мережевий джитер, невідповідний MTU або проблеми синхронізації часу.
• Виправлення: підтвердіть журнали corosync; перевірте кільця; перевірте лічильники NIC; перевірте службу синхронізації часу; тримайте corosync на чистій, нудній мережі.

6) Симптом: пропускна здатність ок, але хвостова латентність жахлива

• Корінь: чергування і поведінка при сплесках; часто зміна IO scheduler, write amplification або фонові роботи (scrub/resilver, trim, резервні копії).
• Виправлення: дивіться iostat -x await і avgqu-sz; вивчіть фонові задачі; відкоригуйте розклад; перевірте глибину черг; розгляньте iothreads для завантажених дисків VM.

7) Симптом: дропи мережі зросли після оновлення, але лінк UP

• Корінь: зміна драйвера NIC/offload, розмір кільця або проблеми з bonding/LACP під час переговорів.
• Виправлення: інспектуйте ip -s link; перевірте offloads через ethtool; підтвердіть стан bond; порівняйте з іншими вузлами; уніфікуйте налаштування і прошивку.

Контрольні списки / покроковий план

Контрольний список A: 20-хвилинна триаж (безпечно для продакшену)

1. Підтвердіть версії: pveversion -v. Запишіть версії ядра і qemu.
2. Перевірте load і iowait: uptime, mpstat -P ALL 1 5.
3. Перевірте затримки пристроїв: iostat -x 1 5. Визначте найгірший пристрій.
4. Перевірте попередження ядра: journalctl -k -p warning --since "2 hours ago".
5. Якщо ZFS: zpool status -v на предмет scrub/resilver; zfs get для дивних параметрів dataset.
6. Якщо Ceph: ceph -s; не налаштовуйте продуктивність, поки кластер деградований.
7. Перевірте мережеві дропи: ip -s link, підтвердіть MTU і стан bond.
8. Виберіть одну повільну VM і порівняйте її qm config з відомо доброю VM.

Контрольний список B: 2-годинна ізоляція (знайти підсистему)

1. Визначте, чи регресія на всьому хості: порівняйте метрики по вузлах; знайдіть «поганий вузол».
2. Якщо один вузол гірший — порівняйте апаратні логи і версії прошивок NIC/дисків (не припускайте однорідність).
3. Запустіть невеликий fio read-only тест на безпечному шляху, щоб порівняти латентність між вузлами.
4. Перевірте переривання і softirq, якщо підозрюєте мережу (/proc/interrupts, mpstat).
5. Перевірте фонові роботи: ZFS scrub/resilver; Ceph recovery; резервні копії; trim/discard задачі.
6. Якщо підозрюєте ядро, розгляньте завантаження попереднього ядра (з планом відкату) для підтвердження причинно-наслідкового зв’язку.

Контрольний список C: Закріплення після виправлення (щоб наступне оновлення не вдарило)

1. Запишіть бази (розподіли латентності, а не лише середні): iostat, невеликий fio-профіль, метрики латентності VM.
2. Уніфікуйте NIC offloads/MTU по вузлах; задокументуйте в процесі побудови.
3. Плануйте scrubs/resilvers/резервні копії поза піковими вікнами бізнесу.
4. Підтримуйте життєвий цикл прошивок: NVMe, NIC, BIOS, HBA.
5. Майте canary-вузол для оновлень; оновлюйте його першим і спостерігайте 24–48 годин, якщо можливо.
6. Запишіть відому добру апаратну конфігурацію VM (тип контролера, режим кешу, модель CPU) і застосовуйте її послідовно.

Питання та відповіді

1) «Після оновлення все повільніше.» Це зазвичай Proxmox?

Зазвичай це шар ядра/зберігання/мережі, що змінився під Proxmox. Proxmox — точка інтеграції, тому його звинувачують. Почніть з iowait, затримок диска і дропів NIC.

2) Як швидко зрозуміти, чи це зберігання чи CPU?

mpstat — ваш друг. Високий %iowait вказує на зберігання. Високі %usr/%sys з низьким iowait вказують на насичення CPU або роботу ядра. Потім підтвердіть iostat -x.

3) Чи може scrub/resilver ZFS настільки уповільнити VMs?

Так, особливо на HDD-пулах або пулах з навантаженими vdev. Воно конкурує за I/O і може підвищити латентність. Бази даних відчують це негайно.

4) Ceph у HEALTH_WARN, але «працює майже нормально». Чи варто вважати його причиною?

Так. «Майже нормально» — спосіб розподілених систем заманити вас у спокусу. Recovery/backfill і degraded PGs можуть викликати видиму користувачеві латентність.

5) Після оновлення продуктивність диска VM впала. Чи змінити режим кеша на writeback?

Не як перший крок. Це може покращити швидкість, але змінює семантику надійності. Спочатку виправте базову латентність (здоров’я пристроїв, розташування пулу, стан Ceph). Якщо міняєте режим кеша — робіть це обдумано з прийняттям ризиків.

6) Чому я бачу високий load average, але CPU стоять простими?

Load включає задачі в неперервному сні (часто I/O). Тому можна мати високий load і idle CPU, якщо система чекає на зберігання.

7) Чи може невідповідність MTU справді виглядати як «повільне зберігання»?

Абсолютно. Якщо ваша storage-мережа дропає великі кадри або фрагментує непередбачувано, ви побачите повторні передачі і джитер. Протоколи зберігання чутливі до цього.

8) Чи варто негайно відкотити ядро?

Якщо у вас є сильні докази, що регресія пов’язана з ядром/драйвером (нові скидання/таймаути, зависання NIC), відкат — допустимий механізм пом’якшення. Підтвердіть логи і зробіть контрольований тест. Не відкочуйте сліпо без розуміння ризиків та наслідків для безпеки.

9) Чи нормально, що продуктивність змінюється після перезавантаження через «холодні» кеші?

Деяка різниця нормальна — ARC і page cache прогріваються. Але стійке уповільнення через декілька годин або періодичні зависання — це не «холодний кеш». Це справжнє вузьке місце.

10) Як уникнути цього наступного разу?

Записуйте базові метрики перед оновленнями, використовуйте canary-вузол, уніфікуйте прошивки і перестаньте ставитись до зберігання й мережі як до «налаштуй і забудь». Вони пам’ятають.

Висновок: наступні кроки, які дійсно працюють

Якщо Proxmox став повільнішим після оновлення, не починайте з налаштувань VM. Почніть з доказу, яка підсистема змушує все чекати.

1. Класифікуйте вузьке місце: CPU vs storage vs network. Використовуйте mpstat і iostat, а не інтуїцію.
2. Перевірте фонові роботи і стан: ZFS resilvers/scrubs, Ceph recovery, нестабільність corosync.
3. Читайте попередження ядра: таймаути і скидання драйверів — це інциденти продуктивності в маскарадi.
4. Порівнюйте конфігурації й бази: знайдіть, що змінилося, виміряйте це і приймайте рішення на основі доказів.
5. Після стабілізації — закріплюйте: записуйте бази, уніфікуйте прошивки і налаштування NIC/сховища, використовуйте canary-підхід до оновлень.

Виконайте ці кроки, і ви зазвичай знайдете причину раніше, ніж наступна планова нарада самозапроситься у ваш календар.