ZFS SLOG: коли лог-пристрій допомагає, коли марний, коли небезпечний

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

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

Існують два типи проблем продуктивності ZFS: ті, що вирішуються архітектурно, і ті, якими намагаються впоратися купівлею заліза о 2-й ночі. Окремий лог-пристрій (SLOG) живе саме на цій межі. Для правильної робочого навантаження він перетворює «чому кожен fsync займає вічність?» на «о, тепер усе добре». Для неправильної робочого навантаження це дорогий паперовий прес, який додає нові режими відмов.

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

Що таке SLOG насправді (і чому він існує)

Почнемо з термінології, тому що «SLOG» — це одне з тих слів, що його використовують як турбо-кнопку.

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

SLOG — це окремий LOG-пристрій: виділений vdev, куди ZFS зберігає записи ZIL замість використання основних дисків пулу. Суть — затримка. Ротаційні диски (і навіть багато SSD) дуже погано поводяться з малими синхронними записами з низькою затримкою, коли вони зайняті іншою роботою. Добрий SLOG може швидко підтверджувати синхронні записи, а основні vdev-и пулу асинхронно оброблятимуть оптову роботу.

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

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

Жарт №1 (обов’язковий і заслужений): Купувати SLOG для асинхронного навантаження — як встановлювати запасний вихід у басейн: технічно вражає, але операційно не має значення.

Цікаві факти та коротка історія

Короткі, конкретні контекстні моменти, які допомагають розуміти, з чим ви маєте справу:

ZFS народився в епоху «брехливого підтвердження записів». Стеки зберігання історично підтверджували записи до того, як вони справді були довговічними; ZIL існує, щоб забезпечити правильні семантики для додатків, які цього вимагають.
ZIL — це не журнал файлової системи. Це ближче до журналу намірів для нещодавніх синхронних операцій, а не повного метаданого журналу, що відтворює весь стан файлової системи.
SLOG став поширеною темою з популяризацією NFS. Клієнти NFS (особливо для віртуальних машин) часто виконують багато синхронних записів або вимушують їх через опції монтування/експорту, перетворюючи затримку на критичний показник.
Ранні SSD були швидкі, але нечесні. Багато споживчих SSD швидко підтверджували flush, але насправді не зберігали дані під час втрати живлення; тому захист від втрати живлення (PLP) став лакмусовим тестом для SLOG.
Часування TXG визначає багато чого. ZFS пакує зміни в транзакційні групи; інтервал коміту за замовчуванням (зазвичай близько 5 секунд) пояснює, чому SLOG не має бути великим за обсягом.
Еволюціонували спеціальні типи vdev. ZFS додав ролі для vdev (log, cache, special, dedup). SLOG — одна з найстаріших «окремих ролей» vdev і також одна з найбільш неправильно зрозумілих.
Деякі вендори продавали «SLOG-в коробці». Збірки з NVRAM або дзеркальними лог-пристроями продавалися як рішення, бо низька затримка підтвердження продається добре для покупців VM і баз даних.
sync=disabled — червона мітка постмортемів. Команди постійно переобнаружують, що продуктивність, яку ви «здобули», брехнею додаткових семантик стане в майбутньому втратою даних, яку важко пояснити аудиторам.

Коли SLOG допомагає, коли марний, коли небезпечний

Коли SLOG допомагає

SLOG допомагає, коли ваша пляшка — це затримка синхронного запису. Не пропускна здатність. Не IOPS читання. Не RAIDZ-математика. Затримка для операцій, які мають бути зафіксовані перед тим, як виклик продовжить роботу.

Класичні випадки:

NFS для віртуалізації (дискі віртуальних машин по NFS). Гостьові файлові системи викликають fsync. Гіпервізори можуть бути надмірно синхронними. Результат — постійний дощ малих синхронних записів.
Бази даних, налаштовані на сильну довговічність (або які явно роблять fsync при коміті). Якщо база даних на ZFS і набір даних сильно синхронний, добрий SLOG може зменшити пікові затримки комітів.
Додатки, які використовують O_DSYNC / O_SYNC або часті виклики fsync (логери, черги повідомлень, деякі CI-системи з параноїдальною роботою з файлами).
Навантаження, доміновані маленькими випадковими синхронними записами, коли ваші основні vdev-и — HDD або зайняті SSD і не можуть забезпечити низьку, стабільну затримку.

Що ви помітите, коли SLOG — правильне рішення: система не «повільна всюди». Вона повільна саме в синхронних точках. CPU в нормі. ARC в нормі. Читання в нормі. Але транзакції затримуються. Перцентилі затримок виглядають погано. Користувачі описують «провали» замість постійної повільності.

Коли SLOG марний

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

Оптові послідовні записи (резервні копії, медіа-інжест, великі копії файлів). ZFS буферизує в пам’яті й скидає в TXG; SLOG не в критичному шляху.
Навантаження з переважним читанням. SLOG не має відношення до читань. Це зона ARC/L2ARC і макету vdev.
Завантаження CPU компресією, контрольними сумами або шифруванням. Якщо ви завантажуєте ядра з zstd чи AES, SLOG не вирішить проблему.
NFS/SMB, обмежені мережею. Якщо ваші NICs насичені, SLOG — дуже дороге продовження насичення.
Пули з уже низькою затримкою (усі NVMe дзеркала з запасом), іноді пул уже швидший за синхронний ритм вашого додатку; додавання лог-пристрою ускладнює систему без вигоди.

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

Коли SLOG небезпечний

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

Ризикові ситуації:

Використання споживчого SSD без PLP як SLOG. Він може підтвердити flush, а потім втратити останні секунди записів при втраті живлення. ZFS чесно відтворить те, що має; відсутня частина — ваші проблеми.
Одинарний диск SLOG у системі, де втрата логу неприйнятна. Якщо SLOG помре так, що втрачає записи ZIL у польоті, ви можете втратити синхронні записи, які вже були підтверджені клієнтам.
Неправильне використання налаштувань sync (наприклад, sync=disabled), щоб «повернути продуктивність». Це не стільки «небезпечно», скільки «помітно руйнівно для кар’єри».
Надмірна впевненість у дзеркальному SLOG. Дзеркалення захищає від відмови пристрою, але не додає захисту від втрати живлення або не виправляє неправильну поведінку flush у прошивці.
Додавання SLOG, щоб замаскувати недостатній пул. Якщо ваші основні vdev-и не витримують майбутніх TXG-комітів, SLOG може зменшити видиму затримку, але штовхатиме пул у накопичення роботи. Це накопичення закінчиться обривом.

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

Як насправді працюють ZIL, SLOG, TXGs і синхронні записи

Щоб впевнено працювати з SLOG, вам потрібна ментальна модель. Ось та, яка витримує інциденти.

Асинхронні записи: щасливий шлях

Більшість записів — асинхронні. Додаток записує; ОС передає дані ZFS; ZFS розміщує зміни в пам’яті (ARC і інші структури) і пізніше скидає їх на диск під час коміту транзакційної групи. ZFS пакує роботу, щоб бути ефективним: менше позиціонувань, більше послідовних записів, краща компресія, кращі контрольні суми, загалом більша пропускна здатність.

Для асинхронних записів підтвердження не вимагає стійкого збереження. Ось чому SLOG не має значення: ZFS не чекав на запис у ZIL, щоб додаток продовжив роботу.

Синхронні записи: «Мені потрібно, щоб це пережило крах»

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

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

Де живе ZIL без SLOG

Без окремого лог-пристрою ZIL живе на основних vdev-ах пулу. Це означає, що синхронні записи конкурують з усім іншим: звичайні записи, читання, scrub, resilver, метадані. На обертових дисках це часто катастрофічно для затримок: голівка рухається, щоб записати маленький запис, потім повертається, щоб продовжити послідовну роботу, і ви щойно створили випадковий I/O посеред послідовного потоку.

Що змінює SLOG

Додавши SLOG, ви переміщуєте ZIL-записи на виділений, зазвичай низькозатримковий пристрій. Тепер синхронні записи потрапляють на SLOG, швидко підтверджуються, а основний пул продовжує пакувати TXG майже без переривань. Пул все одно повинен зрештою записати реальні дані під час комітів TXG. SLOG не видаляє підлягаючого навантаження записів; він розділяє затримку підтвердження від пропускної здатності оптового коміту.

Чому розмір SLOG зазвичай невеликий

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

Що відбувається під час краху або втрати живлення

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

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

Два регулятори, які ви побачите: `sync` і `logbias`

sync — це властивість набору даних, яка впливає на те, як ZFS трактує запити про синхронну поведінку. Має значення як standard (за замовчуванням), always і disabled. Вони не змінюють те, що просить додаток; вони змінюють, як ZFS на це відповідає. Якщо ви встановите sync=disabled, ви вирішуєте брехати додаткам щодо довговічності.

logbias — це властивість набору даних, яка може бути latency (за замовчуванням) або throughput. Вона впливає на те, як ZFS використовує лог для певних навантажень. Неправильне налаштування може нівелювати ефект SLOG або змінити патерни роботи в несподіваний спосіб. Це не магічний перемикач «зроби SLOG швидшим»; це підказка про те, що вам важливіше.

Що робить хороший пристрій SLOG (і що робить поганий)

Справжні вимоги: стабільна затримка і чесна довговічність

Добрий SLOG-пристрій має:

Низьку затримку для малих синхронних записів (особливо при варіабельній глибині черги).
Захист від втрати живлення (PLP), щоб підтверджені записи переживали раптову втрату живлення.
Правильну поведінку flush/FUA. ZFS покладається на те, що пристрій коректно обробляє бар’єри/flush.
Достатню витривалість для стійких синхронних навантажень.
Передбачувану продуктивність під навантаженням (GC та термообмеження — тихі вбивці «він бенчмаркував чудово»).

Поганий SLOG-пристрій зазвичай «швидкий по паперу», але без PLP або з прошивкою, що трактує flush як рекомендацію. Споживчі NVMe можуть бути надзвичайно швидкими для асинхронних записів і все одно ризиковими для синхронної довговічності, якщо використовують леткі кеші записів без захисту. Шлях SLOG алергічний на «брехню».

Дзеркалення SLOG: коли це важливо

Якщо ви не можете терпіти втрату нещодавно підтверджених синхронних записів через відмову одного пристрою, дзеркальте SLOG. Це звично в корпоративних середовищах, де NFS експорти подають диски VM і один втраченний лог-запис стає історією корупції файлової системи VM.

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

Але не плутайте дзеркалення з безпекою

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

Не переплачувати за ємність

Ємність SLOG рідко є обмеженням. Важлива продуктивність і безпека. Якщо ви купили 2 ТБ «ігрового NVMe» як лог-пристрій, ви дорого купили неправильно. Менший корпоративний SSD з PLP зазвичай правильний вибір.

Розміщення та топологія важливі

Розміщення SLOG за ненадійним HBA, експандером, що вже насичений, або контролером з хитрощами write-cache може стерти вигоди. SLOG знаходиться в шляху синхронізації; шлях синхронізації має бути нудним і детермінованим.

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

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

Завдання 1: Підтвердити, чи існує SLOG і як він сконфігурований

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 00:32:10 with 0 errors on Wed Dec 18 03:12:20 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-HDD_A               ONLINE       0     0     0
            ata-HDD_B               ONLINE       0     0     0
        logs
          mirror-1                  ONLINE       0     0     0
            nvme-INTEL_SLOG_A       ONLINE       0     0     0
            nvme-INTEL_SLOG_B       ONLINE       0     0     0

errors: No known data errors

Інтерпретація: Шукайте секцію logs. Якщо її немає — у вас немає окремого log vdev. Якщо вона є, зауважте, чи дзеркалена вона. Також зверніть увагу, чи показує log vdev помилки; хворий SLOG — ризик для коректності.

Завдання 2: Перевірити поведінку sync для набору даних (найважливіше)

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

Інтерпретація: standard означає, що ZFS поважає запити додатків на sync. always змушує синхронні семантики (більш довговічно, часто повільніше). disabled — «зроби швидко, зроби крихким» режим.

Завдання 3: Перевірити `logbias`, бо воно змінює поведінку логу

cr0x@server:~$ sudo zfs get -o name,property,value,source logbias tank/vmstore
NAME          PROPERTY  VALUE    SOURCE
tank/vmstore  logbias   latency  default

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

Завдання 4: Визначити, чи клієнти форсують sync (поширено для NFS)

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

Інтерпретація: Якщо бачите sync=always на NFS-наборі, очікуйте сильну залежність від SLOG. Якщо бачите sync=disabled, очікуйте, що постмортем може містити слово «корупція».

Завдання 5: Спостерігати за ZFS I/O у реальному часі і перевірити, чи активний лог-пристрій

cr0x@server:~$ sudo zpool iostat -v tank 1
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        1.20T  2.40T     50    900  3.2M  85.0M
  mirror-0                  1.20T  2.40T     50    520  3.2M  42.0M
    ata-HDD_A               -      -         25    260  1.6M  21.0M
    ata-HDD_B               -      -         25    260  1.6M  21.0M
logs                          -      -        0    380    0  14.0M
  mirror-1                    -      -        0    380    0  14.0M
    nvme-INTEL_SLOG_A         -      -        0    190    0   7.0M
    nvme-INTEL_SLOG_B         -      -        0    190    0   7.0M
--------------------------  -----  -----  -----  -----  -----  -----

Інтерпретація: Якщо навантаження синхронне, ви маєте бачити операції запису на vdev logs. Якщо logs показує нуль, а додатки скаржаться на fsync-затримки, можливо, ви не маєте справу з синхронними записами — або набір даних не використовує SLOG так, як ви думаєте.

Завдання 6: Перевірити загальну затримку пулу та поведінку кожного vdev (знайти повільний диск)

cr0x@server:~$ sudo zpool iostat -v -l tank 5
                              capacity     operations     bandwidth    total_wait  disk_wait
pool                        alloc   free   read  write   read  write    ---------  ---------
tank                        1.20T  2.40T     80   1100  5.1M  95.0M      18ms       12ms
  mirror-0                  1.20T  2.40T     80    650  5.1M  48.0M      22ms       16ms
    ata-HDD_A               -      -         40    325  2.6M  24.0M      18ms       12ms
    ata-HDD_B               -      -         40    325  2.6M  24.0M      27ms       20ms
logs                          -      -        0    450    0  18.0M       1ms        1ms
  mirror-1                    -      -        0    450    0  18.0M       1ms        1ms
    nvme-INTEL_SLOG_A         -      -        0    225    0   9.0M       1ms        1ms
    nvme-INTEL_SLOG_B         -      -        0    225    0   9.0M       1ms        1ms

Інтерпретація: Це показує час очікування. Якщо один диск має значно більший disk_wait, він може тягнути vdev і пул вниз. SLOG не виправить хворий vdev, який не може швидко комітити TXG.

Завдання 7: Підтвердити, чи взагалі генеруються синхронні записи (міні-тест з fsync)

cr0x@server:~$ cd /tank/vmstore
cr0x@server:/tank/vmstore$ sudo bash -c 'sync; echo 3 > /proc/sys/vm/drop_caches'
cr0x@server:/tank/vmstore$ /usr/bin/time -f "elapsed=%e sec" bash -c 'dd if=/dev/zero of=./fsync.test bs=4k count=4096 conv=fdatasync'
4096+0 records in
4096+0 records out
16777216 bytes (17 MB, 16 MiB) copied, 0.42 s, 40.0 MB/s
elapsed=0.42 sec

Інтерпретація: conv=fdatasync примушує синхронізацію наприкінці. Запустіть це з SLOG і без нього (або на порівнянному хості). Якщо не бачите покращення, або пул вже швидкий при sync, або ви обмежені іншим (CPU, мережа, TXG-тиск).

Завдання 8: Спостерігати поведінку TXG і шукати тиск на коміти (Linux OpenZFS)

cr0x@server:~$ grep -E "txg|zil" /proc/spl/kstat/zfs/arcstats | head
txg_sync                       4    0
txg_quiesce                    4    0
txg_wait_synced                4    0
zil_commit                     4    0

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

Завдання 9: Перевірити, чи справді лог-пристрій швидкий при flush (базове здоров’я пристрою)

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | sed -n '1,25p'
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.6.0] (local build)
=== START OF INFORMATION SECTION ===
Model Number:                       INTEL SSDPED1D280GA
Serial Number:                      BTKA1234567F280G
Firmware Version:                   EDF1470C
NVMe Version:                       1.3
...
Critical Warning:                   0x00
Temperature:                        36 Celsius
Available Spare:                    100%
Percentage Used:                    2%
Data Units Written:                 134,221 [68.7 GB]

Інтерпретація: Ви дивитесь на здоровий пристрій з низьким зносом медіа. SLOG може приймати постійний тиск записів; споживчі пристрої можуть швидко зношуватись у синхронних навантаженнях.

Завдання 10: Додати дзеркальний SLOG безпечно (приклад)

cr0x@server:~$ sudo zpool add tank log mirror /dev/disk/by-id/nvme-INTEL_SLOG_A /dev/disk/by-id/nvme-INTEL_SLOG_B
cr0x@server:~$ sudo zpool status tank | sed -n '1,25p'
  pool: tank
 state: ONLINE
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-HDD_A               ONLINE       0     0     0
            ata-HDD_B               ONLINE       0     0     0
        logs
          mirror-1                  ONLINE       0     0     0
            nvme-INTEL_SLOG_A       ONLINE       0     0     0
            nvme-INTEL_SLOG_B       ONLINE       0     0     0

Інтерпретація: Використовуйте стабільні шляхи пристроїв (/dev/disk/by-id), щоб перезавантаження не перемішало імена. Після додавання спостерігайте zpool iostat, щоб підтвердити, що навантаження ним користується.

Завдання 11: Видалити SLOG (і як це «безпечно» виглядає)

cr0x@server:~$ sudo zpool remove tank mirror-1
cr0x@server:~$ sudo zpool status tank | sed -n '1,35p'
  pool: tank
 state: ONLINE
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-HDD_A               ONLINE       0     0     0
            ata-HDD_B               ONLINE       0     0     0

errors: No known data errors

Інтерпретація: Видалення log vdev підтримується в сучасному OpenZFS. Робіть це у спокійне вікно; спостерігайте за затримками клієнтів. Якщо продуктивність падає, ви підтвердили, що навантаження синхронозалежне.

Завдання 12: Виявити «sync-шторм» від NFS або навантажень VM

cr0x@server:~$ sudo nfsstat -s | sed -n '1,25p'
Server rpc stats:
calls      badcalls   badfmt     badauth    badclnt
214748     0          0          0          0

Server nfs v4:
null       compound
0          198322

Server nfs v3:
null       getattr    setattr    lookup     access     readlink
0          4123       1882       22091      7851       0
read       write      create     mkdir      symlink    mknod
70221      88011      312        12         0          0
commit     remove     rename     link       readdir    readdirplus
65002      401        33         0          112        909

Інтерпретація: Багато викликів NFS commit може корелювати з тиском на sync. Поєднайте це з zpool iostat, щоб бачити, чи SLOG поглинає лог-записи або чи удар приймають основні vdev-и.

Завдання 13: Перевірити, чи набір даних випадково не змушує sync

cr0x@server:~$ sudo zfs get -r -o name,property,value,source sync tank | sed -n '1,30p'
NAME            PROPERTY  VALUE     SOURCE
tank            sync      standard  default
tank/nfs        sync      always    local
tank/vmstore    sync      standard  default
tank/backups    sync      standard  default

Інтерпретація: Одиночний набір даних з sync=always може домінувати у сприйнятті продуктивності пулу. Іноді це коректно; іноді це наслідування з форуму років тому.

Завдання 14: Виявити пул, що відстає в комітах TXG (класичний backpressure)

cr0x@server:~$ sudo zpool iostat tank 1
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        1.20T  2.40T     40   2200  2.4M  240M
tank        1.20T  2.40T     35   2400  2.1M  260M
tank        1.20T  2.40T     38   2600  2.3M  280M

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

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

Це послідовність «я маю 10 хвилин, поки виклик інцидента не перетвориться на ритуал звинувачень». Ви намагаєтеся відповісти на одне питання: Чи пляшка — це затримка синхронізації, чи щось інше?

Перший крок: визначити, чи навантаження синхронне

Перевірте властивості набору даних: zfs get sync,logbias <dataset>.
Спостерігайте активність log vdev: zpool iostat -v <pool> 1. Якщо log vdev простий під час «болю синхронності», SLOG не в шляху.
Подивіться на поведінку клієнтів (NFS commit, fsync у бази даних, патерни збереження VM). Якщо не можете спостерігати додаток, хоча б перевірте серверну сторону: статистику NFS, iostat, затримки.

Другий крок: якщо навантаження синхронне, визначте, чи SLOG — пляшка

Використовуйте затримки по vdev: zpool iostat -v -l <pool> 5. Якщо log vdev має вищий чек, ніж очікується, він не виконує свою роботу.
Перевірте здоров’я пристрою і помилки: zpool status -v і smartctl.
Підтвердьте, що лог-пристрій не за повільним шляхом (спільні лінії PCIe, насичений HBA, неправильно налаштований multipath).

Третій крок: якщо SLOG виглядає нормально, ймовірно вузьке місце — шлях коміту пулу

Перевірте затримку основних vdev у zpool iostat -l. Повільний HDD, помираючий SSD або rebuild vdev вкладуться в домінуючу проблему.
Шукайте фонову роботу: scrub, resilver, важкі snapshot-и, send/recv, навантаження на CPU від компресії/шифрування.
Перевірте тиск пам’яті: якщо машині не вистачає RAM або ARC обмежений, ZFS може досягати лімітів брудних даних і жорстко тротлити.

Четвертий крок: вирішіть, що змінити (в порядку пріоритету)

Якщо навантаження синхронне і немає SLOG: додайте правильний дзеркальний PLP SLOG.
Якщо навантаження синхронне і SLOG існує, але це споживчий клас: замініть його.
Якщо шлях коміту повільний: виправте макет vdev, вийміть повільний диск, додайте дзеркала, зменшіть ширину RAIDZ для IOPS-навантажень або масштабуйтесь горизонтально.
Якщо проблема в «хтось змусив sync скрізь»: відрегулюйте налаштування набору даних/експорту/додатку з чіткою позицією щодо довговічності.

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

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

Тікет звучав ввічливо: «Перервна корупція файлової системи VM при втраті живлення». Команда зберігання спочатку оборонялася — нікому не подобається, коли кажуть, що платформа гризе дані — але шаблон був занадто чистий. Це траплялося лише після раптового ребута PDU в стійці під час тестування обслуговування. Нормальні перезавантаження були в порядку.

Середовище було NFS-датастор на ZFS для кластера гіпервізорів. У них був SLOG, і вони ним пишалися. «Ми купили NVMe, він швидкий», — казали вони, і це перше речення багатьох постмортемів. SLOG був один споживчий NVMe, бо «це лише лог». Сам пул був дзеркалами HDD, гідний для ємності і в основному в порядку для пропускної здатності, але синхронна затримка була їхньою проблемою, тож SLOG здавався правильним важелем.

Після декількох відтворень і незручних пауз урок виявився очевидним: NVMe швидко підтверджував flush, але ненадійно зберігав останні моменти записів під час раптового відключення живлення. Гіпервізори отримували підтвердження «ваші коміти в безпеці», бо NFS і гостьові FS покладалися на цю обіцянку. Потім коробка втрачала живлення. При імпорті ZFS відтворив те, що було в логу. Чого не вистачало — це останнього, що пристрій прикинувся довговічним.

Виправлення не було героїчним. Вони замінили SLOG на корпоративний пристрій з PLP і дзеркалили його, бо не хотіли, щоб один компонент став «ось тут сталося фіаско». Вони також перестали говорити «це просто лог». У ZFS лог — частина контракту довговічності.

Операційні зміни були важливішими за залізо: вони задокументували, що означає «sync safe» для своїх NFS-експортів, додали симуляцію відключення живлення в приймальні тести і написали ранбук, що починався з «Підтвердити, що SLOG має PLP». Інциденти з корупцією припинилися, і єдине, що вони втратили — ілюзію, що продуктивні компоненти можна сприймати як аксесуари.

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

Фінансово суміжний додаток мав періодичні сплески: кінець місяця, кінець кварталу, кінець року — священна трійка «чому сьогодні повільно?». Він працював на VM по NFS на ZFS. Під час сплесків затримки різко зростали й додаток таймаутував. Хтось виявив, що встановлення sync=disabled робить графіки прекрасними. Змінили швидко, бо бізнес кричав, і зміна була зворотна. В чесності — це працювало. Але посадило міну.

Повернення ударило через тижні у формі «ми перезавантажили після оновлень ядра і останні кілька хвилин транзакцій додатка зникли». Не корупція. Не частково записані дані. Просто відсутні. База даних робила sync-запити при коміті, зберігання брехало і казало «ок», і всесвіт вимагав оплату цього боргу на наступному краху.

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

Довгострокове виправлення було нудним: справжній SLOG, дзеркалений, з PLP, відповідного розміру, плюс зміни в додатку для розумнішого батчування комітів. Вони також встановили явні SLO для латентності коміту і вимірювали fsync-частоти, щоб «sync» перестало бути містичною властивістю. Оптимізація не лише відкинула назад — вона пошкодила інституційну пам’ять, і це довелося відновлювати.

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

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

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

Під час розширення латентність синхронізації тихо подвоїлася. Не достатньо, щоб негайно тригерити алерти, але достатньо, щоб проявитися в хвостових затримках VM-операцій. Нудна валідаційна суїта виявила це. Команда порівняла результати з базовою і побачила, що log vdev тепер показує більший чек, ніж зазвичай.

Винуватцем не був ZFS. Оновлення прошивки на новому бекплейні PCIe змінило узгодження лінків, і NVMe-слот, призначений для SLOG, працював на зменшеній ширині ліній. SLOG все ще був «швидким» у тестах пропускної здатності, бо послідовні числа виглядають чудово, але його латентність під навантаженням flush погіршилася — а саме це і потрібно SLOG.

Вони перемістили SLOG-пристрої в інші слоти, підтвердили ширину ліній, повторили тест латентності, і хвостові сплески зникли. Жодного простою, жодного впливу на клієнтів, жодного інциденту. Єдиний видимий артефакт — рядок у зміні: «Виправлено ширину ліній NVMe; відновлено базову латентність sync».

Ось що означає компетентність у продакшні: не героїчні вчинки, а маленькі тести, які запобігають вивченню про переговори PCIe через злі Slack-повідомлення.

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

Цей розділ написаний мовою симптомів, бо саме так ви зустрічаєте SLOG у реальному житті.

Помилка 1: Додати SLOG і очікувати прискорення оптових записів

Симптоми: Жодного помітного покращення; завдання резервного копіювання все ще повільні; послідовна пропускна здатність запису незмінна; log vdev показує мінімальну активність.

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

Виправлення: Приберіть SLOG, якщо він додає ризик без користі, або лишіть його, лише якщо у вас є синхронні навантаження, які ви ще не виміряли. Оптимізуйте макет vdev, recordsize, компресію або мережу, якщо навантаження — оптовий I/O.

Помилка 2: Використання споживчого SSD/NVMe без PLP як SLOG

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

Чому: Пристрій підтверджує запис і flush, які насправді не персистуються.

Виправлення: Замініть на корпоративний пристрій з PLP і перевіреною поведінкою flush. Дзеркальте його, якщо потрібна доступність і зменшення шансів втрати логу при відмові пристрою.

Помилка 3: Одинарний диск SLOG для навантаження, яке шанує sync

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

Чому: Лог-пристрій тепер частина шляху довговічності; одна точка відмови — азарт.

Виправлення: Дзеркальте SLOG. Тримайте запасні диски. Тестуйте процедури заміни. Якщо дзеркалення неможливе, перегляньте, чи варто це навантаження тримати на цій архітектурі.

Помилка 4: Встановлення `sync=disabled`, щоб зробити графіки зеленими

Симптоми: Покращення продуктивності, за яким слідує втрата/корупція даних після краху; аудитори цікавляться вашими вихідними планами.

Чому: Ви сказали ZFS підтверджувати синхронні записи без їх довговічного збереження.

Виправлення: Встановіть sync=standard (або always, якщо потрібно). Додайте правильний SLOG і/або змініть поведінку додатку (батчування, групові коміти), щоб зменшити частоту fsync.

Помилка 5: Трактувати SLOG як «кеш» і перебільшувати ємність

Симптоми: Немає користі від великої ємності SLOG; бюджет витрачено без помітного зниження затримок.

Чому: SLOG зберігає коротке вікно записів ZIL, а не всі записи.

Виправлення: Розмірюйте за латентністю і безпекою, а не за ємністю. Витрачайте бюджет на якість (PLP, витривалість), а не на терабайти.

Помилка 6: Ігнорувати здатність основного пулу комітити TXG

Симптоми: Спочатку затримка sync покращується з SLOG, потім система потрапляє у періодичні застої; схоже, що пропускна здатність в порядку, але додатки таймаутять; «усе фризиться кожні кілька секунд».

Чому: SLOG роз’єднує підтвердження і не знімає необхідності комітити дані у пул. Якщо пул не встигає, він почне тротлити.

Виправлення: Поліпшіть записну продуктивність пулу (більше vdev-ів, дзеркала, швидші диски), зменшіть write amplification (recordsize, compression) або зменшіть навантаження. SLOG не заміна адекватній пропускній здатності комітів.

Помилка 7: Плутати L2ARC із SLOG

Симптоми: «Ми додали SLOG, а читання все ще повільні».

Чому: SLOG для підтвердження синхронних записів. L2ARC — кеш читань другого рівня. Різні проблеми — різні інструменти.

Виправлення: Якщо читання повільні, дослідіть ARC hit ratio, властивості набору даних, IOPS читання vdev і, можливо, L2ARC. Не купуйте лог-пристрій для проблеми читання.

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

Чекліст: Вирішіть, чи взагалі потрібен SLOG

Виміряйте інтенсивність sync: Визначте fsync-важливі додатки (бази даних, VM/NFS) і чи вони дійсно обмежені латентністю sync.
Спостерігайте активність логу: Якщо SLOG уже є — перевірте, чи використовується. Якщо ні — оцініть потенційну користь, вимірявши латентність fsync зараз.
Виключіть очевидні пляшки: Насичення мережі, насичення CPU, scrub/resilver або один збійний диск можуть домінувати в симптомах.
Визначте позицію щодо довговічності: Підтвердіть, що вам потрібні коректні синхронні семантики. Якщо ні — задокументуйте це явно; не «випадково» працюйте небезпечно.

Чекліст: Вибір правильного пристрою SLOG

PLP обов’язковий: Обирайте пристрої з захистом від втрати живлення та корпоративною прошивкою.
Переважайте низьку латентність над великою ємністю: Мета — швидка, стабільна затримка flush.
Перевірте витривалість: Синхронні навантаження можуть писати постійно; переконайтеся, що TBW/DWPD підходять.
Уникайте шпильок продуктивності: Тестуйте під стабільним навантаженням; слідкуйте за термообмеженнями та сплесками GC.
Дзеркалення, якщо важлива коректність: Особливо для NFS VM-датасторів та критичних баз даних.

Покроковий план: Додавання SLOG безпечно в продакшн

Зніміть базову метрику: Захопіть перцентилі латентності з моніторингу і запустіть невеликий fsync-тест на наборі даних.
Підтвердіть шляхи пристроїв: Ідентифікуйте лог-пристрої через /dev/disk/by-id, щоб уникнути перемикання імен.
Додайте дзеркальний лог: Використовуйте zpool add POOL log mirror DEV1 DEV2.
Підтвердьте використання: Під час пікового синхронного навантаження перевірте записи на лог-vdev через zpool iostat -v.
Перезніміть базу: Запустіть той самий fsync-тест; порівняйте розподіли латентності, не лише середні значення.
Задокументуйте контракт: Запишіть, що «синхронні записи довговічні й захищені дзеркальним PLP SLOG», і опишіть процедури заміни.

Покроковий план: Якщо підозрюєте, що SLOG вам шкодить

Перевірте на помилки: zpool status -v і SMART-статус.
Перевірте латентність логу: zpool iostat -v -l POOL 5. Якщо чек логу високий — проблема є.
Розгляньте тимчасове видалення: У контрольованому вікні zpool remove POOL LOGVDEV і заміряйте поведінку. Це діагностика, не постійне рішення.
Замініть на правильне залізо: Якщо підтвердили, що SLOG — пляшка, замініть його на пристрій, призначений для синхронних навантажень.

Поширені питання

1) Чи робить додавання SLOG записи ZFS швидшими?

Лише синхронні записи. Воно покращує латентність операцій, які мають бути підтверджені як довговічні (fsync, O_SYNC, патерни з великою кількістю NFS commit). Саме по собі воно не підвищує оптову асинхронну пропускну здатність.

2) Чи SLOG — це те саме, що ZIL?

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

3) Якого розміру має бути SLOG?

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

4) Чи варто дзеркалити SLOG?

Якщо ви не хочете втратити підтверджені синхронні записи через відмову одного пристрою — так. Для VM-датасторів по NFS і критичних баз даних дзеркальний SLOG — звичне «за замовчуванням правильне» рішення.

5) Чи може SLOG зменшити write amplification на основному пулі?

По суті — ні. Він змінює місце збереження наміру запису, а не обсяг даних, які пул має зрештою записати. Він може зробити I/O-патерни основного пулу менш хаотичними, видаливши малі sync-записи з основних vdev-ів, що опосередковано допоможе, але не усуне навантаження.

6) У чому різниця між SLOG і L2ARC?

SLOG прискорює підтвердження синхронних записів. L2ARC — це вторинний кеш читань. Плутанина між ними поширена і дорога.

7) Чи коли-небудь прийнятно `sync=disabled`?

Тільки якщо ви готові втратити нещодавні транзакції при краху і явно прийняли цей ризик (і задокументували це). Багато внутрішніх «тимчасових» робочих навантажень можуть жити з цим. Більшість продакшн-баз даних і VM-датасторів не повинні.

8) Чому продуктивність погіршала після додавання SLOG?

Поширені причини: лог-пристрій має погану flush-латентність, він термально тротлиться, він за повільним шляхом контролера, або навантаження не синхронне і ви просто додали накладні витрати/складність. Заміряйте латентність лог-vdev через zpool iostat -l і перевірте, чи синхронні записи реально ним користуються.

9) Чи можна розділити пристрій і використовувати частину як SLOG?

Технічно можливо, але операційно ризиковано, якщо ви не дисципліновані. Спільні пристрої можуть створити конкуренцію та зв’язування відмов. Шлях sync хоче ізоляції і передбачуваності.

10) Які налаштування набору даних зазвичай поєднуються з SLOG для VM/NFS?

Зазвичай sync=standard (або always, якщо ваше середовище цього вимагає) і logbias=latency. Решта залежить від навантаження: recordsize, compression, atime і налаштування експорту NFS важливі, але вони не специфічні для SLOG.

Висновок

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

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

Схожі статті

Розмір SLOG у ZFS: скільки вам насправді потрібно (не «чим більше — тим краще»)