Proxmox pveperf показує нісенітницю: як правильно тестувати продуктивність

Що таке pveperf (і чому він розчаровує)

pveperf — це швидкий «smoke test». Він розроблений, щоб дати вам грубий сигнал: «цей хост явно слабкий або неправильно налаштований?» Він не призначений для відповіді на питання типу:

• Чи витримає мій ZFS пул синхронні записи для PostgreSQL?
• Чи переживе мій Ceph кластер домени відмови з 3 вузлами під піковим навантаженням?
• Чому ВМ зупиняються під час запуску бекапів?
• Проблема в CPU steal, IO-затримках чи мережевій нестабільності?

pveperf запускає малі, примітивні тести (записи файлової системи, цикли CPU) і видає число. Малі тести люблять кеші і не люблять реальність. Якщо ви ставите це число в ранг SLA для сховища, ви опинитеся за дебагом о 2-й ночі, поки користувачі відкривають для себе поняття «витривалість кнопки оновлення».

Цікаві факти й контекст, які варто знати (щоб ви припинили тестувати не те)

1. Bonnie++ (і подібні мікробенчмарки) сформували ранню культуру Linux perf: швидкі числа використовували для порівняння дисків, але вони відомі чутливістю до кешу і тим, що їх легко «заграти».
2. Fio став стандартом, бо моделює IO-патерни: він може робити sync vs async, глибину черги, випадкові vs послідовні операції і звітувати розподіл затримок — не лише середні значення.
3. Середня затримка — брехун: хвостова затримка (p95/p99) ламає бази даних. Сучасна культура тестування сильно змістилася в бік перцентилів.
4. Writeback-кешування змінило правила гри (і режими відмов): контролери та SSD можуть підтверджувати записи до того, як вони стануть стійкими; тести виглядають чудово, доки ви не відключите харчування або не натрапите на межу скидання кешу.
5. ZFS навмисно жертвує сирою швидкістю заради коректності: copy-on-write та контрольні суми вимагають ресурсів; спроба змусити його поводитися як ext4-на-RAID0 породжує міфи.
6. Семантика fsync визначає навантаження: OLTP-база — по суті машина забезпечення стійкості; бенчмарк, який не моделює fsync, здебільшого вимірює оптимізм.
7. NVMe приніс глибину черги в повсякденність: SATA часто був обмежений малою чергою команд; NVMe справляється з глибокими чергами і карає неглибокі тести.
8. Virtio і паравіртуальні драйвери — це функції продуктивності: тестування всередині ВМ без virtio-драйверів — це тестування ваших помилок.

Тестування — це не число; це питання. Почніть з питання, а потім обирайте інструменти і параметри, що йому відповідають.

Чому результати pveperf виглядають як нісенітниця

pveperf часто видає числа, які одночасно «правдиві» й «марні». Ось основні режими відмов:

1) Він вимірює page cache, а не диск

Якщо тестовий файл поміщається в RAM, ви тестуєте пропускну здатність пам’яті і поведінку буферизації ядра. Ваш SSD не став у 10 разів швидшим; RAM просто зробила свою справу.

2) Він потрапляє в шлях файлової системи з непередбачуваною поведінкою

У Proxmox «типи» сховища мають значення. Тестування /var/lib/vz на local-lvm проти local-zfs чи NFS змінює все: кешування, синхронні семантики, навіть метадані витрати.

3) Він ігнорує контракт стійкості

Багато «швидких» тестів запису швидкі, бо не чекають на стабільне збереження. Якщо ваше навантаження потребує стійкості (бази даних, журнальні додатки, образи ВМ), потрібно тестувати з синхронними записами (або явним fsync), щоб знати, що ви купуєте.

4) Він працює надто коротко

Сучасне сховище має кілька фаз продуктивності: SLC-кеш-бурсти, теплове тротлінг, garbage collection, ZFS transaction group, Ceph recovery. 10-секундний тест — це скоріше привітання, ніж вимір.

5) Він приховує конкуренцію й чергування

Реальні системи — розділені: багато ВМ, фоновий scrub, бекапи, реплікація. «Нісенітний» результат часто — це найкращий-case у лабораторній фантазії, де нічого іншого не відбувається.

Жарт №1: pveperf — як зважувати автівку, перевіряючи, як швидко вона котиться з гори — технічно це вимір, емоційно — помилка.

Принципи тестування, що вбережуть від проблем

Визначте, що ви тестуєте: пристрій, файлову систему чи навантаження

• На рівні пристрою (raw disk/NVMe): «Чи обладнання здорове і правильно налаштоване?» Використовуйте інструменти nvme, smartctl, fio з --filename=/dev/nvme0n1 (обережно).
• На рівні файлової системи/пулу (ZFS dataset, LVM-thin, ext4): «Що моя стек сховища постачає ВМ?» Запускайте fio на файлі в цільовому маунті.
• На рівні додатку (база даних, ОС ВМ): «Чи відповідатиме сервіс SLO?» Використовуйте бенчмарки самого додатка плюс телеметрію IO.

Переважайте відтворюваність над героїчними числами

Тестування, яке не можна повторити, — не тестування; це оповідь. Контролюйте те, що можете:

• Запускайте тести у відомому стані системи (без scrub, без resilver, без бекапів).
• Фіксуйте версії ядра, Proxmox, розклад сховища, моделі дисків, прошивку.
• Фіксуйте стан масштабування частоти CPU.
• Фіксуйте планувальник IO, multipath і політику кешу контролера.

Перцентилі затримок важливіші за середню пропускну здатність

Пропускна здатність — приємно, але затримка — те, що відчувають користувачі. Вихідні дані, що включають перцентилі clat, відрізняють «начебто нормально» від «чому API таймаутить?»

Запускайте триваліше, щоб дочекатися стану рівноваги

Якщо ви не бачите, як система стабілізується, ви її не виміряли. Для SSD дайте час на прогрів; для ZFS дочекайтеся циклу transaction group; для Ceph зачекайте, поки кластер перестане «спілкуватися» і почне роботу.

Одна парафразована ідея (бо вона все ще вірна)

Парафразована ідея (Werner Vogels, reliability/operations): «You build it, you run it» означає: ви тестуєте це так, ніби вас будуть викликати у разі проблем.

Швидкий план діагностики: знайти вузьке місце швидко

Це послідовність «у вас є 20 хвилин до виклику інциденту». Мета — визначити, чи основне обмеження в CPU, диску, мережі або в конфігураційному ляпі.

Перш за все: підтвердіть симптом і знайдіть шар

1. На хості Proxmox: перевірте load, CPU steal (якщо є nested), тиск пам’яті і IO wait.
2. На шарі сховища: перевірте завантаження дисків, глибину черг і затримки.
3. У ВМ: підтвердіть, що це дійсно IO-затримка, а не свопінг гостя чи блокування в додатку.

По-друге: визначте, чи обмежені ви пропускною здатністю, IOPS чи затримкою

• Високий MB/s, низький IOPS — обмеження послідовної пропускної здатності.
• Високий IOPS, низький MB/s — типовий для малоблокових навантажень (бази даних).
• Низьке завантаження, але висока затримка — підозра на синхронні штрафи, невирівняний кеш, скидання контролера або мережеву нестабільність при мережевому сховищі.

По-третє: ізолюйте змінні одним контрольованим запуском fio

Запустіть fio на хості проти точного шляху сховища, який використовують ваші ВМ. Використовуйте direct IO. Розмір файлу — більший за RAM. Захопіть перцентилі. Рішайте на основі даних, а не вражень.

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

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

Завдання 1: Подивіться, що насправді тестує pveperf

cr0x@server:~$ pveperf /var/lib/vz
CPU BOGOMIPS:      59840.00
REGEX/SECOND:      2071670
HD SIZE:           222.22 GB (/dev/mapper/pve-root)
FSYNCS/SECOND:     1641.53
DNS EXT:           68.88 ms
DNS INT:           0.34 ms (pve1)

Що це означає: Рядок «HD SIZE» показує, який пристрій стоїть за шляхом. Якщо це pve-root на обертових дисках — не чекайте див. Якщо на ZFS — він не розповідає про налаштування dataset.

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

Завдання 2: Підтвердіть, що підставляє ваші Proxmox сховища

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local            dir      active        222.22G          48.13G         162.60G   21.66%
local-lvm        lvmthin  active          1.82T         910.24G         929.76G   50.04%
rpool            zfspool  active          3.62T           1.23T           2.39T   33.98%

Що це означає: Proxmox «storage» — не одне й те саме. Директорійне сховище поводиться інакше, ніж LVM-thin, інакше ніж ZFS.

Рішення: Тестуйте саме бекенд, де живуть диски ВМ. Якщо ВМ на local-lvm, не тестуйте /var/lib/vz і не ставте крапку.

Завдання 3: Перевірте поточний IO-прес і IO wait

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  0      0 421232  91264 882012    0    0    12    44  520  880  6  2 91  1  0
 1  3      0 418904  91272 882140    0    0     0  3240  610  990  5  2 70 23  0
 1  2      0 419120  91280 882188    0    0     0  2800  590  970  5  2 74 19  0

Що це означає: Стовпець wa — CPU, що чекає IO. Високий wa під час скарг — паличка-в-оці, але не вердикт.

Рішення: Якщо wa високий — йдіть прямо до затримки по диску (iostat) і черг; якщо wa низький — не переживайте про диски в першу чергу.

Завдання 4: Виміряйте затримку диска і завантаження (найшвидша правда)

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

Device            r/s   w/s  rkB/s  wkB/s  await  svctm  %util
nvme0n1         85.0 120.0  5120  19456    2.10   0.18  37.0
sda              2.0  95.0    64   4096   45.20   0.80  82.0
dm-0            10.0 110.0  1024  16384   39.10   0.00   0.0

Що це означає: await — середня затримка запиту. %util близьке до 100% означає насичення. Якщо sda показує await 45ms і 82% util — цей диск проблема незалежно від симпатій pveperf.

Рішення: Якщо await стабільно вище ~10ms для SSD навантажень або вище ~30ms для HDD у нормальному режимі — ви в «території інциденту продуктивності». Досліджуйте стек за цим пристроєм.

Завдання 5: Дізнайтеся, хто зараз робить IO

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

01:12:44 PM   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
01:12:45 PM     0      2123      0.00  82124.00      0.00  vzdump
01:12:45 PM     0      3891      0.00  11200.00      0.00  pveproxy
01:12:45 PM     0     15322    512.00   9200.00      0.00  kvm

Що це означає: Це пов’язує IO-прес з процесом. Якщо vzdump «б’є» по записах — ваша «випадкова затримка ВМ» стає менш загадковою.

Рішення: Тротлити бекапи, планувати їх або переносити на окреме сховище. Не звинувачуйте гіпервізор у стратегії бекапів.

Завдання 6: Перевірте, чи масштабування частоти CPU не саботує тести

cr0x@server:~$ cpupower frequency-info | sed -n '1,12p'
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  available cpufreq governors: performance powersave
  current policy: frequency should be within 800 MHz and 3500 MHz.
                  The governor "powersave" may decide which speed to use
  current CPU frequency: 900 MHz (asserted by call to hardware)

Що це означає: Якщо ви тестуєте при «запаркованому» CPU 900 MHz — отримаєте «нісенітні» результати й покличете у всьому диск за ледачий CPU.

Рішення: Для відтворюваних тестів тимчасово виставте governor performance. Для продакшену — обирайте свідомо; не дозволяйте дефолту вирішувати за вас.

Завдання 7: Переключіть governor на performance (тимчасово) і підтвердіть

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3

cr0x@server:~$ cpupower frequency-info | grep -E 'current policy|current CPU frequency'
  current policy: frequency should be within 800 MHz and 3500 MHz.
  current CPU frequency: 3401 MHz (asserted by call to hardware)

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

Рішення: Якщо продуктивність змінилася драматично — ваше навантаження може бути CPU-зв’язане або чутливе до латентності планування.

Завдання 8: Підтвердіть здоров’я ZFS pool і помітіть очевидні невідповідності

cr0x@server:~$ zpool status -v
  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 00:12:44 with 0 errors on Sun Dec 22 03:12:45 2025
config:

	NAME                        STATE     READ WRITE CKSUM
	rpool                       ONLINE       0     0     0
	  mirror-0                  ONLINE       0     0     0
	    nvme-SAMSUNG_MZVLB1T0   ONLINE       0     0     0
	    nvme-SAMSUNG_MZVLB1T0   ONLINE       0     0     0

errors: No known data errors

Що це означає: Деградований пул, resilver або помилки checksum роблять кожен тест підозрілим. Також час scrub підказує про фонову активність.

Рішення: Якщо стан не ONLINE/healthy — виправте сховище спочатку. Тестування хворого пулу — це просто кількісна оцінка суму.

Завдання 9: Перегляньте налаштування ZFS dataset, що впливають на IO ВМ

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

Що це означає: recordsize і sync можуть зробити або зламати IO для баз даних. primarycache=all може витісняти корисний кеш під навантаженням ВМ залежно від розміру пам’яті.

Рішення: Якщо диски ВМ на ZVOL, перевірте також volblocksize. Якщо в продакшені бачите sync=disabled для баз даних — зупиніться і переосмисліть ризики.

Завдання 10: Перевірте розмір блоку ZVOL (поширене невідповідність навантаження)

cr0x@server:~$ zfs list -t volume
NAME                USED  AVAIL  REFER  MOUNTPOINT
rpool/vm-101-disk-0  64G   1.1T    64G  -

cr0x@server:~$ zfs get -H -o property,value volblocksize rpool/vm-101-disk-0
volblocksize	8K

Що це означає: volblocksize задається при створенні ZVOL і не змінюється пізніше. 8K — поширено; інколи нормально, інколи підсилює накладні витрати при записах.

Рішення: Якщо багато 4K випадкових записів, 8K може працювати, але збільшити write amplification. Для великих послідовних навантажень розгляньте більші блоки на нових томах.

Завдання 11: Перевірте планувальник IO (особливо для не-NVMe)

cr0x@server:~$ cat /sys/block/sda/queue/scheduler
[mq-deadline] none kyber bfq

Що це означає: Планувальник впливає на затримки під конкуренцією. На багатьох SSD mq-deadline — розумний дефолт; на NVMe часто — none, і це нормально.

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

Завдання 12: Перевірте підтримку TRIM/Discard (SSD-саніті, довготривала продуктивність)

cr0x@server:~$ lsblk -D
NAME         DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                 0      512B       4G         0
nvme0n1             0        4K       2G         0
dm-0                0        0B       0B         0

Що це означає: Ненульовий DISC-GRAN вказує на підтримку discard. Якщо ви ніколи не робите discard для thin provisioning, продуктивність може деградувати, бо SSD втрачає внутрішні вільні блоки.

Рішення: Увімкніть discard там, де доречно (ZFS autotrim, таймери fstrim, thin-lvm discard), але розумійте компроміс латентності у вашому середовищі.

Завдання 13: Підтвердіть здоров’я мережі для NFS/iSCSI/Ceph трафіку

cr0x@server:~$ ip -s link show dev eno1 | sed -n '1,12p'
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    9876543210  8123456      0       12       0    12345
    TX:  bytes packets errors dropped carrier collsns
    8765432109  7345678      0        0       0       0

Що це означає: Drop-и важливі. Кілька під час сплесків можуть бути терпимі, постійний потік — ні. Сховище по мережі не любить втрати пакетів.

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

Завдання 14: Запустіть швидкий fio на хості по реальному шляху датастору

cr0x@server:~$ fio --name=randread --directory=/var/lib/vz --rw=randread --bs=4k --iodepth=32 --numjobs=4 --size=8G --time_based=1 --runtime=60 --direct=1 --group_reporting
randread: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
...
  read: IOPS=72.4k, BW=283MiB/s (297MB/s)(16.6GiB/60001msec)
    clat (usec): min=70, max=6200, avg=420.11, stdev=190.22
    clat percentiles (usec):
     |  1.00th=[  110],  5.00th=[  170], 10.00th=[  210], 50.00th=[  390]
     | 90.00th=[  690], 95.00th=[  900], 99.00th=[ 1400], 99.90th=[ 2400]

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

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

Рецепти fio, що відповідають на реальні питання

Fio — як бензопила: потужний, небезпечний і інколи використовується для нарізання хліба тими, хто любить хаос. Використовуйте його свідомо.

Правило: тестуйте там, де живе навантаження

Якщо ВМ працюють на local-lvm, тестуйте файл на тому маунті або блоковий пристрій, що відображається на нього (дуже обережно). Якщо ВМ на ZFS zvol, тестуйте на zvol або на файлі в датасеті, що їх підпирає.

Рецепт 1: Випадкові читання (4k) для «чи поводиться мій SSD пул?»

cr0x@server:~$ fio --name=rr4k --directory=/rpool --rw=randread --bs=4k --iodepth=64 --numjobs=4 --size=16G --time_based=1 --runtime=120 --direct=1 --group_reporting
rr4k: (g=0): rw=randread, bs=(R) 4096B-4096B, ioengine=libaio, iodepth=64
...
  read: IOPS=110k, BW=431MiB/s (452MB/s)(50.5GiB/120001msec)
    clat percentiles (usec):
     | 90.00th=[  520], 95.00th=[  740], 99.00th=[ 1300], 99.90th=[ 2200]

Інтерпретація: Сильні IOPS, прийнятний p99. Якщо p99.9 стрибне в десятки мілісекунд — скоріше конкуренція або проблема синхронізації/скидання десь ще.

Рішення: Якщо p99.9 неприйнятний — переходьте до телеметрії (iostat, zpool iostat, ceph health) і знайдіть джерело до «тонування».

Рецепт 2: Випадкові синхронні записи (4k) для моделювання комітів бази даних

cr0x@server:~$ fio --name=rsw4k --directory=/rpool --rw=randwrite --bs=4k --iodepth=1 --numjobs=4 --size=8G --time_based=1 --runtime=120 --direct=1 --fsync=1 --group_reporting
rsw4k: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, ioengine=libaio, iodepth=1
...
  write: IOPS=8200, BW=32.0MiB/s (33.6MB/s)(3.75GiB/120001msec)
    clat (usec): min=120, max=48000, avg=1850.22
    clat percentiles (usec):
     | 90.00th=[ 3200], 95.00th=[ 5800], 99.00th=[18000], 99.90th=[42000]

Інтерпретація: Sync-записи виявляють реальний шлях стійкості. Ці хвостові затримки — те, що викликає «замерзання додатка кожну хвилину».

Рішення: Якщо це погано: перевірте ZFS sync налаштування, наявність/якість SLOG (якщо є), політику кешу контролера і чи справді ваше «швидке» сховище підтверджує записи безпечно.

Рецепт 3: Послідовне читання (1M) для очікувань бекапу/відновлення

cr0x@server:~$ fio --name=sr1m --directory=/rpool --rw=read --bs=1M --iodepth=16 --numjobs=1 --size=32G --time_based=1 --runtime=120 --direct=1 --group_reporting
sr1m: (g=0): rw=read, bs=(R) 1024KiB-1024KiB, ioengine=libaio, iodepth=16
...
  read: BW=1710MiB/s (1793MB/s)(200GiB/120001msec)

Інтерпретація: Тут іноді й виникають щасливі числа pveperf. Корисно для планування вікон міграції, але не для прогнозу затримок БД.

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

Рецепт 4: Змішане читання/запис (70/30) випадкове для імітації загального навантаження ВМ

cr0x@server:~$ fio --name=mix7030 --directory=/var/lib/vz --rw=randrw --rwmixread=70 --bs=16k --iodepth=32 --numjobs=4 --size=16G --time_based=1 --runtime=180 --direct=1 --group_reporting
mix7030: (g=0): rw=randrw, bs=(R) 16.0KiB-16.0KiB, (W) 16.0KiB-16.0KiB, ioengine=libaio, iodepth=32
...
  read: IOPS=18.2k, BW=284MiB/s (298MB/s)
  write: IOPS=7810, BW=122MiB/s (128MB/s)
    clat percentiles (usec):
     | 90.00th=[ 1400], 95.00th=[ 2200], 99.00th=[ 5200], 99.90th=[12000]

Інтерпретація: Змішане IO показує манери стеку сховища. Слідкуйте за p99/p99.9; це ваша «ВМ відчуває лаг» зона.

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

Жарт №2: Якщо ви запустите fio не по тому шляху, він сумлінно доведе, що ваше сховище швидше, ніж ваша здатність читати власні маунтпоінти.

ZFS на Proxmox: пастки та правильні тести

ZFS — це файлово-системне рішення для продакшену, що передбачає, що вам важлива цілісність. Воно також передбачає, що ви звинуватите його в тестах, якщо не зрозумієте, як воно підтверджує дані. Виправимо це.

Чому тестування ZFS складне

• Copy-on-write означає, що малі випадкові записи можуть ампліфікуватись у більше IO, ніж ви очікуєте, залежно від recordsize/volblocksize і фрагментації.
• Transaction groups батчують записи; продуктивність може виглядати імпульсною. Короткий тест може спіймати тільки «хорошу» частину.
• ARC (RAM-кеш) робить читання приголомшливими, поки не перестає. Якщо хочете дискові числа — використовуйте --direct=1 і робочу множину більшу за RAM.
• Синхронні записи або безпечно підтверджені, або ні. ZFS ставиться до цього серйозно; тести, що це ігнорують, вимірюють інший контракт.

Видимість на хості: zpool iostat — ваш друг

cr0x@server:~$ zpool iostat -v 1 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
rpool       1.23T  2.39T  8.20K  3.10K   220M  64.0M
  mirror    1.23T  2.39T  8.20K  3.10K   220M  64.0M
    nvme0n1     -      -  4.10K  1.55K   110M  32.0M
    nvme1n1     -      -  4.10K  1.55K   110M  32.0M
----------  -----  -----  -----  -----  -----  -----

Що це означає: Це показує, що ZFS штовхає на кожен пристрій. Якщо fio каже «100k IOPS», але zpool iostat показує помірні операції — ймовірно ви б’єте в кеш або тест не досягає дисків.

Рішення: Погодьте параметри fio (direct IO, розмір файлу), поки zpool iostat не відобразить значиму активність пристрою.

Семантика sync: не ставте SLOG за магічний амулет

Виділений SLOG допомагає лише для sync-записів. І тільки якщо він швидкий, з малою латентністю і захищений від втрати живлення. Звичайний споживчий SSD як SLOG — чудовий спосіб змусити себе вірити в чудеса.

Якщо ви використовуєте SLOG, тестуйте синхронні записи явно і дивіться перцентилі затримок. Якщо покращення немає — вузьке місце в іншому (CPU, розклад vdev, або ви взагалі не були sync-bound).

Стиснення: корисне в продакшені, заплутує в тестах

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

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

Ceph на Proxmox: тестування без самообману

Ceph — розподілене сховище. Це означає, що ваш тест — це насправді перевірка мережі, медіа OSD, реплікації, CPU і здоров’я кластера. Якщо ви запускаєте тест під час backfill, ви тестуєте поведінку відновлення, а не steady-state.

Перевірте стан кластера перед вимірюванням

cr0x@server:~$ ceph -s
  cluster:
    id:     2c1e3a6d-9e4d-4a4d-9b2e-1a2b3c4d5e6f
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum pve1,pve2,pve3
    mgr: pve1(active), standbys: pve2
    osd: 9 osds: 9 up, 9 in

  data:
    pools:   3 pools, 256 pgs
    objects: 1.12M objects, 4.3TiB
    usage:   12TiB used, 18TiB / 30TiB avail
    pgs:     256 active+clean

Що це означає: active+clean PGs і HEALTH_OK — ваш базовий рівень. Все інше означає, що ваші числа відобразять поведінку під час обслуговування.

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

Виміряйте сирий пропуск та IOPS Ceph (і знайте, що це означає)

cr0x@server:~$ rados bench -p rbd 60 write --no-cleanup
hints = 1
Maintaining 16 concurrent writes of 4194304 bytes to objects of size 4194304 for up to 60 seconds or 0 objects
...
Total written: 2388 MiB
Bandwidth (MB/sec): 39.8
Average IOPS: 9
Average Latency(s): 1.72

Що це означає: Це тест на рівні кластера через RADOS-об’єкти, не обов’язково те саме, що RBD-продуктивність для ВМ. Проте він виявляє, чи кластер фундаментально повільний.

Рішення: Якщо пропуск низький і затримка висока — перевірте мережу (MTU, дропи), затримку дисків OSD і насичення CPU. Не «оптимізуйте Proxmox» у першу чергу.

Перевірте якість мережевого шляху для Ceph (латентність і втрата)

cr0x@server:~$ ping -c 20 -i 0.2 pve2
PING pve2 (10.10.10.12) 56(84) bytes of data.
64 bytes from 10.10.10.12: icmp_seq=1 ttl=64 time=0.286 ms
...
20 packets transmitted, 20 received, 0% packet loss, time 3804ms
rtt min/avg/max/mdev = 0.251/0.302/0.401/0.038 ms

Що це означає: Ceph не любить джиттер. Низьке середнє — добре; низька варіативність — краще.

Рішення: Якщо бачите втрати або велику варіативність — виправте комутатори, NIC, bonding або перевантаження перед тим, як чіпати Ceph-тюнінги.

Ceph-тестування заслуговує окремої книги, але принцип простий: перевірте здоров’я спочатку, потім сервіс сховища, потім досвід ВМ. Якщо пропускаєте шари — будете тонувати симптоми.

Три корпоративні міні-історії з практики

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

В одній середній компанії з Proxmox-кластером команда замінила старий SAN на локальні NVMe-дзеркала під ZFS. Міграція пройшла гладко. pveperf виглядав фантастично. Всі привіталися і пішли додому в розумний час — що мало б бути першим натяком, що щось не так.

За два тижні портал клієнта почав тайм-аутитися в пікові години. Не постійно — досить, щоб кількість заявок у сапорті зросла. Інженер на виклику перевірив CPU і пам’ять. Все добре. Мережа виглядала чистою. Графіки сховища показували «високу пропускну здатність», тож сховище ментально виправдали.

Справжній винуватець: найважливіше навантаження було база даних у ВМ із інтенсивними sync-записами. ZFS робив правильно: шанував семантику sync. Але бенчмарк, яким вони приймали міграцію, був переважно послідовним, буферизованим і коротким. Він виміряв легкий шлях.

Коли вони запустили fio з --fsync=1 і глянули на p99, історія змінилася. Хвостова затримка була жахлива в пікові моменти. їм не потрібні були «більші MB/s»; їм потрібен був передбачуваний шлях sync-записів та менша конкуренція під час хвиль комітів.

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

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

В іншому середовищі були змішані навантаження: CI-ранери, кеші збірки, кілька баз даних і купа загальних ВМ. Хтось прочитав, що «вимкнення sync покращує продуктивність ZFS», побачив sync=disabled в якомусь форумі і застосував його до датасету з дисками ВМ.

Миттєво бенчмарки стали приголомшливими. pveperf піднявся. fio без fsync був практично підбіркою кращих моментів. Менеджмент був задоволений — бо менеджмент завжди любить графіки, що ростуть.

Потім хост впав під час відключення живлення. UPS зробив, що міг; реальність зробила, що робить. Декілька ВМ повернулися з пошкодженими файловими системами і неконсистентним станом додатків. Проблема не в тому, що ZFS «втратив дані» випадково — він зробив саме те, що йому наказали: підтвердив записи, які не були гарантовано збережені.

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

Вони відкотили sync-поведінку, задокументували причини і побудували набір тестів, що явно перевіряє latency синхронних записів. Найкраща «оптимізація» — не брехати собі у майбутньому.

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

Одна фінансова організація використовувала Proxmox з Ceph для зберігання ВМ. Нічого гламурного. Багато вимог щодо відповідності. SRE-команда мала просту практику: щоквартально виконувати однаковий набір бенчмарків у контрольованих умовах і зберігати результати з моментальними знімками здоров’я кластера.

Це було не круто. Пара fio-профілів на RBD-backed ВМ, sanity-check rados bench і телеметрія хостів (iostat, ceph -s, лічильники NIC). Також вони запускали тести після будь-якого великого оновлення чи зміни заліза. Ті самі параметри. Такий самий runtime. Та сама політика збереження даних.

Одного кварталу результати змінилися тонко: послідовна пропускна здатність була в нормі, але p99 на випадкових записах повільно піднімався. Не критично для інциденту. Достатньо, щоб насторожитися. Оскільки були історичні базові значення, зміна була беззаперечна, а не предметом суперечки.

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

День врятував простий спредшит і послідовність. Жодних подвигів. Просто дорослий нагляд.

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

1) «pveperf каже 1500 MB/s, але ВМ повільні»

Симптом: Чудові числа pveperf, повільна інтерактивність, спайки бази даних.

Корінна причина: pveperf влучив у кеш або вимірював послідовну пропускну здатність; ваше навантаження — випадкові IO з вимогами до sync.

Виправлення: Запустіть fio з --direct=1, розмір файлу > RAM і включіть тести синхронних записів (--fsync=1). Рішайте за p99 затримкою, а не за піковим MB/s.

2) «fio показує чудові числа в понеділок, жахливі у вівторок»

Симптом: Варіативність бенчмарку, яку не можете пояснити.

Корінна причина: Фонова активність: ZFS scrub/resilver, Ceph backfill, бекапи, TRIM або термальний тротлінг SSD.

Виправлення: Фіксуйте стан системи (zpool status, ceph -s, бекап-завдання), подовжіть runtime до steady-state і перезапустіть у контрольований час.

3) «Затримка випадкових записів жахлива, але диски мало завантажені»

Симптом: iostat показує помірній %util, але fio p99 — поганий.

Корінна причина: Поведінка flush/sync, відключений write cache, поганий SLOG або мережевий джиттер, що спричиняє паузи, не відображені %util.

Виправлення: Перевірте політику кешу контролера, ZFS sync, апарат SLOG, і втрати мережі/латентність. Міряйте синхронні патерни fio.

4) «Продуктивність Ceph непослідовна і погіршується після відмов»

Симптом: IO ВМ падає під час збоїв вузлів або перезавантажень.

Корінна причина: Відновлення/backfill конкурує з клієнтським IO; мережа перенавантажена; диски OSD насичені.

Виправлення: Тестуйте лише коли active+clean. Якщо це неприйнятно оперативно — налаштуйте пріоритети відновлення, планування ємності і ізолюйте Ceph-трафік.

5) «Переход на швидші SSD не допоміг затримці бази даних»

Симптом: Краща послідовна пропускна здатність, ті самі затримки комітів.

Корінна причина: Вузьке місце в шляху sync-записів (латентність flush), плануванні CPU або конкуренції на спільному пулі.

Виправлення: Виміряйте latency синхронних записів явно; розділіть навантаження; забезпечте достатній CPU і уникайте гучних сусідів; перевірте захист від втрати живлення у шляху підтвердження запису.

6) «Тест всередині ВМ виглядає нормально; користувачі все одно скаржаться»

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

Корінна причина: Бенчмарк гостя не відповідає IO-патерну додатка; або хостова конкуренція спричиняє хвостові сплески, які середні приховують.

Виправлення: Захопіть хостові перцентилі затримок (fio на хості, iostat, zpool/ceph stats) під час скарг. Порівнюйте p95/p99, а не середні.

7) «Після увімкнення стиснення бенчмарки подвоїлися»

Симптом: Раптом величезна пропускна здатність запису, підозріло мала дискова пропускна здатність.

Корінна причина: Тестові дані добре стискаються (нули або повторювані патерни), вимірюючи CPU+стискання, а не обмеження диска.

Виправлення: Використовуйте несжимаємі дані для тестів сирого медіа (fio --buffer_compress_percentage=0 і --refill_buffers=1), або явно вказуйте, що вимірюєте ефективну продуктивність з стисненням.

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

Крок за кроком: побудуйте надійну базу тестів Proxmox

1. Визначте питання. Наприклад: «Чи витримає цей хост 4k sync-записи з p99 < 5ms для 10 ВМ?»
2. Знайдіть точний шлях сховища. Використайте pvesm status і конфігурацію дисків ВМ, щоб його знайти.
3. Перевірте здоров’я. ZFS: zpool status. Ceph: ceph -s. SMART/NVMe health за потреби.
4. Стабілізуйте середовище. Пауза scrub/backfill якщо можливо, уникайте бекапів під час запуску і задокументуйте те, що не змогли зупинити.
5. Контролюйте масштабування CPU для тесту. Тимчасово виставте governor свідомо.
6. Запустіть телеметрію паралельно. Тримайте iostat -x і або zpool iostat, або метрики Ceph.
7. Запустіть fio з direct IO і реалістичною робочою множиною. Розмір > RAM, runtime 120–300 с для SSD, довше для HDD/Ceph якщо потрібно.
8. Заархівуйте перцентилі. Фіксуйте p50/p95/p99/p99.9. Якщо інструмент їх не показує — ви літаєте сліпо.
9. Повторіть тричі. Якщо не можете повторити — не довіряйте результату.
10. Запишіть конфіг. Властивості ZFS, RAID-стек, версії прошивок, швидкості NIC, MTU, розміри реплікації Ceph.
11. Рішіть на основі SLO. Пропускна здатність для бекапів, перцентилі затримки для баз даних, змішане IO для кластерів ВМ.
12. Зберігайте результати з контекстом. Число без умов — це дрібниці.

Короткий чекліст: перед тим як звинувачувати сховище

• Чи гостя ВМ свопиться? (тиск пам’яті гостя виглядає як повільність сховища)
• Чи хост у IO wait? (vmstat)
• Чи є packet drops на мережах сховища? (ip -s link)
• Чи йде бекап/scrub/backfill? (pidstat, zpool status, ceph -s)
• Чи ви вимірюєте правильний датастор? (pvesm status)
• Чи CPU зменшив частоту? (cpupower frequency-info)

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

1) Чи варто припинити використовувати pveperf?

Ні. Використовуйте його як smoke test і підказку інвентаризації («який пристрій за цим шляхом?»). Перестаньте використовувати його як інструмент закупівлі чи прогнозу SLO продуктивності.

2) Чому pveperf покращується після першого запуску?

Кеші прогріваються. Page cache, ARC, внутрішні кеші пристроїв. Другий запуск часто «швидший», бо ви вимірюєте пам’ять і метадані, а не диски.

3) Який найкорисніший показник продуктивності сховища в Proxmox?

Затримка під навантаженням, особливо p95/p99, у кореляції з хостовою затримкою пристрою (iostat -x await) і чергуванням.

4) Де тестувати: на хості чи всередині ВМ?

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

5) Як уникнути випадкового тестування RAM?

Використовуйте fio з --direct=1, обирайте розмір тесту, більший за RAM, і підтверджуйте через zpool iostat/iostat, що пристрої справді працюють.

6) Чому послідовна пропускна здатність чудова, а база даних повільна?

Бази даних зазвичай мають багато синхронних і випадкових IO. Послідовні тести здебільшого говорять, скільки швидко пройдуть бекапи й відновлення, а не як швидко виконається коміт.

7) Чи іноді варто вмикати ZFS sync=disabled?

Може бути прийнятним для некритичних, відновлюваних робочих навантажень, де стійкість не потрібна. Для баз даних і важливих дисків ВМ — це звичайно ризик, що потребує письмового обґрунтування і плану відкату.

8) Який runtime повинен бути у fio?

Достатній, щоб досягнути steady state: часто 120–300 секунд для SSD-тестів, довше для HDD-масивів і розподіленого сховища. Якщо SSD має великий SLC-кеш — 30 секундний тест — це маркетингове шоу.

9) Як справедливо тестувати Ceph?

Тестуйте лише коли HEALTH_OK і PGs active+clean, ізолюйте Ceph-трафік на надійній мережі, і тестуйте як на шарі RADOS (rados bench), так і на шарі VM/RBD (fio на RBD-backed сховищі).

10) Мої числа fio менші за pveperf. Які вірні?

Зазвичай fio, якщо ви налаштували його правильно (direct IO, реалістичний розмір, правильний шлях, відповідна модель sync). pveperf часто вимірює іншу, простішу проблему.

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

Якщо pveperf «виглядає чудово», а користувачі скаржаться — повірте користувачам. Потім доведіть це вимірами, які моделюють ваше навантаження.

1. Запустіть швидкий план діагностики, щоб визначити, чи ви CPU-, диск- чи мережо-обмежені.
2. Тестуйте fio на реальному датасторі з direct IO, реалістичними розмірами робочої множини і перцентилями.
3. Для ZFS тестуйте синхронні записи явно і перевіряйте властивості pool/dataset. Не плутайте послідовну пропускну здатність зі стійкістю.
4. Для Ceph тестуйте лише коли здоровий і вважайте якість мережі частиною продуктивності сховища.
5. Зберігайте результати з контекстом і повторюйте після змін. Нудна база — це як виявляти регресії до того, як вони розбудять вас серед ночі.

Правильне тестування не дає одного магічного числа. Воно дає карту обмежень — і спосіб припинити сперечатися з графіками, які ніколи не мали тягнути продакшен.