ZFS logbias: Затримка проти пропускної здатності — оберіть те, що дійсно потрібно

November 19, 2025 • February 3, 2026 • Читання: 5 хв • Views: 5

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

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

Якщо ви запускаєте бази даних, сховище для віртуальних машин, NFS-експорти або будь-що, що використовує fsync() як основну операцію, ваше реальне запитання не «Наскільки швидкий ZFS?» Воно звучить: «Що я хочу: меншу затримку на кожен синхронний запис, чи більше пропускної здатності в часі?» logbias — це місце, де ви кажете ZFS, чого ви справді потребуєте — а не те, чого сподіваєтесь.

Що таке `logbias` насправді (і чим воно не є)

logbias — це властивість на рівні набору даних (або на рівні zvol), яка впливає на те, як ZFS обробляє синхронні записи: чи повинен він віддавати перевагу шляху ZFS Intent Log (ZIL) для низької затримки підтвердження, чи схилятися до відправки даних безпосередньо в основний пул для кращої загальної пропускної здатності.

Практично важливі два значення:

logbias=latency (за замовчуванням): пріоритезувати низьку затримку для синхронних записів; агресивно використовувати шлях ZIL/SLOG.
logbias=throughput: намагатись уникати схем «подвійного запису» і зменшити залежність від лог-пристрою для великих синхронних записів; більше штовхати дані в основний пул, коли це доцільно.

Чим воно не є:

Не чарівний перемикач «зроби мій пул швидким». Якщо ваш пул перевантажений або має жахливу випадкову поведінку записів, logbias цього не виправить.
Не те саме, що sync=disabled. logbias не змінює семантики коректності. sync=disabled змінює.
Не заміна для належного SLOG-пристрою (якщо ваш навантаження його потребує), і не заміна для правильного вибору розміру записів або налаштування бази даних.

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

Жарт №1: Встановлювати logbias=throughput без вимірювань — це як «оптимізувати» нараду, прибравши порядок денний: технічно швидше, духовно катастрофічно.

Практична ментальна модель: ZIL, SLOG, TXGs

Якщо ви довго працюєте з ZFS, то напевно чули ці абревіатури так, ніби вони самоочевидні. Це не так. Зробімо їх корисними.

ZIL: журнал намірів, завжди присутній

ZFS Intent Log (ZIL) існує для однієї задачі: забезпечити безпечне підтвердження синхронних записів ZFS. Коли застосунок виконує синхронний запис (або викликає fsync()), ZFS має зафіксувати достатньо інформації на стійкому носії, щоб після збою можна було відтворити операції і зберегти гарантії на рівні застосунку.

Важливо: ZIL не є кешем для всього підряд. Це журнал останніх синхронних транзакцій, і він використовується тільки для відновлення після некоректного завершення. За нормальної роботи дані зрештою потрапляють в основний пул під час комітів транзакційних груп (TXG).

SLOG: окремий пристрій для ZIL, опціональний але потужний

SLOG — це назва, якою оператори називають окремий лог-пристрій, приєднаний через log vdev(s) (наприклад, enterprise SSD або NVMe). Коли він присутній, ZFS записує записи ZIL на цей пристрій замість розміщення їх у основному пулі.

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

TXGs: система пакетування, яка робить ZFS ефективним

ZFS групує модифікації в TXG і періодично комітує їх на диск. Каденс за замовчуванням — на порядок секунд (залежить від реалізації; операційна точка — «пакетування»). Саме в цьому пакуванні ZFS отримує багато продуктивності: він може реупорядковувати, зливати і писати ефективно.

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

«Подвійний запис», який вас має хвилювати

У багатьох навантаженнях із великою кількістю синхронних операцій ви фактично записуєте дані двічі:

Записати журнальні записи в ZIL (на SLOG або в пул), щоб можна було підтвердити синхронність.
Пізніше записати реальні блоки у фінальне розташування під час коміту TXG.

Це не «марнування»; так ZFS забезпечує коректність і продуктивність. Але це означає, що ваш найшвидший пристрій може стати вузьким місцем у дуже специфічний спосіб: крихітний SLOG, що обробляє маленькі синхронні записи, може обмежити всю швидкість транзакцій вашого застосунку.

Затримка проти пропускної здатності: що змінює `logbias`

Ось пояснення для операторів: ZFS має вирішити, як обробляти синхронні записи, особливо великі. Логування великої кількості даних у ZIL може бути дорогим і породжувати другий потік записів, які система повинна потім поглинути знову. У таких випадках може бути розумніше трактувати «великий синхронний запис» як «треба швидко помістити це в пул», а не «пропхати все через лог-пристрій».

logbias — це підказка, яка спрямовує це рішення.

`logbias=latency` (за замовчуванням): робити підтвердження синхронних записів швидким

Коли ваше навантаження часто робить синхронні записи і дбає про час відгуку кожної транзакції — бази даних з гарантованими commit, NFS зі синхронною семантикою, диски VM з бар’єрами — затримка домінує.

При logbias=latency:

ZFS більш готовий спрямовувати дані синхронних записів у шлях ZIL/SLOG.
Якщо у вас хороший SLOG (низька затримка, захист від втрати живлення), ви часто побачите радикально нижчу латентність комітів.
Ваш пул може залишатися відносно спокійним, бо SLOG поглинає синхронний шквал, а пул надолужує через коміти TXG.

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

`logbias=throughput`: зменшити залежність від лог-пристрою, віддати перевагу стрімінгу в пул

logbias=throughput зазвичай використовують для навантажень, які генерують синхронні записи, але для яких затримка на запис менш важлива за загальну пропускну здатність — уявіть великі послідовні записи, позначені як синхронні через поведінку застосунку, рівні віртуалізації або консервативні налаштування експорту.

При logbias=throughput:

ZFS заохочується уникати пропхування великих синхронних записів через ZIL, бо це може перетворитися на «записати у лог зараз — записати знову пізніше» у великих масштабах.
Основний пул бере на себе більше роботи безпосередньо, що може бути кращим, якщо ваш пул широкий (багато vdev) і ваш SLOG відносно малий.

Що може піти не так: ви можете перемістити вузьке місце із затримки SLOG на затримку запису в пулі. Якщо пул складається з повільних обертових дисків, або якщо він вже фрагментований, або якщо у вас сильний тиск на читання, штовхання більшої частини синхронних даних «безпосередньо в пул» може збільшити видиму для застосунку затримку. Іншими словами: ви отримали пропускну здатність, але заплатили за це хвостову латентність.

Чого `logbias` не виправить

Деякі проблеми походять вище за стеком і сміятимуться над вашими властивостями:

Неправильно підібраний recordsize/volblocksize для навантаження.
VM-гості, які роблять малі випадкові синхронні записи на тонкопровізовані zvol з вимкненою компресією і без TRIM.
NFS-експорти зі синхронною поведінкою, яка змушує кожен запис бути стійким перед поверненням, у поєднанні з посереднім SLOG.
Пул, який просто вичерпав доступний IOPS.

Жарт №2: SLOG — як дверник у нічному клубі — якщо ви наймаєте повільного, неважливо, яка велика танцплоща; ніхто не потрапляє всередину.

Факти й історія, які можна використовувати на нарадах

Ось кілька коротких конкретних пунктів, які допоможуть вам розвіяти культи налаштувань на рев’ю дизайну.

ZFS спроектовано навколо семантики транзакцій, а не «записати на місце негайно». TXG — фундамент, а не додаток.
ZIL існує навіть без SLOG. Якщо ви не додаєте лог vdev, записи ZIL потрапляють на основні пристрої пулу.
SLOG використовується тільки для синхронних записів. Асинхронні стрімінгові записи не стануть раптово швидшими через додавання лог-пристрою.
ZIL зазвичай читають тільки після збою. За здорової роботи дані ZIL — «тільки для запису» і відкидаються після коміту TXG.
Захист від втрати живлення (PLP) — це не функція продуктивності; це функція коректності. Без PLP «швидке» підтвердження може стати «швидкою втратою даних».
Багато стеків віртуалізації і мережевого зберігання консервативно генерують синхронні записи (бар’єри, flush, стійкі записи). Іноді застосунок не параноїдальний; стек параноїдний.
Ранні розгортання ZFS популяризували підхід «додати SSD SLOG», але ринок споживчих SSD часто брехав про надійність flush — оператори вчилися на гіркому досвіді.
Окремі лог-пристрої можна дзеркалити, бо втрата SLOG під час роботи може спричинити паніку пулу/офлайн на деяких платформах/конфігураціях — доступність має значення.
Затримка і пропускна здатність можуть рухатися в протилежні боки, коли ви змінюєте шлях підтвердження синхронності, бо ви змінюєте, який пристрій стає «ворітьми».

Три корпоративні міні-історії (помилка, зворотний ефект, порятунок)

1) Інцидент через неправильне припущення: «SLOG прискорить усе»

Середня компанія працювала з NFS-сервісом на ZFS для артефактів збірки й образів VM. Вони мали проблему продуктивності: клієнти скаржилися на «випадкові паузи». Хтось запропонував класичне: «Додайте швидкий NVMe як SLOG; ZFS полетить». Закупівля привезла споживчий NVMe з відмінними послідовними бенчмарками і приємною ціною для фінансів.

Вони додали його як одиночний лог vdev і пішли додому. Декілька днів було краще — середня латентність NFS-записів знизилась, менше скарг. Потім стався елемент живлення: короткий відключення, перемикання UPS, нічого драматичного. Сервер зберігання повернувся, і за кілька хвилин пул почав мати проблеми. Клієнти бачили помилки I/O і висіли монтування. Сервер не був мертвим; він був гірше: живий і заплутаний.

Корінь проблеми був болісно звичайний. Споживчий NVMe не забезпечував надійного захисту від втрати живлення для семантики flush. Під час відключення журнальні записи, які були підтверджені як стійкі, фактично не були стійкими. ZFS зробив те, що мав: відмовився працювати далі безпечно, коли ланцюжок журналу не мав сенсу. Команда припустила, що «швидкий SSD = добрий SLOG», а продакшн показав інше.

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

2) Оптимізація, що дала зворотній ефект: «logbias=throughput скрізь»

Інше середовище: кластер віртуалізації, що використовує zvol для дисків VM через iSCSI. Команда зберігання помітила, що SLOG завантажений, і деякі VM мали посередню пропускну здатність запису. Хтось прочитав, що logbias=throughput може покращити продуктивність для великих синхронних записів, і вирішив застосувати це по всій інфраструктурі: всі датасети, всі zvol, без винятків. Вікно змін було малим, мотивація зрозуміла: менше змін — менше помилок.

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

Що сталося — архітектурно. Деякі VM робили великі послідовні записи (джоб бекапу) і дійсно отримали кращу пропускну здатність. Але шумні сусіди не були проблемою. Чутливі навантаження — малі синхронні бази даних. Змінивши ухил від шляху журналу, система перемістила більше синхронної роботи в основний пул. Пул міг це робити, але не з низькою латентністю при змішуванні з навантаженням на читання й періодичними scrub/зовнішніми роботами. Латентність комітів зросла, потім це переросло в тайм-аути застосунків.

Вони вибрали селективний відкат: logbias=latency для zvol баз даних, logbias=throughput для бекапів і об’ємних ingest-томів. Потім встановили SLO продуктивності, які явно відслідковували p95/p99 латентність комітів для синхронних записів, а не тільки MB/s. Оптимізація не була неправою; припущення, що одна настройка підходить для всіх, було помилковим.

3) Нудна, але правильна практика, яка врятувала день: «вимірювати синхронну латентність і дзеркалити SLOG»

Фінансова компанія (така, що ставить сховище як продукт першого класу) використовувала ZFS для внутрішніх кластерів PostgreSQL. Їх уже кусали «швидким, але крихким» залізом, тож їх практика була майже нудною: дзеркалені enterprise SLOG-пристрої з PLP і дашборд, що відслідковував метрики, пов’язані з ZIL, і латентність синхронних записів.

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

Вони відкрили логи системи і побачили періодичні помилки медіа на одному з SLOG-пристроїв. Оскільки лог-vdev був дзеркалений, пул залишився здоровим і сервіс працював. Оскільки вони вимірювали саме ту метрику, яку треба (синхронну латентність), вони зловили це до того, як це стало інцидентом. Вони замінили несправний пристрій у робочий час без драм — найкращий тип інцидент-репорту: той, що ніхто не пише.

Це важко продати на бюджетних нарадах: нудна практика не «підвищувала продуктивність». Вона просто не допустила перетворення проблеми продуктивності в проблему доступності.

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

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

По-перше: підтвердіть, що ви справді маєте справу з синхронними записами

Перевірте властивості набору даних/zvol: sync, logbias.
Перевірте поведінку клієнта/протоколу: NFS-монтування, налаштування надійності баз даних, бар’єри VM.
Шукайте симптоми: висока латентність при низькій пропускній здатності, багато малих записів, шаблони з інтенсивним fsync.

По-друге: визначте, чи лог-путь (SLOG) є воротами

Якщо у вас є SLOG, перевірте затримку і помилки лог-vdev.
Порівняйте латентність комітів застосунку з латентністю пристрою SLOG. Якщо вони корелюють — ви знайшли точку звуження.
Перевірте, чи SLOG насичується (IOPS, глибина черги) або зависає (латентність flush).

По-третє: якщо не SLOG, тоді вузьке місце — ваш пул (або CPU)

Перевірте латентність запису і використання пулу. Якщо ваші vdev майже 100% завантажені — ви вичерпали ресурс.
Перевірте тиск ARC і read amplification; сильні операції читання можуть відбирати ресурси для записів.
Перевірте накладні витрати на компресію, контрольні суми і шифрування, якщо CPU завантажений.

Точка прийняття рішення

Якщо проблема — латентність синхронних записів:

Віддавайте перевагу logbias=latency з належним SLOG для наборів даних, чутливих до затримки.
Розглядайте logbias=throughput тільки там, де навантаження велике і послідовне, і додаткові записі в пул не порушать SLO по затримці.

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

Це реальні завдання, які ви можете виконати на типовій системі OpenZFS-on-Linux. Підлаштуйте імена пулів/наборів даних під своє середовище. Сенс не в спорті виконувати команди; сенс — перетворити logbias з фольклору на вимірюваний вибір.

Завдання 1: Перевірити поточні `logbias` і `sync` на наборі даних

cr0x@server:~$ sudo zfs get -o name,property,value,source logbias,sync tank/db
NAME      PROPERTY  VALUE     SOURCE
tank/db   logbias   latency   local
tank/db   sync      standard  inherited from tank

Інтерпретація: Цей набір даних явно встановлено в logbias=latency. Поведінка sync — standard (дотримуватись запитів застосунку). Якщо ви налагоджуєте латентність комітів, це той базовий стан, якого слід очікувати.

Завдання 2: Знайти, де в пулі встановлено `logbias`

cr0x@server:~$ sudo zfs get -r -o name,property,value,source logbias tank | grep -v default
tank                     logbias   latency     default
tank/db                  logbias   latency     local
tank/backups             logbias   throughput  local

Інтерпретація: У вас змішана політика: бази даних — з ухилом на latency; бекапи — на throughput. Зазвичай це здорова конфігурація, якщо ваші навантаження дійсно різні.

Завдання 3: Перевірити, чи є окремий лог (SLOG) vdev

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:11:33 with 0 errors on Sun Dec 22 03:10:01 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            sda                     ONLINE       0     0     0
            sdb                     ONLINE       0     0     0
            sdc                     ONLINE       0     0     0
            sdd                     ONLINE       0     0     0
        logs
          mirror-1                  ONLINE       0     0     0
            nvme0n1p2               ONLINE       0     0     0
            nvme1n1p2               ONLINE       0     0     0

Інтерпретація: У вас є дзеркалений SLOG. Це надійна виробнича позиція для навантажень із великою кількістю синхронних операцій: продуктивність плюс доступність.

Завдання 4: Спостерігати за IO і латентністю на рівні пулу

cr0x@server:~$ sudo zpool iostat -v tank 1
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                         3.21T  8.54T    210    460  18.4M  62.1M
  raidz2-0                    3.21T  8.54T    210    460  18.4M  62.1M
    sda                           -      -     35     78  3.1M  10.5M
    sdb                           -      -     37     80  3.3M  10.2M
    sdc                           -      -     34     76  3.0M  10.4M
    sdd                           -      -     35     77  3.1M  10.6M
logs                              -      -      -      -
  mirror-1                        -      -      0    920    0B  12.4M
    nvme0n1p2                     -      -      0    470    0B   6.2M
    nvme1n1p2                     -      -      0    450    0B   6.1M

Інтерпретація: Багато записів йде до лог-vdev: сильний натяк, що ви маєте справу з навантаженням, зосередженим на синхронних операціях. Якщо застосунки скаржаться на латентність, тепер ви знаєте, куди дивитись далі: латентність лог-пристрою і поведінку flush.

Завдання 5: Отримати розширену статистику латентності (де підтримується)

cr0x@server:~$ sudo zpool iostat -v -l tank 2
                              capacity     operations     bandwidth    total_wait     disk_wait
pool                        alloc   free   read  write   read  write   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----  ----- -----   ----- -----
tank                         3.21T  8.54T    190    510  16.9M  64.8M   3ms  18ms     2ms  15ms
  raidz2-0                    3.21T  8.54T    190    240  16.9M  52.1M   2ms  22ms     2ms  19ms
logs                              -      -      0   1080    0B  12.7M    -   2ms       -   1ms
  mirror-1                        -      -      0   1080    0B  12.7M    -   2ms       -   1ms

Інтерпретація: Записи на лог-vdev — з низькою латентністю (добре). Записи в пулі повільніші (22ms). Якщо синхронна латентність хороша, а пропускна здатність погана — можливо обмеження в пулі; якщо синхронна латентність погана — лог може бути воротами. Такі числа допомагають відокремити два шляхи.

Завдання 6: Перевірити вирівнювання recordsize / volblocksize (часто прихований податок)

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

cr0x@server:~$ sudo zfs get -o name,property,value volblocksize tank/vm-001
NAME         PROPERTY     VALUE
tank/vm-001  volblocksize 8K

Інтерпретація: Бази даних часто краще поводяться з меншими recordsize (наприклад, 8K–16K) залежно від розміру сторінки БД і шаблону доступу. VM часто за замовчуванням мають 8K volblocks для zvol. Невирівняність може посилити IO і зробити синхронні хвилі гіршими незалежно від того, що каже logbias.

Завдання 7: Перевірити, чи навантаження змушує синхронність на шарі ZFS

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

Інтерпретація: standard зазвичай те, що вам треба: дотримуватись запитів застосунку. Якщо хтось встановив sync=always «для безпеки», очікуйте більше трафіку ZIL. Якщо хтось встановив sync=disabled «для продуктивності», очікуйте швидші бенчмарки і більш креативні інциденти.

Завдання 8: Змінити `logbias` для конкретного набору даних (безпечне локальне)

cr0x@server:~$ sudo zfs set logbias=throughput tank/backups
cr0x@server:~$ sudo zfs get -o name,property,value,source logbias tank/backups
NAME         PROPERTY  VALUE       SOURCE
tank/backups logbias   throughput  local

Інтерпретація: Це низькоризикова зміна, якщо набір даних містить великі послідовні записи і ви можете терпіти вищу латентність на запис. Не робіть цього на наборі даних, що містить журнали транзакцій, якщо вам не подобаються аварійні дзвінки.

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

Використовуйте fio, якщо доступно. У цьому прикладі робляться 4K записів у режимі, схожому на sync, з поведінкою fsync через fdatasync=1.

cr0x@server:~$ sudo fio --name=sync4k --directory=/tank/dbtest --rw=randwrite --bs=4k \
  --iodepth=1 --numjobs=1 --size=2G --direct=1 --fdatasync=1 --time_based --runtime=60 --group_reporting
sync4k: (groupid=0, jobs=1): err= 0: pid=22190: Tue Dec 24 10:11:09 2025
  write: IOPS=820, BW=3280KiB/s (3359kB/s)(192MiB/60001msec)
    clat (usec): min=500, max=32000, avg=1215.4, stdev=820.1
    lat (usec): min=510, max=32050, avg=1222.0, stdev=822.0

Інтерпретація: Це показує, що відчуває застосунок: ~1.2ms середня латентність завершення, з хвостами до 32ms. Якщо ви зміните logbias або SLOG-залізо і це не зміниться — ви налаштовуєте не той шар.

Завдання 10: Порівняти поведінку тестом, орієнтованим на пропускну здатність

cr0x@server:~$ sudo fio --name=seq128k --directory=/tank/backuptest --rw=write --bs=128k \
  --iodepth=16 --numjobs=4 --size=8G --direct=1 --fsync=0 --time_based --runtime=60 --group_reporting
seq128k: (groupid=0, jobs=4): err= 0: pid=22310: Tue Dec 24 10:13:30 2025
  write: IOPS=2100, BW=262MiB/s (275MB/s)(15.4GiB/60001msec)

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

Завдання 11: Визначити, чи NFS-клієнти змушують синхронну поведінку

cr0x@server:~$ mount | grep nfs
10.0.0.20:/export/vmstore on /mnt/vmstore type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.0.42)

cr0x@server:~$ nfsstat -m | sed -n '1,6p'
/mnt/vmstore from 10.0.0.20:/export/vmstore
 Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys

Інтерпретація: Опції монтування не завжди розкажуть повну історію; семантика NFS у поєднанні з патернами fsync застосунку має значення. Але це підтверджує, що ви не випадково змонтували лише для читання або з крихітними rsize/wsize, які все гальмують.

Завдання 12: Перевірити статистику ZFS щодо активності ZIL (Linux)

cr0x@server:~$ awk 'NR==1 || /zil/ {print}' /proc/spl/kstat/zfs/arcstats | head
13 1 0x01 122 4880 167920131122 293229773812
zil_commit_count                         4    189223
zil_commit_writer_count                  4    189223
zil_itx_count                            4    812333
zil_itx_indirect_count                   4    1102

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

Завдання 13: Підтвердити, що ваші лог-пристрої не вмирають мовчки

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | sed -n '1,25p'
SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        41 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    2%
Data Units Written:                 12,345,678
Media and Data Integrity Errors:    0
Error Information Log Entries:      0

Інтерпретація: Помилки медіа і записи в лог помилок важливіші за «процент використання». SLOG піддається шаленому навантаженню малими записами і flush; пристрій може виглядати «здоровим», поки раптом не стане нездатним. Слідкуйте за лічильниками помилок і латентністю, а не лише за ємністю.

Завдання 14: Визначити, де живе вузьке місце за допомогою `iostat`

cr0x@server:~$ iostat -x 1 3
Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda              30.0    75.0   3072   10432   18.5   2.1   98.0
sdb              29.0    76.0   2976   10384   19.0   2.0   97.5
sdc              28.0    74.0   2880   10240   18.9   2.0   97.1
sdd              29.0    75.0   2992   10368   19.2   2.1   98.3
nvme0n1           0.0   480.0      0    6144    1.1   0.2    9.5
nvme1n1           0.0   470.0      0    6016    1.0   0.2    9.2

Інтерпретація: HDD майже на 98% завантаженості. Навіть якщо ваш SLOG швидкий, пул насичений і вичерпаний, що зрештою позначиться на синхронній поведінці через тиск TXG і загальну відзивність служби. Якщо ваш «фікс» полягав тільки в logbias, він не витримає цієї реальності.

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

Контрольний список: вибір `logbias` для набору даних

Класифікуйте навантаження: Домінують малі синхронні записи (коміти БД, операції з великою кількістю метаданих) чи великі послідовні синхронні записи (масовий ingest із синхронними семантиками)?
Визначте метрику успіху: p95/p99 латентність для комітів або MB/s для масових записів. Якщо ви не можете її назвати — не зможете її налаштувати.
Перевірте, чи у вас справжній SLOG: enterprise-клас, PLP, низька латентність; бажано дзеркалення для доступності.
Встановіть logbias=latency для чутливих до затримки наборів даних: бази даних, диски VM з інтенсивними метаданими, інтерективні NFS-домашні директорії.
Встановіть logbias=throughput для масових наборів: бекапи, ingest медіа, тимчасове зберігання великих файлів — особливо коли синхронні семантики неможливо уникнути.
Бенчмаркуйте до і після: використовуйте тест, що імітує синхронні записи для синхронних навантажень, а не стрімінговий тест, який ігнорує fsync.

Покроковий план: безпечний rollout у продакшн

Виберіть один набір даних з чіткою ідентичністю навантаження і відповідальним власником (хтось, хто підтвердить успіх або біль).
Зніміть базові метрики (латентність синхронних записів, IOPS, хвостова латентність, використання пулу, латентність SLOG, якщо є).
Змінюйте лише одну змінну: встановіть logbias (не змінюйте одночасно recordsize, компресію і залізо).
Спостерігайте під час піку, а не тільки у вікні обслуговування. Проблеми синхронності часто виявляються при конкуренції за ресурси.
Швидко відкотіть, якщо хвостова латентність погіршилася. Тримайте команду відкату під рукою.
Документуйте раціонал (яке навантаження, яка метрика покращилась, яка погіршилась). Це припиняє «амнезію налаштувань» через шість місяців.

Операційні запобіжні заходи

Ніколи не використовуйте sync=disabled як обхід продуктивності для навантажень, які вимагають надійності. Якщо мусите — трактуйте це як свідоме рішення з підписанням ризику.
Дзеркаліть SLOG-пристрої для доступності, якщо платформа та ризикова терпимість цього вимагають. Втрата лог-пристрою може спричинити простої.
Розділяйте масові і чутливі до затримки навантаження принаймні на рівні наборів даних, бажано на рівні пулів, якщо конкуренція сильна.

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

Помилка 1: Припущення, що `logbias=throughput` «загалом швидший»

Симптоми: середні показники нормальні, але p95/p99 латентність погіршується; бази даних тайм-аутять; VM «підгальмовують» під навантаженням.

Чому так трапляється: ви змістили синхронну роботу з швидкого лог-пристрою на зайнятий пул, збільшивши конкуренцію і хвостову латентність.

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

Помилка 2: Купівля «швидкого SSD» для SLOG без PLP

Симптоми: періодичні проблеми пулу після відключень живлення; загадкові помилки I/O; ZFS відмовляється імпортувати чисто або скаржиться на відтворення журналу.

Чому так трапляється: пристрій бреше (або неоднозначний) щодо надійності flush. Підтвердження синхронних записів стає недостовірним.

Виправлення: використовуйте enterprise-пристрої з захистом від втрати живлення; дзеркаліть лог-vdev; моніторьте логи помилок пристроїв і латентність.

Помилка 3: Забувати, що SLOG не допомагає асинхронним записам

Симптоми: додали SLOG і не побачили змін у тестах великих стрімінгових записів; керівництво питає, чому ви «витратили гроші дарма».

Чому так трапляється: ваше навантаження в основному асинхронне; SLOG не на гарячому шляху.

Виправлення: бенчмаркуйте відповідну метрику (латентність синхронних записів) і підтвердьте, що застосунок/протокол справді робить синхронні записи.

Помилка 4: Встановити глобальні властивості і назвати це «стандартизацією»

Симптоми: одна команда задоволена, інша в паніці; графіки зберігання виглядають «ок», але продуктні SLO не виконуються.

Чому так трапляється: змішані навантаження потребують різної політики. ZFS дає контроль на рівні набору даних не випадково.

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

Помилка 5: Ігнорувати насичення пулу, бо «SLOG швидкий»

Симптоми: синхронна латентність спочатку хороша, потім гіршає з часом; періодичні хвилі під час scrub/resilver; «випадкові паузи».

Чому так трапляється: коміти TXG все одно мають бути записані. Насичений пул врешті-решт стане проблемою для всіх.

Виправлення: додайте vdev, переробіть макет, зменшіть фрагментацію, розділіть навантаження або перейдіть на швидше залізо. logbias не здатен створити IOPS з нічого.

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

1) Чи відключає `logbias=throughput` ZIL?

Ні. ZIL все ще існує і ZFS все ще надає синхронні семантики. logbias впливає на те, як ZFS віддає перевагу обробці певних шаблонів синхронних записів, особливо великих, але не знімає гарантій коректності.

2) Якщо у мене є SLOG, чи завжди слід використовувати `logbias=latency`?

Для чутливих до затримки синхронних навантажень зазвичай так — це правильний дефолт. Для масових наборів з великими синхронними записами logbias=throughput може зменшити тиск на лог і покращити загальну пропускну здатність. Правильна відповідь — «на рівні набору даних, залежно від навантаження, після вимірювань».

3) Чи покращить додавання швидшого SLOG пропускну здатність моєї бази даних?

Може підвищити кількість транзакцій, якщо БД застрягає на латентності fsync() і ви зараз обмежені повільними стійкими записами. Але це не виправить погані плани запитів, недостатню пам’ять або насичений пул. Виміряйте латентність комітів перед покупкою заліза.

4) У чому різниця між ZIL і SLOG в одному реченні?

ZIL — це механізм журналу намірів, який завжди існує; SLOG — це опціональний окремий пристрій, на який ви можете направити ZIL, щоб записи журнала потрапляли туди швидше (і бажано безпечніше), ніж в основний пул.

5) Чи безпечно працювати без SLOG?

Так, з точки зору коректності: ZIL-записи будуть писатися в основний пул. Продуктивність може постраждати для навантажень із великою кількістю синхронних операцій, бо основні пристрої пулу мусять обробляти шлях підтвердження синхронності.

6) Чи слід мені дзеркалити SLOG?

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

7) Чи може `logbias` виправити «випадкові паузи» NFS?

Іноді. Якщо паузи викликані латентністю підтвердження синхронних записів і ваш лог-пристрій є вузьким місцем (або відсутній), налаштування logbias і/або додавання належного SLOG може допомогти. Якщо паузи викликані насиченням пулу, проблемами мережі або поведінкою клієнта — ні.

8) Чи слід використовувати `sync=disabled` замість гри з `logbias`?

Тільки якщо ви свідомо ризикуєте втратою даних при відключенні живлення або збоях, і власники застосунків погоджуються, що стійкість не критична. Для більшості продакшн-систем sync=disabled — не опція налаштування; це політичне рішення з наслідками.

9) Як зрозуміти, чи моє застосунок робить синхронні записи?

Шукайте зростання лічильників комітів ZIL, інтенсивну активність записів лог-vdev і бенчмарки, які суттєво змінюються, коли ви змушуєте fdatasync/fsync. Також перевіряйте налаштування застосунку (режими надійності БД) і семантику протоколів (стійкі записи NFS, бар’єри віртуалізації).

10) Якщо мій SLOG швидкий, чому мій пул все ще зайнятий?

Бо SLOG лише допомагає швидко підтвердити синхронні записи. Дані все одно мають потрапити у фінальне місце під час коміту TXG. Якщо пул замалий, сильно фрагментований або ділиться на багато змішаних навантажень, він може залишитися довготривалим вузьким місцем.

Висновок

logbias — це не налаштування «прискорення продуктивності». Це заява пріоритетів. Коли ви встановлюєте logbias=latency, ви говорите: «Мені важливо, як швидко ви підтверджуєте синхронні записи, і я побудував систему — особливо SLOG — щоб зробити це безпечним і швидким». Коли ви встановлюєте logbias=throughput, ви кажете: «Мені важливо ефективно переміщати дані, і я готовий пожертвувати частиною часу відповіді кожного запису, щоб уникнути перетворення шляху журналу на другорядну роботу».

Системи, що добре працюють у продакшні, не обирають одну ідеологію. Вони обирають на рівні навантаження, вимірюють правильні метрики (включаючи хвостову латентність) і тримають нудні речі — PLP, дзеркалювання, моніторинг — як незмінні. Якщо ви так робитимете, logbias перестане бути загадковою властивістю і стане тим, чим і повинно бути: свідомим вибором.