ZFS zpool iostat -w: як у реальному часі розпізнати шаблони навантаження

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

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

Вам не потрібна панель моніторингу, щоб зрозуміти, що сховище страждає. Достатньо одного сердитого тайм-ауту API, однієї гілки в Slack «чому деплой завис?»
і одного керівника, який каже «але вчора ж працювало». ZFS дає правдивий інструмент: zpool iostat -w.

Правильно використаний, він скаже, чи ви обмежені CPU, IOPS, латентністю, синхронними записами або просто «обмежені оптимізмом».
Неправильно використаний — змусить купити непотрібне залізо, крутити регулятори, яких не розумієте, і звинувачувати «мережу» за звичкою.

Що насправді показує `-w` (і чому це має значення)

zpool iostat — це монітор серцебиття. Прапорець -w додає те, чого ви зазвичай хотіли б під час інциденту: затримку.
Не теоретичну затримку. Не затримку з даташиту вендора. Фактичну затримку, яку бачить ZFS для операцій пулу та vdev.

Якщо ви працюєте з продакшеном, ставтеся до zpool iostat -w як до інструмента «чи є зараз сховище вузьким місцем?».
Він відповідає на такі питання:

Чи накопичуються запити в черзі? Затримка зростає раніше, ніж пропускна здатність падає.
Де біль? На рівні пулу, один повільний vdev чи лише одна ланка дзеркала.
Який тип болю? Читання, записи, синхронні записи, операції з метаданими, resilver, trim або «маленькі випадкові все підряд».

Затримка — це валюта, якою платять додатки. Пропускну здатність хваляться команди зберігання. Коли приходить платіж, додатки платять затримкою.

Що додає `-w` і чого не додає

Точні стовпці залежать від реалізації та версії ZFS (OpenZFS на Linux vs FreeBSD vs illumos). Але загалом:

Він додає стовпці затримки (часто окремо для читань і записів).
Може додавати час черги або «wait» залежно від платформи.
Він не розділяє автоматично затримку наміру ZFS і затримку пристрою, якщо ви про це не попросите (далі про це буде більше).
Він не каже, чому висока затримка; він показує, куди копати далі.

Суха істина: zpool iostat може зробити вашу систему «здоровою» в звітах, поки додаток горить, бо ARC кеш тихо рятує ситуацію.
Потім промахи кеша зростають і той самий пул падає під навантаженням справжніх зчитувань з диска. Потрібно спостерігати безперервно, а не лише коли все вже пропало.

Коротка історія та факти, що роблять вивід зрозумілішим

Декілька контекстних фактів перетворюють «стовпці цифр» на історію, з якою можна працювати. Ось дев’ять коротких фактів, що дійсно важать.

ZFS народився в Sun Microsystems (середина 2000-х) як стек кінця в кінець: файловa система + менеджер томів з контрольними сумами повсюди.
Ідея «пулу» — це ключова інновація: файлові системи живуть зверху пулу, і пул вирішує, де блоки лежать по vdev.
Copy-on-write (CoW) — причина іншої поведінки фрагментації: ZFS не перезаписує блоки на місці; він записує нові блоки і оновлює вказівники.
ZIL — це не кеш записів: це журнал для синхронних записів. Він існує навіть без виділеного SLOG-пристрою.
SLOG — це пристрій, ZIL — концепція: додавання SLOG переміщує ZIL на швидший носій, але лише для синхронних записів.
OpenZFS об’єднав різні форки, тому функції як видалення пристрою, спеціальні vdev та постійний L2ARC стали більш поширеними між платформами.
Ashift — назавжди (переважно): якщо вказали неправильно при створенні пулу, ви несете цей штраф продуктивності на весь час життя vdev.
«IOPS» — напівправда без затримки: можна гонити великі IOPS із жахливою хвостовою латентністю; база даних все одно вас вб’є.
Resilver і scrub — це навмисний біль: це фонові читання/записи, які можуть домінувати в zpool iostat, якщо їм дозволити.

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

Ментальна модель для продакшену: від запиту додатку до vdev

Коли додаток виконує I/O на ZFS, ви спостерігаєте, як декілька шарів домовляються з реальністю:

Додаток робить читання/записи (часто маленькі, часто випадкові, і буває образливі).
OS і ZFS агрегують, кешують (ARC) і іноді переставляють в порядку.
ZFS транслює логічні блоки в фізичні записи по vdev, дотримуючись правил надмірності й алокації.
Ваші vdev перетворюють це на реальні команди пристрою. Найповільніший релевантний компонент задає темп.

Пул vs vdev: чому ваші «швидкі диски» все одно можуть бути повільними

Продуктивність ZFS зорієнтована на vdev. Пул — це набір vdev. Пропускна здатність пулу масштабується кількістю vdev, а не кількістю дисків,
як люди наївно припускають.

Дзеркала дають більше IOPS на vdev, ніж RAIDZ, і кілька дзеркал масштабується. RAIDZ vdev відмінні для щільності і великих послідовних читань,
але вони не перетворюються автоматично в IOPS-монстрів. Якщо ви зробили один гігантський RAIDZ2 vdev з купою дисків і очікували базу даних з випадковим I/O —
ви купили мінівен і виставили його на дрег-рейсинг.

Затримка — це стек: час обслуговування + час очікування

Найкорисніший спосіб інтерпретувати -w: «пристрій повільний» проти «пристрій зайнятий».
Висока затримка при помірній завантаженості часто означає, що пристрій сам по собі повільний (або виходить з ладу, або робить внутрішній GC).
Висока затримка при високих IOPS/пропускній здатності зазвичай означає черги: навантаження перевищує те, що vdev може обслуговувати прийнятною латентністю.

Як читати стовпці чесно

Ви побачите варіанти як:

capacity: використано, вільно, фрагментація і іноді розподілене місце по пулу/vdev.
operations: операції читання/запису в секунду (IOPS).
bandwidth: байти в секунду для читання/запису (пропускна здатність).
latency: затримка читання/запису, іноді розбита на «wait» і «service».

Правило: діагностуєте комбінацією IOPS, bandwidth і latency. Один показник сам по собі — брехун.

Лінії на рівні пулу — це середні; лінії vdev — правда

Статистика пулу може приховати один хворий диск у дзеркалі або один повільний RAIDZ vdev, що тягне все за собою.
Завжди використовуйте -v, щоб бачити розбивку по vdev при діагностиці.

Спостерігайте за змінами, а не за абсолютними числами

zpool iostat найкраще використовувати як часовий ряд. Запускайте з інтервалом 1 або 2 секунди і відстежуйте тренди.
«Зараз» важить більше, ніж середні за весь час.

Жарт №1: Графіки сховищ як гороскопи — невизначені, доки не спрацює пейджер, і тоді раптом «вочевидь передбачувані».

Швидкий план діагностики

Це послідовність, яку я використовую, коли команда додатку каже «сховище повільне» і у вас 90 секунд, щоб вирішити, чи це правда.

Перше: визначте, чи дивитесь ви на диск чи на кеш

Запустіть zpool iostat -w з інтервалом 1 с протягом 10–20 секунд.
Якщо IOPS і пропускна здатність читань низькі, але додаток повільний — підозрюйте CPU, блокування, мережу або промахи кеша, що ще не дійшли до диска.
Якщо IOPS читань різко зростають і затримка з ними зростає, проблема на дисках. Це вже реальна справа.

Друге: ізолюйте шар вузького місця

Використайте zpool iostat -w -v. Знайдіть vdev з найгіршою затримкою або найвищими симптомами завантаження.
Якщо це один диск у дзеркалі: ймовірно, він виходить з ладу, проблеми з прошивкою або з шляхом.
Якщо це весь RAIDZ vdev: ви наситили IOPS цього vdev. Виправлення архітектурне (більше vdev, дзеркала або прийняти затримку).

Третє: вирішіть, чи це біль від синхронних записів

Шукайте сплески затримки записів, що корелюють з високими дрібними write IOPS і низькою пропускною здатністю.
Перевірте, чи навантаження примушує синхронні записи (бази даних, NFS, гіпервізори).
Якщо так: перевірте здоров’я SLOG і затримку пристрою; розгляньте, чи ваші налаштування sync відповідають допустимому ризику.

Четверте: перевірте «фонові роботи, що удають трафік»

Scrub, resilver, trims і важкі snapshot/clone можуть домінувати над I/O.
Якщо zpool status показує активну роботу, вирішіть, чи її обмежити, перепланувати або дати завершитись.

П’яте: підтвердіть другим сигналом

Корелюйте з CPU (mpstat), тиском пам’яті або по-процесним I/O (pidstat).
Використовуйте інструменти на рівні пристрою (iostat -x), щоб побачити, чи один NVMe «плавиться», поки ZFS усереднює всі дані.

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

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

Завдання 1: Базова перевірка затримки пулу в реальному часі

cr0x@server:~$ sudo zpool iostat -w tank 1
              capacity     operations     bandwidth    latency
pool        alloc   free   read  write   read  write   read  write
----------  -----  -----  -----  -----  -----  -----  -----  -----
tank        3.21T  7.58T    210    180  18.2M  22.4M   2ms   4ms
tank        3.21T  7.58T    195    260  16.9M  31.1M   3ms  18ms
tank        3.21T  7.58T    220    240  19.1M  29.7M   2ms  20ms

Значення: Затримка записів стрибнула з 4ms до ~20ms при збільшенні пропускної здатності. Класичний випадок «ми тиснемо шлях запису».

Рішення: Якщо це корелює з затримкою для користувачів, вважайте сховище підозрілим. Далі: додайте -v, щоб знайти проблемний vdev.

Завдання 2: Знайти vdev, що завдає шкоди

cr0x@server:~$ sudo zpool iostat -w -v tank 1
                                            operations     bandwidth    latency
pool        vdev                             read  write   read  write   read  write
----------  -------------------------------- ----  -----  -----  -----  -----  -----
tank        -                                  220    240  19.1M  29.7M   2ms  20ms
tank        mirror-0                           110    120   9.5M  14.6M   2ms  10ms
tank          nvme0n1                          108    118   9.4M  14.4M   2ms  12ms
tank          nvme1n1                          112    119   9.6M  14.7M   2ms  65ms
tank        mirror-1                           110    120   9.6M  15.1M   2ms  10ms
tank          nvme2n1                          110    118   9.5M  14.8M   2ms  11ms
tank          nvme3n1                          110    121   9.7M  15.3M   2ms  10ms

Значення: Одна ланка дзеркала (nvme1n1) має 65ms записової латентності, тоді як її партнер у нормі. ZFS може робити читання з дзеркала, але записи чекають обох ланок.

Рішення: Це проблема пристрою/шляху. Перевірте SMART, прошивку, помилки PCIe, multipath і швидкість лінку. Замініть або виправте шлях перед тим, як крутити ZFS.

Завдання 3: Відокремити «зайнятий» від «поламаного» на рівні пристрою

cr0x@server:~$ iostat -x 1 3
Linux 6.5.0 (server)  12/25/2025  _x86_64_  (32 CPU)

Device            r/s     w/s   rMB/s   wMB/s  avgrq-sz  avgqu-sz   await  r_await  w_await  svctm  %util
nvme0n1         110.0   120.0     9.5    14.4     197.0      0.4     3.1      2.0      4.2    0.4   18.0
nvme1n1         112.0   119.0     9.6    14.7     198.2      9.8    66.7      2.2     65.8    0.5   95.0

Значення: nvme1n1 на високому %util з глибокою чергою і величезним write await. Це не «балакучість» ZFS; це хворий або обмежений пристрій.

Рішення: Перестаньте звинувачувати recordsize. Дослідіть здоров’я пристрою та тротлінг (термічний, GC прошивки). Якщо це спільна PCIe шина, виправте топологію.

Завдання 4: Швидко виявити навантаження синхронних записів

cr0x@server:~$ sudo zpool iostat -w tank 1
              operations     bandwidth    latency
pool        read  write   read  write   read  write
----------  ----  -----  -----  -----  -----  -----
tank          80   3200   6.1M  11.8M   1ms  35ms
tank          75   3500   5.9M  12.4M   1ms  42ms

Значення: Дуже високі write IOPS при низькій write пропускній здатності означає дрібні записи. Затримка висока. Якщо додаток — база даних, хост VM або NFS, припускайте sync-навантаження.

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

Завдання 5: Перевірити, чи датасети примушують sync-поведінку

cr0x@server:~$ sudo zfs get -o name,property,value -s local,received sync tank
NAME   PROPERTY  VALUE
tank   sync      standard

Значення: Пул/датасети використовують стандартну семантику: виконують запити додатків на sync.

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

Завдання 6: Перевірити, чи є у вас SLOG і чи він здоровий

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
config:

        NAME          STATE     READ WRITE CKSUM
        tank          ONLINE       0     0     0
          mirror-0    ONLINE       0     0     0
            nvme0n1   ONLINE       0     0     0
            nvme1n1   ONLINE       0     0     0
          mirror-1    ONLINE       0     0     0
            nvme2n1   ONLINE       0     0     0
            nvme3n1   ONLINE       0     0     0
        logs
          mirror-2    ONLINE       0     0     0
            nvme4n1   ONLINE       0     0     0
            nvme5n1   ONLINE       0     0     0

Значення: Є дзеркальний SLOG. Добре: одинарний пристрій SLOG — це підступ, якщо вам важлива довговічність.

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

Завдання 7: Виміряти поведінку по vdev під час scrub або resilver

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Thu Dec 25 10:11:03 2025
        1.23T scanned at 1.1G/s, 512G issued at 450M/s, 3.21T total
        0B repaired, 15.9% done, 01:42:18 to go

cr0x@server:~$ sudo zpool iostat -w -v tank 1
                                            operations     bandwidth    latency
pool        vdev                             read  write   read  write   read  write
----------  -------------------------------- ----  -----  -----  -----  -----  -----
tank        -                                 6200    180  1.05G  22.4M  12ms   4ms
tank        mirror-0                          3100     90  525M  11.2M  13ms   4ms
tank        mirror-1                          3100     90  525M  11.2M  12ms   4ms

Значення: Читання домінують через scrub. Затримка підвищена, але пояснювана. Записи виглядають нормально.

Рішення: Якщо це активний продакшен-інтервал, обмежте scrub (залежить від платформи) або перенесіть на інший час. Якщо ваші SLO руйнує читальна латентність, планування scrub — завдання SRE, не тільки сховища.

Завдання 8: Ідентифікувати один повільний диск у дзеркалі без гадань

cr0x@server:~$ sudo zpool iostat -w -v tank 1
                                            operations     bandwidth    latency
pool        vdev                             read  write   read  write   read  write
----------  -------------------------------- ----  -----  -----  -----  -----  -----
tank        mirror-0                           800    900  65M   72M     3ms  14ms
tank          sda                              400    450  32M   36M     2ms   6ms
tank          sdb                              400    450  33M   36M     3ms  80ms

Значення: sdb — анкер, що тягне човен. Дзеркала записують на обидві сторони; одна повільна ланка отруює латентність запису.

Рішення: Витягніть SMART-дані, перевірте кабелі/HBA і плануйте заміну. Не «тюньте» систему навколо помираючого диска.

Завдання 9: Підтвердити ashift і чому це важливо

cr0x@server:~$ sudo zdb -C tank | grep -E "ashift|vdev_tree" -n
45:        ashift: 12

Значення: ashift=12 (4K сектора). Це зазвичай розумний вибір для сучасних дисків і SSD. Якщо бачите ashift=9 на 4K-native носіях — ви платите податок на write amplification назавжди.

Рішення: Якщо ashift неправильний, ви не «виправляєте» це sysctl. Потрібно мігрувати на новий vdev/pool з правильним ashift.

Завдання 10: Виявити біль, спричинений метаданими, і розглянути спеціальний vdev

cr0x@server:~$ sudo zpool iostat -w -v tank 1
                                            operations     bandwidth    latency
pool        vdev                             read  write   read  write   read  write
----------  -------------------------------- ----  -----  -----  -----  -----  -----
tank        -                                 5200   2100  48M   39M    18ms  22ms
tank        raidz2-0                           5200   2100  48M   39M    18ms  22ms

Значення: Величезні IOPS при маленькій пропускній здатності — ознака метаданих або дрібного блокового випадкового I/O (огляди директорій, маленькі файли, maildirs, шари контейнерів).
RAIDZ цьому не радіє.

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

Завдання 11: Перевірити recordsize датасету стосовно навантаження

cr0x@server:~$ sudo zfs get -o name,property,value recordsize tank/db
NAME     PROPERTY    VALUE
tank/db  recordsize  128K

Значення: 128K recordsize підходить для великих послідовних I/O, але багато баз даних віддають перевагу меншим (наприклад 16K) залежно від двигуна і розміру сторінки.

Рішення: Якщо навантаження — випадкові операції з маленькими сторінками і ви бачите read amplification, протестуйте менший recordsize для цього датасету.
Не змінюйте recordsize сліпо для існуючого датасету і не чекайте миттєвого дива; існуючі блоки залишаться такими, якими були.

Завдання 12: Перевірити стиснення і зрозуміти, чи ви CPU-bound

cr0x@server:~$ sudo zfs get -o name,property,value compression,compressratio tank/vm
NAME      PROPERTY       VALUE
tank/vm   compression    zstd
tank/vm   compressratio  1.62x

cr0x@server:~$ mpstat 1 3
Linux 6.5.0 (server)  12/25/2025  _x86_64_  (32 CPU)

12:11:01 AM  all   %usr  %nice   %sys %iowait  %irq  %soft  %steal  %idle
12:11:02 AM  all   72.0    0.0   11.0     2.0   0.0    0.0     0.0   15.0

Значення: Стиснення активне і ефективне. CPU досить зайнятий. Якщо zpool iostat показує низьку активність диска, але додаткова затримка є — CPU може бути обмежуючим фактором.

Рішення: Якщо насичення CPU корелює з I/O латентністю, розгляньте зміну рівня стиснення (але зберігайте стиснення), додайте CPU або ізолюйте галасливі сусідні процеси.
Не вимикайте стиснення як перший рефлекс; воно часто зменшує дисковий I/O.

Завдання 13: Помітити вплив TRIM/autotrim і вирішити, коли його запускати

cr0x@server:~$ sudo zpool get autotrim tank
NAME  PROPERTY  VALUE     SOURCE
tank  autotrim  on        local

cr0x@server:~$ sudo zpool iostat -w tank 1
              operations     bandwidth    latency
pool        read  write   read  write   read  write
----------  ----  -----  -----  -----  -----  -----
tank         180    220  12.4M  19.1M   2ms   6ms
tank         175    240  12.2M  19.8M   3ms  18ms

Значення: Якщо ви бачите періодичні сплески write-латентності без відповідних змін навантаження, фонові роботи (включно з TRIM на деяких пристроях) можуть бути причиною.

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

Завдання 14: Корелювати «хто робить I/O» з симптомами пулу

cr0x@server:~$ pidstat -d 1 5
Linux 6.5.0 (server)  12/25/2025  _x86_64_  (32 CPU)

12:12:01 AM   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  Command
12:12:02 AM     0      2211      120.0   82000.0      0.0       1  postgres
12:12:02 AM     0      3440      200.0   14000.0      0.0       0  qemu-system-x86

Значення: Postgres шмагає записи. Якщо zpool iostat -w показує високу write-латентність, тепер ви можете вести продуктивну розмову з власником бази даних.

Рішення: Визначте, чи це реальне збільшення навантаження (масштабуйте сховище), помилка конфігурації додатка (fsync-цикл) або операційна робота (vacuum, reindex), що потребує планування.

Розпізнавання шаблонів навантаження в реальному світі

Уся суть zpool iostat -w — швидко розпізнати шаблони, щоб діяти. Ось поширені, що з’являються в реальних системах.

Шаблон: дрібні випадкові записи, високі IOPS, низька пропускна здатність, висока затримка

Виглядає як: тисячі операцій записів, кілька MB/s, затримка записів десятки мілісекунд або гірше.

Зазвичай це: тиск WAL/fsync бази даних, журналювання VM, синхронні NFS записи, навантаження з великим обсягом логів.

Що робити:

Підтвердити, чи записи синхронні (датасет sync і поведінка додатку).
Переконатися, що SLOG присутній, швидкий і має захист від втрати живлення, якщо ви дбаєте про довговічність.
Не ставте дешевий споживчий SSD як SLOG і вважайте проблему вирішеною. Так ви купуєте втрату даних з чек-листом.

Шаблон: висока пропускна здатність читань, помірні IOPS, зростаюча латентність читань

Виглядає як: сотні MB/s до GB/s читань, латентність зростає від кількох ms до десятків ms.

Зазвичай це: стрімінгові читання під час бекапу, аналітичні скани, scrub або шторм промахів кеша.

Що робити:

Перевірити статус scrub/resilver.
Перевірити ARC hit ratio опосередковано, дивлячись, чи взагалі читання доходять до диска (пара з ARC-метриками, якщо доступні).
Якщо це реальний користувацький трафік, можливо потрібні додаткові vdev або швидший носій. Латентність не торгується.

Шаблон: один vdev показує високу латентність; середнє по пулу «окей»

Виглядає як: рядок пулу у zpool iostat -w здається нормальною; -v показує одне дзеркало або диск з в 10–100 разів більшою латентністю.

Зазвичай це: збій диска, поганий кабель, HBA reset storms, термічний тротлінг або баг прошивки.

Що робити: ставтеся до цього як до апаратного питання, поки не доведено інакше. Замініть. Не марнуйте тиждень на оптимізації під диск, що тихо помирає.

Шаблон: сплески латентності при стабільній пропускній здатності

Виглядає як: ті самі MB/s і IOPS, але латентність періодично різко зростає.

Зазвичай це: GC пристрою, TRIM, flush кешу запису або конкуренція на спільних ресурсах (PCIe лінії, HBA, віртуалізований хост).

Що робити: корелюйте з метриками на рівні пристрою та системними логами. Якщо це NVMe термічний тротлінг, «фікс» може бути вентиляція, а не софт.

Жарт №2: Якщо ваші «сплески латентності випадкові», вітаю — ви створили розподіл ймовірностей у продакшені.

Три корпоративні міні-історії (бо реальність жорстока)

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

Середня SaaS-компанія мігрувала зайнятий кластер Postgres з старого SAN на локальні NVMe з дзеркалами ZFS. Команда святкувала:
бенчмарки виглядали чудово, середня латентність була низька, і графіки сховища перестали виглядати як місце злочину.

Через два тижні інцидент: періодичні зависання записів 2–5 секунд на навантажених ендпоінтах. Не постійні. Непередбачувані.
Команда додатку звинуватила блокування. DBA — autovacuum. SRE — «можливо ядро».
У кожного був улюблений лиходій, але це не були диски.

Хтось нарешті запустив zpool iostat -w -v 1 під час зависання. Середні значення пулу були нормальні, але один NVMe показував write-латентність у сотні мілісекунд.
Він не відмовив повністю. Він періодично тротлився.

Помилкове припущення: «NVMe завжди швидке, і якщо повільне — значить ZFS». Реальність: споживчі NVMe можуть сягати термічних меж і різко падати в продуктивності
під тривалими синхронно-подібними записами. Коробка мала чудовий CPU і жахливий повітрообмін.

Рішення було нудно правильним: покращити охолодження, оновити прошивку і замінити модель на enterprise у наступному вікні обслуговування.
Налаштування ZFS б не допомогли. Перегляд латентності по пристрою з -w -v вирішив проблему.

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

Корпоративна платформа тримала мульти-орендну кластерну віртуалізацію на великому RAIDZ2 пулі. Розробники хотіли швидше CI,
і сховище було «річчю, на яку всі жаліються».

Хтось запропонував швидку перемогу: поставити sync=disabled на датасеті VM. Аргумент звучав привабливо: «У нас є UPS. Гіпервізор відновить.
І це лише дев навантаження». Змінювали пізно ввечері і дивилися, як zpool iostat показує зниження write-латентності. Усі плескали в долоні.

Потім стався відкат. Хост впав у спосіб, який UPS не захистив (проблема з материнською платою, а не відключення живлення).
Кілька VM отримали пошкодження файлової системи. Не всі. Достатньо, щоб зіпсувати вихідні і зробити постмортем гострим.

Операційна помилка не в тому, що «sync=disabled завжди погано». Помилка — трактувати семантику довговічності як ручку продуктивності без моделювання префекту впливу.
Вони оптимізували медіану і заплатили за хвостовий ризик.

Довгострокове рішення: знову ввімкнули sync=standard, додали дзеркальний SLOG з PLP і сегментували «реальний дев» від «псевдо-продакшену»,
щоб рішення щодо довговічності відповідало бізнес-реальності. Урок: zpool iostat -w покаже, що sync-записи болючі,
але не дає дозволу їх відключати.

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

Фінансова компанія тримала ZFS для файлових сервісів і артефактів збірок. Нічого надзвичайного. Тип сховища, що ніколи не отримує увагу, поки не зламається.
Інженер зі сховищ мав одну звичку: щотижневий «п’ятихвилинний дрил» у робочий час.
Запустити zpool iostat -w -v 1 на хвилину, подивитися латентності, перевірити zpool status і йти далі.

Одного вівторка дрил показав ланку дзеркала зі стабільним зростанням write-латентності. Помилок ще не було. Алертів — також.
Але тренд латентності був неправильний, як звук коробки передач до катастрофи.

Вони витягли SMART-дані і знайшли зростаючі помилки медіа. Диск не був мертвий; він почав брехати.
Запланували заміну на наступному вікні, зробили resilver і ніколи не мали аварії.

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

Нудна практика — не героїзм. Це визнання того, що диски рідко йдуть від «ідеально» до «мертвий» без фази «дивний».
zpool iostat -w чудово ловить дивне.

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

Це типові режими відмов, які я бачу в організаціях. Трюк — зіставити симптом у zpool iostat -w з ймовірною причиною,
а потім зробити конкретну зміну, яку можна перевірити.

1) Затримка запису пулу висока, але лише одна ланка дзеркала повільна

Симптом: Сплески write-латентності пулу; -v показує один пристрій із значно вищою write-латентністю.
Корінь: Тротлінг пристрою, GC прошивки, термічні проблеми, поганий лінк або диск, що виходить з ладу.
Виправлення: Перевірити iostat -x і логи; замінити пристрій або виправити шлях. Не марнуйте час на tuning recordsize або ARC.

2) Високі write IOPS, низька write пропускна здатність, погана write-латентність

Симптом: Тисячі записів/с, лише кілька MB/s, write-латентність десятки ms до секунд.
Корінь: Синхронні записи без швидкого SLOG або повільний SLOG.
Виправлення: Додати/замінити дзеркальний PLP SLOG; підтвердити поведінку додатка щодо sync; ізолювати датасети і свідомо налаштувати sync-семантику.

3) Читання в нормі, поки не стрибнуть пропуски ARC, і тоді все тане

Симптом: Зазвичай низькі дискові читання; під час інциденту read IOPS/bandwidth стрибають і read-латентність зростає.
Корінь: Робочий набір перевищив ARC або зміна патерну доступу (скан, звіт, бекап, нова функція).
Виправлення: Додати RAM (часто найкращий ROI), переглянути стратегію кешування або ізолювати роботи зі сканами. Підтверджуйте зміни спостереженнями у zpool iostat -w.

4) RAIDZ vdev насичується на метаданих/малому випадковому I/O

Симптом: Високі IOPS, низький MB/s, висока латентність; vdev — RAIDZ.
Корінь: Накладні витрати паритету RAIDZ і обмежена кількість IOPS на vdev для дрібних випадкових записів.
Виправлення: Додати більше vdev (не додавати дисків в той самий vdev), або перейти на дзеркала для чутливих до латентності випадкових I/O. Розглянути спеціальний vdev для метаданих, якщо доречно.

5) «Ми поміняли диски, але все ще повільно»

Симптом: Нові SSD, схожа латентність під навантаженням.
Корінь: Ви CPU-bound (стискання/чексуми), або обмежені однією vdev-структурою, або топологія PCIe/HBA чинить обмеження.
Виправлення: Підтвердіть через метрики CPU і по-vdev статистику; масштабувати кількість vdev, виправити топологію або перемістити «гарячі» датасети в окремий пул.

6) Сплески латентності під час scrub/resilver, і користувачі скаржаться

Симптом: Read-латентність різко зростає під час виконання технічного обслуговування.
Корінь: Scrub/resilver конкурує з продакшен-навант

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

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

Чекліст: відповісти на «сховище повільне» за менше п’яти хвилин

Запустіть sudo zpool iostat -w -v tank 1 і подивіться 10–20 рядків.
Визначте, чи домінують читання або записи, і чи росте латентність з навантаженням.
Якщо один пристрій виділяється — переключіться на iostat -x і системні логи для цього пристрою.
Перевірте sudo zpool status tank на предмет scrub/resilver.
Перевірте налаштування датасету sync для відповідного навантаження.
Корелюйте з по-процесним I/O (pidstat -d), щоб ви не діагностували примар.
Робіть одну зміну за раз; підтверджуйте вплив тим самим zpool iostat -w видом.

Чекліст: побудувати базу перед тим, як щось чіпати

Зробіть знімок zpool iostat -w -v 2 30 у період відсутності проблем.
Зафіксуйте ті самі дані під час пікового трафіку.
Збережіть виводи з часовими мітками у вашому журналі інцидентів або тікеті.
Запишіть конфігурацію пулу: типи vdev, моделі дисків, ashift.
Запишіть властивості датасетів: recordsize, compression, sync, atime.
Визначте, що для вас «погано» (пороги латентності, узгоджені з SLO додатку).

Покроковий план: перетворення спостережень у проєкт покращення

Класифікуйте навантаження: випадкове vs послідовне, читання vs запис, sync vs async, метадані vs великі блоки.
Зіставте з дизайном ZFS: визначте, чи ваша vdev-конфігурація відповідає навантаженню.
Виправте коректність першою: замініть погані пристрої, виправте кабелі/HBA, забезпечте надлишковість для SLOG/спеціальних vdev.
Зменшіть уникненний I/O: увімкніть розумне стиснення, налаштуйте recordsize по датасетах, розгляньте atime=off де доречно.
Масштабуйте правильно: додавайте vdev для масштабування IOPS; не роздувайте один RAIDZ vdev і не чекайте дива.
Валідуйте за допомогою -w: вам потрібна нижча латентність при тому ж навантаженні, а не просто кращі числа пропускної здатності.
Операціоналізуйте: додайте регулярні перевірки і алерти на аномалії латентності по vdev, а не лише на ємність.

FAQ

1) Що саме вимірює `zpool iostat -w` для затримки?

Воно повідомляє спостережувану затримку для I/O ZFS на рівні пулу/vdev, як її рахує ZFS. Це не ідеальна заміна для метрик прошивки пристрою,
але дуже добре показує, куди йде час і чи відбувається чергування.

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

Бо диски можуть бути не вузьким місцем. Ви можете бути CPU-bound (стиснення, чексуми), блочно-заблоковані або мати поведінку додатку, що змушує fsync.
Також ARC може маскувати читання до того, як промахи кеша стрибнуть. Корелюйте з CPU і по-процесним I/O.

3) Чи завжди запускати з `-v`?

Для діагностики — так. Середні пулу приховують повільні пристрої і нерівномірне навантаження по vdev. Для швидкої проби на зайнятій системі почніть без -v, а потім переключіться.

4) Чи збільшує додавання дисків до RAIDZ IOPS?

Не так, як більшість людей очікує. Це може збільшити послідовну пропускну здатність, але дрібне випадкове I/O обмежено накладними витратами паритету і поведінкою vdev.
Якщо вам потрібно більше IOPS — додайте vdev або використовуйте дзеркала для гарячих даних.

5) Коли SLOG виправданий?

Коли у вас значне навантаження синхронних записів і ви дбаєте про семантику довговічності (sync=standard).
Без тиску на sync SLOG часто нічого помітного не дає. При sync-навантаженні він може бути різницею між «все ок» і «чому все таймаутиться?»

6) Чи можна використовувати споживчий SSD як SLOG?

Можна, але не варто, якщо ви дбаєте про коректність. Хороший SLOG потребує низької латентності під тривалими sync-записами і захисту від втрати живлення.
Дешеві SSD можуть «брехати» про flush і різко падати у продуктивності під саме тим навантаженням, для якого ви їх купили.

7) Чому бачу високу латентність під час scrub, навіть коли користувацький трафік низький?

Scrub читає багато даних і може піднімати черги vdev. Навіть при низькому трафіку додатку, scrub — реальний I/O.
Виправлення — розклад, обмеження швидкості (де доступно) або забезпечення достатнього запасу продуктивності.

8) Чи прийнятне `sync=disabled`?

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

9) Чому write-латентність зростає, навіть коли write-пропускна здатність стала?

Бо черги і внутрішня поведінка пристрою мають значення. Постійний through-put може накопичувати backlog, якщо час обслуговування пристрою зростає через GC,
термічний тротлінг, flush кешу або конкуренцію.

10) Скільки часу треба знімати з `zpool iostat -w`?

Для триажу інциденту зазвичай достатньо 10–30 секунд з інтервалом 1 с, щоб виявити вузьке місце. Для планування ємності або роботи з продуктивністю захопіть кілька вікон:
спокійний, піковий і «поганий день».

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

zpool iostat -w — не звітний інструмент. Це двигун для прийняття рішень. Він підкаже, чи проблема пристрою, дизайну, синхронних записів
або «фонова робота їсть мені обід» — поки система жива і поводиться неправильно.

Практичні наступні кроки:

У спокійний період зробіть baseline: sudo zpool iostat -w -v tank 2 30.
Запишіть, як виглядає «нормальна» латентність по vdev і по робочих вікнах.
Коли настане наступна скарга — виконайте швидкий план діагностики і стримайте бажання почати тюнінг перш ніж з’ясувати причину.
Якщо знайдете повторюваний шаблон (sync write pressure, один повільний пристрій, RAIDZ metadata pain) — перетворіть його на інженерний проєкт з вимірюваними результатами.

Вашому майбутньому собі не потрібно більше графіків. Потрібно менше сюрпризів. -w — це як почати нараховувати відсотки за хаос.