ZFS L2ARC на SATA SSD: коли це має сенс

Що таке L2ARC насправді (і чого воно не є)

Кешування в ZFS починається з ARC: кеш у пам’яті, який зберігає дані й метадані. ARC швидкий, адаптивний і опортуністичний.
Коли ARC замалий для вашого робочого набору, ZFS може розширити його на другий рівень: L2ARC, зазвичай на SSD.

Що таке L2ARC

• Кеш читання для блоків, що випали з ARC. Це не «чарівний шар SSD». Це другий шанс віддати читання без звернення до обертових дисків.
• Постійне зберігання кешованих блоків, індексованих ARC. SSD тримає блоки; у пам’яті зберігається індекс (заголовки), який вказує ZFS, що знаходиться на SSD.
• Краще для повторних читань. Якщо ваш робочий навантаження не перечитує блоки, L2ARC перетворюється на бігову доріжку записів з малою віддачею.

Чого L2ARC не є

• Не є кешем запису. Це зона SLOG для синхронних записів, і навіть там — для журналювання намірів, а не «прискорення записів» загалом.
• Не заміна оперативної пам’яті. ARC живе в RAM і виконує основну роботу. L2ARC — доповнення, а не заміна.
• Не ліки від поганого дизайну пулу. Якщо ваша топологія vdev не підходить для випадкових читань, L2ARC може на короткий час маскувати симптоми, але хвороба залишиться.

Найбільш неправильно зрозумілий аспект L2ARC — накладні витрати на RAM. Ви не отримуєте «1 ТБ кешу безкоштовно», тільки тому що SATA SSD дешеві.
Індекс L2ARC споживає пам’ять, і голодний ARC, щоб наповнити L2ARC, — це як пропустити сніданок, щоб купити ширший пояс.

Цитата, яку варто мати на увазі під час налаштування кешів: «Сподівання — не стратегія.» — Vince Lombardi.
Вона застосовна й до продуктивності зберігання, тільки з більшою кількістю iostat.

Цікаві факти та історія (бо контекст змінює рішення)

1. ARC з’явився до нинішньої культури «кешувати все» в хмарі. ZFS постачався з ARC у середині 2000-х, коли RAM була дорогою й могла змусити досвідчених інженерів плакати.
2. L2ARC був розроблений для повільних дисків. Ранні розгортання ZFS часто були на SATA HDD; L2ARC був практичним пластирем для випадкових читань без перебудови пулу.
3. Спочатку L2ARC прогрівався повільно після перезавантаження. Ранні версії вимагали повторного заповнення кешу після кожного рестарту; пізніший OpenZFS додав фічі для швидшого відновлення стану L2ARC (залежно від платформи).
4. L2ARC «записується» під час підживлення, за замовчуванням не дублюється. Якщо ви втратите кеш-пристрій, цілісність даних не постраждає; продуктивність просто повернеться до базової.
5. ARC може агресивно кешувати метадані. Для багатьох робочих навантажень кешування метаданих (обходи каталогів, пошук малих файлів) визначає відчутну швидкість.
6. Зараз у ZFS є кілька ролей «швидкого зберігання». L2ARC, SLOG, special vdev і навіть таблиці дедупації кожен вимагають різних властивостей SSD.
7. SATA SSD звузили розрив по пропускній здатності, але не по затримці. Інтерфейс SATA лімітує пропускну спроможність і має вищі затримки, ніж NVMe; L2ARC часто чутливий до затримок.
8. L2ARC може збільшити частку читань, що обробляються швидко, але також і записи загалом. Підживлення кешу — це записувальне навантаження, на яке ви підписуєтесь добровільно.

Жарт №1: Додавати L2ARC, щоб виправити повільний пул — це як поставити турбіну на розвізний фургон з квадратними колесами. Воно буде гучати. Але щастя не принесе.

Коли L2ARC на SATA SSD має сенс

L2ARC на SATA SSD варто застосовувати, коли одночасно виконуються три умови:
(1) навантаження орієнтоване на читання, (2) робочий набір не вміщується в ARC, та (3) достатньо RAM, щоб тримати індекс L2ARC без викидання корисного ARC.
Якщо щось із цього відсутнє, ви в основному купуєте складність.

Навантаження, які зазвичай виграють

• Читальні штормі у віртуалізації: багато VM одночасно завантажуються або оновлюються, багаторазово звертаючись до схожих OS-блоків і спільних бібліотек.
• Аналітика/BI панелі: повторні сканування одних і тих самих наборів даних, часто в пікові години.
• Веб/додатки з великою кількістю читань коду: холодні деплої можуть трясти систему, але в steady-state часто перечитуються ті самі бінарні файли і шаблони.
• Файлові сервери з «гарним» спільним контентом: CAD-бібліотеки, артефакти збірок, спільні тулчейни, які багато клієнтів читають повторно.

Сигнали, що ви кандидат

• Дискові операції читання (IOPS) високі і в основному випадкові.
• Показник хітів ARC пристойний, але обмежений через те, що робочий набір більший за RAM.
• Затримка читання — ваш обмежувач, не CPU, не мережа, не синхронні записи.
• Ваш L2ARC-пристрій може витримати записи без швидкого зносу або тротлінгу під навантаженням підживлення кешу.

L2ARC на SATA SSD також може бути хорошим «тимчасовим» рішенням у корпоративній реальності: часто можна швидше додати пару SATA SSD, ніж отримати бюджет на «перебудову пулу з іншими vdev» або «перейти на NVMe».
Просто не плутайте «швидко впровадити» з «архітектурно правильно».

Коли це не допоможе (і що робити натомість)

Не допоможе, якщо ви прив’язані до записів

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

Робіть натомість: оцініть SLOG для латентності синхронних записів; додайте vdev для IOPS запису; налаштуйте recordsize; перевірте sync-настройки та fsync у додатку.

Не допоможе, якщо навантаження — одноразове проходження

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

Робіть натомість: додайте RAM (більший ARC), додайте більше шпинделів/vdev, або перемістіть гарячий датасет на спеціальний vdev чи в швидкий пул.

Не допоможе, якщо вузьким місцем є топологія пулу

Один RAIDZ vdev із великими HDD чудово підходить для ємності, але не для випадкових IOPS. L2ARC може зменшити випадкові читання, але не змінить фундаментальну здатність пулу обробляти промахи.
Якщо рівень промахів залишається високим, ви все одно живете з латентністю HDD.

Робіть натомість: переробіть план vdev (більше vdev, mirror для IOPS), або розмістіть дійсно «гарячі» дані на SSD/NVMe.

Не допоможе, якщо у вас брак пам’яті

Якщо ARC вже стискається через брак пам’яті (контейнери, JVM, бази даних або просто замало RAM), L2ARC може погіршити продуктивність через додаткові накладні витрати. Система буде жонглювати кешами замість обслуговування читань.

Робіть натомість: додайте RAM першочергово. ARC зазвичай — найдешевший і найшвидший приріст продуктивності у світі ZFS.

Жарт №2: L2ARC на хості, що голодний до пам’яті, — це як орендувати склад, бо в домі безлад. Ключі ви все одно не знайдете.

Як L2ARC працює на практиці: прогрів, підживлення та промахи

Життєвий цикл кешованого блоку

Блок читається. Якщо він використовується достатньо часто, ARC тримає його. Коли ARC потребує місця, деякі блоки викидаються.
Викинуті блоки стають кандидатами для L2ARC: ZFS може записати їх на SSD, щоб майбутні читання потрапляли в L2ARC замість диска.

Це означає дві важливі реальності:

• L2ARC наповнюється через викиди з ARC. Якщо ARC ніколи не заповнюється, L2ARC залишається переважно бездіяльним. Якщо ARC активно міняється, L2ARC підживлюється агресивно.
• Час прогріву має значення. Ви не додаєте L2ARC і негайно перемагаєте. Кеш потребує часу, щоб заповнитися потрібними блоками, і це вимагає реального робочого часу.

Прогрів після перезавантаження: практичний біль

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

Підживлення L2ARC коштує I/O

ZFS записує в L2ARC у фоновому режимі. Це — пропускна здатність запису на SSD, плюс навантаження на CPU і пам’ять для обліку.
Якщо SSD — споживчий SATA з поганою стабільною продуктивністю запису і агресивним термічним тротлінгом (так, деякі SATA диски так роблять),
кеш може стати самообмежуваним: він не зможе приймати нові блоки достатньо швидко, щоб залишатися корисним.

Затримка важливіша за пропускну здатність

Попадання в L2ARC уникає затримок HDD. Чудово. Але затримка SATA SSD все ще значно вища за ARC. Тому L2ARC слід розглядати як «швидше за HDD, повільніше за RAM».
Якщо ваше навантаження надзвичайно чутливе до затримки (бази даних, інтерактивні системи) і промахи часті, вам можуть знадобитися NVMe або більше RAM.

Розмір і вибір SATA пристрою без сорому

Почніть з нудного правила: додайте RAM перед L2ARC

Хіти ARC — золота стандарта. Додавання RAM збільшує ARC без додаткових I/O-витрат і з мінімальною складністю. Якщо можете додати RAM — зробіть це спочатку.
L2ARC — для випадку, коли RAM уже «розумна», а робочий набір все одно не вміщується.

Якого розміру має бути L2ARC?

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

Практично:

• Мале й ефективне краще за велике й бездіяльне. Почніть з приблизно 5–10× розміру вашого ARC для L2ARC лише якщо у вас є RAM-голова і доведене повторне читання робочого набору.
• Слідкуйте за накладними витратами й хіт-рейтом. Якщо частка хітів L2ARC низька, більший розмір цього не виправить; він просто стане більшою дорогою машиною промахів.

Вибирайте SATA SSD так, ніби його будуть знущати (бо так і буде)

L2ARC записується постійно в багатьох робочих навантаженнях. Споживчі SATA SSD підходять для легкого кешування, але в продакшені часто є слабким місцем:
обмежена витривалість записів, непередбачувана поведінка при тривалих записах, коли SLC-кеш вичерпано, і мікрокодні особливості.

Що вам треба:

• Захист від втрати живлення (PLP), якщо можливо. Це не про цілісність даних (кеш є змінним), а про уникнення дивної поведінки під час раптових відключень живлення.
• Стабільна тривала продуктивність запису. Не пікові бенчмарки; дивіться на стабільні довготермінові записи.
• Витривалість, відповідна до швидкості підживлення. Якщо ваш кеш записує сотні ГБ/день, плануйте витривалість відповідно.
• Теплова стабільність. SATA SSD заштовханий за передньою панеллю без повітряного потоку буде тротлитися і саботувати ваш хіт-рейт.

Один пристрій чи два?

L2ARC-пристрої зазвичай не дзеркаляться. Втрата L2ARC — це не подія втрати даних; це подія продуктивності.
Якщо ваша платформа підтримує кілька кеш-пристроїв, розподіл L2ARC на два SSD може підвищити пропускну здатність і зменшити навантаження на один диск.
Більш важливе запитання — операційне: чи можете ви швидко виявити відмову і замінити пристрій без драм.

Не плутайте L2ARC зі special vdev

special vdev (де підтримується/використовується) може зберігати метадані і малі блоки на SSD, що може радикально покращити роботу з дрібними файлами.
Але це не «кеш». Воно стає частиною пулу; якщо воно помре і не є надмірним, можна втратити дані. Це інший клас зобов’язання.
L2ARC задуманий як відкидний шар.

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

Коли продуктивність погана, часу на філософські дискусії про кеш немає. Потрібно швидко знайти вузьке місце.
Ось порядок дій, який дає відповіді за хвилини, а не дні.

1) Підтвердіть, який саме біль: затримка читання, затримка запису, CPU чи пам’ять

• Перевірте затримки та завантаження пулу I/O.
• Перевірте розмір ARC і тиск на викиди.
• Перевірте, чи навантаження багато синхронних записів.

2) Якщо вузьке місце — затримка читання, визначте, промахи це кешу чи повільні хіти

• ARC hit ratio високий? Ймовірно, вам не потрібен L2ARC; потрібні CPU, прискорені контрольні суми або налаштування додатку.
• ARC hit ratio помірний/низький і диски зайняті? Кандидат на збільшення ARC, L2ARC або переробку пулу.
• L2ARC hit ratio низький після прогріву? Навантаження не перечитує дані; не продовжуйте підживлення даремно.

3) Якщо розглядаєте L2ARC, перевірте поведінку SSD при тривалих записах

• Подивіться на швидкість підживлення L2ARC і пропускну здатність запису SSD.
• Перевірте SMART-показники зносу і лічильники помилок.
• Підтвердіть, що SSD не насичує SATA-контролер або не ділить лінії з іншими пристроями.

4) Пере-тестуйте під тим самим вікном навантаження

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

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

Суть цих завдань проста: ви запускаєте команду, читаєте вивід і приймаєте рішення. Ніякої містики. Усі приклади для Linux з OpenZFS.
Замініть імена пулів/датасетів під своє середовище.

Завдання 1: Визначити, чи пул обмежений затримкою читання

cr0x@server:~$ zpool iostat -v tank 2 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        12.3T  7.10T    980    140  92.1M  10.8M
  raidz2-0                  12.3T  7.10T    980    140  92.1M  10.8M
    sda                         -      -    160     25  15.1M   2.0M
    sdb                         -      -    165     23  15.3M   1.9M
    sdc                         -      -    162     24  15.2M   2.0M
    sdd                         -      -    161     22  15.1M   1.8M
    sde                         -      -    165     23  15.2M   1.9M
    sdf                         -      -    167     23  15.2M   1.9M
--------------------------  -----  -----  -----  -----  -----  -----

Що це значить: Операції читання домінують. Якщо користувачі скаржаться на повільні читання і диски зайняті, кеш може допомогти.
Рішення: Продовжуйте перевірки ARC/L2ARC; не кидайтесь одразу до SLOG.

Завдання 2: Перевірити затримку безпосередньо (тест «це диски?»)

cr0x@server:~$ iostat -x 2 3
Linux 6.6.0 (server)  12/26/2025  _x86_64_  (24 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.12    0.00    2.04    9.55    0.00   82.29

Device            r/s     w/s   rMB/s   wMB/s  avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda             128.0    20.1    15.1     2.0    136.5     8.20   58.2   60.1   46.3   7.6   99.5
sdb             131.2    19.4    15.3     1.9    135.9     8.05   56.7   59.0   44.8   7.4   99.1

Що це значить: Await ~55–60ms і %util ~99% вказують на насичення дисків. Класичний біль від випадкових читань на HDD vdev.
Рішення: Якщо навантаження перечитує дані, L2ARC може зменшити звернення до дисків; інакше потрібні додаткові vdev або швидше сховище.

Завдання 3: Перевірити розмір ARC і тиск

cr0x@server:~$ arcstat 2 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c  avail
12:01:10  9820  2810     28   420    4  2390   24    95    1   38G   48G   12G
12:01:12 10110  3120     30   455    4  2665   26    98    1   38G   48G   11G
12:01:14  9905  3010     30   440    4  2570   26    92    1   38G   48G   11G

Що це значить: ARC ~38G з ціллю (c) 48G; рівень промахів ~28–30% — суттєво.
Рішення: Якщо можна збільшити RAM — робіть це. Якщо ні, L2ARC може допомогти — далі перевірте, чи робочий набір перечитується і чи L2ARC вже присутній.

Завдання 4: Перевірити, чи є L2ARC і як він поводиться

cr0x@server:~$ arcstat -f time,read,miss,arcsz,l2hits,l2miss,l2read,l2asize 2 3
    time  read  miss  arcsz  l2hits  l2miss  l2read  l2asize
12:02:20  9820  2810   38G     620    2190    6200     480G
12:02:22 10110  3120   38G     700    2420    7100     480G
12:02:24  9905  3010   38G     655    2355    6600     480G

Що це значить: L2ARC присутній (l2asize 480G). L2-хіти є, але не домінують.
Рішення: Якщо l2hits зростають під час навантаження і дискові читання падають — L2ARC допомагає. Якщо l2hits практично нуль після годин/днів — ймовірно, марно.

Завдання 5: Підтвердити наявність L2ARC-пристрою в ZFS

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 05:22:11 with 0 errors on Sun Dec 21 03:10:12 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
            sde                     ONLINE       0     0     0
            sdf                     ONLINE       0     0     0
        cache
          ata-SAMSUNG_SSD_870_EVO_1TB_S6PNNX0R123456A  ONLINE       0     0     0

errors: No known data errors

Що це значить: SSD підключено як cache-пристрій.
Рішення: Якщо ви усуваєте несправність — тепер знаєте, який фізичний пристрій перевіряти (SMART, кабелі, контролер).

Завдання 6: Додати SATA SSD як L2ARC (обережно)

cr0x@server:~$ sudo zpool add tank cache /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_1TB_S6PNNX0R123456A
cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
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
            sde                     ONLINE       0     0     0
            sdf                     ONLINE       0     0     0
        cache
          ata-SAMSUNG_SSD_870_EVO_1TB_S6PNNX0R123456A  ONLINE       0     0     0

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

Завдання 7: Перевірити, чи стискає пам’ять (L2ARC може погіршити це)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           128Gi        96Gi       2.1Gi       1.2Gi        30Gi        18Gi
Swap:           16Gi       3.5Gi        12Gi

Що це значить: Доступна пам’ять лише 18Gi, swap використовується. ARC може конкурувати з додатками.
Рішення: Якщо є свопування під навантаженням, додавання L2ARC — червоний прапор. Виправити спочатку тиск пам’яті (RAM, розподіл навантажень, обмеження ARC).

Завдання 8: Перевірити ліміти ARC (щоб ZFS не з’їв весь хост)

cr0x@server:~$ cat /sys/module/zfs/parameters/zfs_arc_max
68719476736
cr0x@server:~$ cat /sys/module/zfs/parameters/zfs_arc_min
17179869184

Що це значить: ARC max 64GiB, min 16GiB (значення в байтах).
Рішення: На хостах зі змішаним використанням обмежте ARC, щоб залишити простір. Якщо додаєте L2ARC, вам може знадобитися ще більше вільної пам’яті, а не менше.

Завдання 9: Перевірити підживлення L2ARC/поведінку записів (чи не б’є по SSD?)

cr0x@server:~$ grep -E "l2arc_write|l2arc_feed" /proc/spl/kstat/zfs/arcstats | head
l2arc_write_bytes                        4    982374982374
l2arc_write_issued                        4    1293847
l2arc_feed_calls                          4    9182
l2arc_feed_bytes                          4    982374982374

Що це значить: L2ARC записав ~982GB (з моменту завантаження/підключення модуля). Якщо це число швидко росте, питання витривалості та тротлінгу стають реальними.
Рішення: Якщо швидкість підживлення велика і хіт-рейти слабкі — відключіть L2ARC або зменшіть агресивність підживлення (де доступні налаштування), протестуйте.

Завдання 10: Перевірити стан SSD і знос (реалії SATA SSD)

cr0x@server:~$ sudo smartctl -a /dev/sdg | egrep "Model Number|Power_On_Hours|Media_Wearout|Percentage Used|Total_LBAs_Written|Reallocated|CRC_Error"
Model Number:                       Samsung SSD 870 EVO 1TB
Power_On_Hours:                    12890
Percentage Used:                   12%
Total_LBAs_Written:                1823749821
Reallocated_Sector_Ct:             0
UDMA_CRC_Error_Count:              0

Що це значить: «Percentage Used» — індикатор зносу; CRC-помилки можуть вказувати на проблему з кабелем/контролером.
Рішення: Якщо знос швидко зростає або з’являються CRC-помилки — ставтеся до кеш-пристрою як до компоненту під стресом і плануйте заміну або зміну стратегії.

Завдання 11: Підтвердити швидкість SATA-лінку та режим (щоб уникнути сорому 1.5Gbps)

cr0x@server:~$ sudo smartctl -a /dev/sdg | egrep "SATA Version|SATA.*current"
SATA Version is:  SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)

Що це значить: SSD працює на 6.0 Gb/s. Якщо показує 1.5 або 3.0 — контролер/кабель/бекплейн обмежують його.
Рішення: Виправте лінк перед остаточним судженням про продуктивність L2ARC.

Завдання 12: Виміряти, чи переходять читання з HDD на L2ARC (до/після)

cr0x@server:~$ zpool iostat -v tank 2 2
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        12.3T  7.10T    420    150  38.0M  11.5M
  raidz2-0                  12.3T  7.10T    420    150  38.0M  11.5M
    sda                         -      -     70     26   6.0M   2.0M
    sdb                         -      -     71     25   6.1M   1.9M
    sdc                         -      -     70     26   6.0M   2.0M
    sdd                         -      -     69     25   5.9M   1.9M
    sde                         -      -     70     24   6.0M   1.8M
    sdf                         -      -     70     24   6.0M   1.8M
--------------------------  -----  -----  -----  -----  -----  -----

Що це значить: Якщо навантаження подібне, падіння HDD читань з ~980 ops до ~420 ops свідчить про те, що кеш-хіти збільшилися (ARC і/або L2ARC).
Рішення: Коруйте це з латентністю додатку. Якщо користувачі відчувають покращення — залишайте. Якщо ні — не оголошуйте перемогу лише по лічильниках зберігання.

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

cr0x@server:~$ zfs get -o name,property,value -s local,default recordsize,primarycache,secondarycache,compression tank/vmstore
NAME          PROPERTY        VALUE
tank/vmstore  recordsize      128K
tank/vmstore  primarycache    all
tank/vmstore  secondarycache  all
tank/vmstore  compression     lz4

Що це значить: secondarycache=all дозволяє L2ARC кешувати і дані, і метадані (згідно з політикою ZFS).
Рішення: Для деяких робочих навантажень установка secondarycache=metadata може зменшити записи на SSD, зберігаючи швидкість для пошуку файлів.

Завдання 14: Обмежити, що потрапляє в L2ARC для «галасливого» датасету

cr0x@server:~$ sudo zfs set secondarycache=metadata tank/backups
cr0x@server:~$ zfs get -o name,property,value secondarycache tank/backups
NAME          PROPERTY        VALUE
tank/backups  secondarycache  metadata

Що це значить: Датасет backup припинить засмічувати L2ARC об’ємними даними; метадані все ще можуть кешуватися.
Рішення: Використовуйте це, коли один «холодний» датасет витісняє корисні блоки для інтерактивних навантажень.

Завдання 15: Видалити пристрій L2ARC (для відкату)

cr0x@server:~$ sudo zpool remove tank ata-SAMSUNG_SSD_870_EVO_1TB_S6PNNX0R123456A
cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
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
            sde     ONLINE       0     0     0
            sdf     ONLINE       0     0     0

Що це значить: Кеш-пристрій видалено чисто.
Рішення: Якщо L2ARC не покращив латентність у реальному вікні навантаження — видаліть його і припиніть платити операційний податок.

Три корпоративні міні-історії з реального світу

1) Інцидент через хибне припущення: «SSD кеш = все швидше»

Середня компанія працювала на кластері NFS на ZFS для домашніх директорій і CI-артефактів. Ємність була RAIDZ2 з великими HDD.
Розробники скаржилися на «випадкову повільність», особливо під час великих збірок і коли ранери тягнули артефакти.

Доброзичливий інженер додав споживчий SATA SSD як L2ARC на кожному вузлі. Ніхто не вимірював; чекали похвал.
Що отримали — повільний інцидент: через кілька днів SSD почали показувати підвищену латентність і випадкові ресети.
Збірки стали повільнішими, і NFS-клієнти почали тайм-аутитись, що спочатку виглядало як мережна проблема, поки не стало очевидно інакше.

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

Виправлення було прозаїчне: прибрати L2ARC, додати RAM і винести артефактний стор в mirror vdev, спроектований під IOPS, а не під ємність.
Команда також встановила secondarycache=metadata для бекап-датасету, який забруднював ARC/L2ARC під час нічних завдань.

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

2) Оптимізація, що обернулась проти: «Зробимо L2ARC величезним»

Внутрішня аналітична платформа працювала на ZFS. У команди була поважна кількість RAM і помічені промахи ARC під час ранкового напливу панелей.
Вони додали пару великих SATA SSD як L2ARC і вирішили «піти ва-банк», бо SSD дешеві за ГБ.

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

Негативний ефект виник через накладні витрати пам’яті й чурнінг. Система тепер тримала значно більший індекс L2ARC в RAM, що зменшило ефективний ARC.
Під піком навантаження викиди з ARC зросли, підживлення L2ARC збільшилось, і SATA SSD дісталися до межі тривалих записів.
Кеш-панель почала поводитися як затор на з’їзді: все сповільнилось, бо занадто багато намагалось увійти.

Команда виправила ситуацію, звузивши амбіції: обмежили датасети, які можуть використовувати L2ARC (знову ж, secondarycache), і перестали вважати L2ARC дешевою заміною кращого vdev-дизайну.
Пізніше вони мігрували читально-важкі датасети на NVMe mirror і залишили SATA SSD для менш чутливих ролей.

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

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

Регульоване підприємство мало платформу ZFS для кількох внутрішніх сервісів. Вони хотіли покращити читальну продуктивність для VM-датастора на HDD-мірарорах.
Закупівлі йшли повільно, тому інженер запропонував SATA SSD L2ARC як тимчасове підсилення.

Перед впровадженням вони зробили три нудні речі: зняли базову латентність під піком, записали статистику ARC/L2ARC (L2ARC ще не було),
і підготували план відкату з конкретною командою zpool remove і вікном змін.
Також попередньо перевірили SMART та підтвердили узгоджену швидкість SATA на контролері.

Зміна пройшла чисто. Два тижні метрики показували явний зсув: HDD-чити впали під час boot-штормів, і p95 латентності додатку покращився помірно, але стабільно.
Потім виявився баг у прошивці моделі SSD (не фатальний, але неприємний) і пристрій іноді зникав під важкими записами.

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

Ніхто не отримав трофей за «операційну чистоту». Але ніхто не чергував вночі з pager’ом, а це — справжній приз.

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

1) Симптом: L2ARC hit ratio практично нуль після днів роботи

Причина: Навантаження не перечитує блоки, або датасети не допускаються до L2ARC через налаштування secondarycache, або кеш забруднюється стриминговими робочими навантаженнями.

Виправлення: Перевірте поведінку повторних читань; встановіть secondarycache=metadata для стримингових датасетів; розгляньте видалення L2ARC і додавання RAM або vdev замість нього.

2) Симптом: Система стала повільнішою після додавання L2ARC

Причина: Тиск пам’яті (ARC зменшений через накладні витрати індексації L2ARC), плюс додаткові записи SSD для підживлення кешу.

Виправлення: Додайте RAM або зменшіть конкуренцію за ресурси; обмежте ARC; обмежте використання L2ARC для окремих датасетів; розгляньте менший L2ARC або відмову від нього.

3) Симптом: SSD кеш пристрій швидко показує високий знос

Причина: Високий темп підживлення L2ARC через чурний ARC; споживча SATA витривалість не підходить.

Виправлення: Оберіть SSD з вищою витривалістю; зменшіть підживлення, обмеживши датасети; віддайте пріоритет зростанню ARC; розгляньте NVMe для тривалих навантажень, якщо це справді необхідно.

4) Симптом: Періодичні I/O-паузи під час піку

Причина: Тротлінг SATA SSD або насичений SATA-контролер; підживлення кешу конкурує з читаннями; прошивка SSD під час тривалих записів.

Виправлення: Перевірте поведінку при тривалих записах; підтвердіть швидкість лінку; розподіліть кеш по різних пристроях/контролерах; обирайте SSD зі стабільними тривалими записами і PLP.

5) Симптом: Відмінні синтетичні бенчмарки, але жодного реального покращення

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

Виправлення: Вимірюйте під реальним піком; очищайте тестові артефакти; оцінюйте кінцеву латентність додатка і зменшення дискових операцій, а не тільки лічильники кешу.

6) Симптом: Після перезавантаження продуктивність погана «доки не стане кращою»

Причина: Прогрів L2ARC; вміст кешу не відразу корисний або не відновлюється; ARC холодний старт.

Виправлення: Плануйте перезавантаження на малонавантажені вікна; прогрівайте кеш, попередньо завантаживши поширені датасети, якщо можливо; не оцінюйте ефективність L2ARC одразу після рестарту.

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

Чек-лист рішення: чи варто додавати SATA L2ARC?

1. Чи біль головним чином — затримка читання? Якщо ні — стоп. L2ARC не виправить проблеми, пов’язані із записами.
2. Чи диски насичені під час проблемного вікна? Якщо ні — можливо, обмежувачем є CPU/мережа/додаток.
3. Чи значно високий промах ARC? Якщо ARC вже домінує в хітах, L2ARC навряд чи щось змінить.
4. Чи навантаження перечитує дані? Якщо ні — L2ARC стане витратою ресурсів.
5. Чи маєте запас RAM? Якщо є свопування — не додавайте L2ARC.
6. Чи можете виміряти до/після? Якщо ні — ви займаєтесь перформанс-театром.

План впровадження (безпечний, відкатний)

1. Зніміть базу: zpool iostat, iostat -x, arcstat під час піку.
2. Виберіть SSD: віддавайте перевагу витривалості і стабільним тривалим записам над маркетингом.
3. Перевірте апаратний шлях: правильний контролер, узгоджена 6.0 Gb/s, пристойне охолодження.
4. Додайте L2ARC через zpool add tank cache ....
5. Чекайте прогріву під реальним навантаженням; не оцінюйте через 10 хвилин.
6. Порівняйте: дискові читальні операції/латентність і p95/p99 додатку.
7. Якщо допомагає — обмежте галасливі датасети через secondarycache.
8. Якщо не допомагає — видаліть через zpool remove і рухайтесь далі.

Операційний чек-лист (щоб не було сюрпризів)

• Моніторте знос SSD щомісяця (SMART).
• Сповіщайте при зникненні кеш-пристрою або лінкових помилках (CRC).
• Документуйте, що кеш — відкидний, щоб ніхто не панікував під час заміни.
• Пере-тестуйте продуктивність після великих змін у навантаженні (нова версія додатку, нові запити, нова VM-флот).

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

1) Чи прискорює L2ARC записи?

Ні. L2ARC — кеш читання. Для латентності синхронних записів дивіться на SLOG, і навіть це — про журналювання, а не про прискорення всіх записів.

2) Чи додавати L2ARC перед додаванням RAM?

Майже ніколи. RAM збільшує ARC без додаткових затримок пристроїв, фонових записів або нових точок відмови. Якщо можете додати RAM — зробіть це спочатку.

3) Чи підходить споживчий SATA SSD для L2ARC?

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

4) Як дізнатися, чи моє навантаження перечитує дані?

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

5) Чи зберігається L2ARC після перезавантаження?

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

6) Чи слід дзеркалити L2ARC-пристрої?

Зазвичай ні. L2ARC відкидний; при відмові пристрою ви втрачаєте кеш, а не дані. Якщо втрата кешу спричиняє неприйнятні падіння продуктивності, реальне рішення — більше ARC або швидше первинне сховище.

7) Чому L2ARC показує активність, а користувачі не відчувають швидкості?

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

8) Чи можна обмежити, які датасети використовують L2ARC?

Так. Використайте secondarycache для кожного датасету (наприклад, metadata для стримингових/бекап-датасетів), щоб уникнути засмічення L2ARC холодними об’ємними даними.

9) SATA SSD чи NVMe для L2ARC?

NVMe виграє в затримці та паралелізмі. SATA може допомогти, коли ви замінюєте промахи HDD на «достатньо швидкі» SSD-хіти за низьку ціну, і ваше навантаження не супер-чутливе до затримки.

10) Альтернатива L2ARC для робочих навантажень з малими файлами?

special vdev (з надмірністю) може зберігати метадані і малі блоки на SSD, часто даючи більший приріст, ніж L2ARC для навантажень, орієнтованих на метадані. Але це не відкидний шар; проєктуйте його як реальний сховищний ресурс.

Наступні кроки, які можна виконати вже сьогодні

1. Запустіть швидкий план діагностики під піком і запишіть, чи ви обмежені затримкою читання, запису, CPU чи пам’яттю.
2. Зніміть базові заміри: iostat -x, zpool iostat -v, arcstat хоча б 10 хвилин під час болючого вікна.
3. Якщо ви кандидат, додайте SATA SSD L2ARC з чітким планом відкату і вікном вимірювань, достатнім для прогріву.
4. Зробіть це нудним: моніторте SMART-знос, сповіщайте про помилки пристрою і робіть налаштування кешу для датасетів свідомо.
5. Якщо L2ARC не покращить латентність користувача, видаліть його. Вкладайте час і гроші в RAM, дизайн vdev або переміщення гарячого датасету на швидше сховище.

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