ZFS L2ARC на NVMe: коли це варто (а коли достатньо ARC)

December 9, 2025 • February 3, 2026 • Читання: 6 хв • Views: 12

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

ZFS має репутацію «магії», зазвичай сказану тим же тоном, яким люди говорять про еспресо-машини. Попадання в ARC швидке, контрольні суми заспокоюють, а снапшоти змушують виглядати компетентним у стресі. Потім ваше навантаження зростає, оперативна пам’ять перестає бути дешевою (або просто недоступною), і хтось пропонує: «Просто додайте L2ARC на NVMe».

Іноді це саме правильний крок. В інших випадках — дорожчий шлях до того самого результату, який ви б отримали, просто додавши RAM в ARC, виправивши recordsize або переставши читати ті самі 4 KB у шаблоні 1 MB. L2ARC не є універсальною кнопкою «зробити ZFS швидшим»; це дуже специфічний важіль з гострими краями.

Що таке L2ARC (і чого від нього не чекати)

ARC (Adaptive Replacement Cache) — це основний кеш ZFS, що живе в оперативній пам’яті. Він кешує дані (та метадані) і надзвичайно ефективний, бо затримки RAM мізерні, а ARC тісно інтегрований з I/O-пайплайном ZFS.

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

Чого L2ARC не є:

Не є кешем записів. Записи ZFS обробляються транзакційними групами, ZIL і (якщо є) SLOG-пристроєм. L2ARC допомагає читанням.
Не гарантія. Це кеш із політикою витіснення й поведінкою «прогріву», і після перезавантаження він може бути «холодним».
Не безкоштовний. Він споживає CPU і пам’ять для заголовків/індексації, генерує додаткові читання/записи на пристрої кешу і може відбирати смугу пропускання у пулу, якщо неправильно підібраний або використаний.

Дві фрази гумору, як обіцяно, і повернемося до професійного тону: додавання L2ARC, щоб виправити випадкові затримки читання — це як додати другий холодильник, щоб покращити готування: іноді допомагає, але тільки якщо у вас справді є, що зберігати. І ще: «кеш» — це єдине слово в ІТ, яке одночасно означає «швидше» й «складніше».

Цікаві факти та історичний контекст

ARC — не просто LRU. Він поєднує недавність і частоту за допомогою адаптивного алгоритму, що важливо, коли навантаження поєднує скани й «гарячі» множини.
L2ARC з’явився рано в житті ZFS. Його проєктували, коли SSD були меншими й витривалість була великим занепокоєнням, тому поведінка записів і регульовані параметри мають значення.
Ранні реалізації L2ARC не зберігалися після перезавантаження. Багато деплойментів жорстко дізналися, що перезавантаження могло «стерти» продуктивність до прогріву кешу.
Сучасний OpenZFS може зберігати L2ARC persistently. Персистентний L2ARC зменшує ефект «повільного понеділка після оновлення» — якщо його правильно налаштувати й підтримувати.
Кеш — це не лише дані. Метадані ZFS (dnode, непрямі блоки) часто дають непропорційний приріст продуктивності при кешуванні, особливо для великих дерев каталогів і образів віртуальних машин.
NVMe змінила економіку. Воно зробило «достатньо швидким, щоб діяти як кеш» значно дешевше й компактніше, але також легше наситити PCIe-лінії або отримати термічне тротлінгування пристроїв при тривалих записах.
Записи в L2ARC можуть бути безперервними. L2ARC наповнюється шляхом запису даних з потоків витіснення ARC; під тиском це може створювати стійке зношування пристрою і навантаження на смугу пропускання.
Стиснення змінює математику кешування. ARC/L2ARC зберігають стиснені блоки (коли увімкнено стиснення), фактично збільшуючи «ємність» кешу — про що багато таблиць розмірів забувають.

Чому ARC перемагає за замовчуванням

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

У продакшні я бачив більше виграшів у продуктивності від:

Додавання оперативної пам’яті (або запобігання її «викраданню» іншими сервісами)
Виправлення recordsize (і volblocksize для zvol)
Увімкнення стиснення (особливо lz4) для зменшення I/O
Виправлення sync-настроювань і правильне використання SLOG (для проблем із затримками запису)
Виділення метаданих на спеціальний vdev, коли навантаження важке на метадані

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

Коли L2ARC на NVMe виправданий

1) У вас є «тепла множина», більша за RAM, але менша за NVMe

Класичний приклад: хост віртуалізації з десятками ВМ, де «гарячі» блоки кожної ВМ не великі, але загальна гаряча множина — десятки або сотні ГБ. ARC не може втримати все, а пул знаходиться на HDD або насичених SSD. L2ARC на хорошому NVMe може підвищити IOPS читання й зменшити хвильові затримки.

2) Ваш пул повільний при випадкових читаннях

Якщо основний пул на HDD mirror/RAIDZ, випадкові читання коштують переміщень голівок. L2ARC може перетворити «штраф за випадкові читання» в «затримку читання NVMe», що суттєво покращує досвід при завантаженні ВМ, встановленні пакетів і CI-збірках із великою кількістю залежностей.

3) У вас багато CPU і ви чутливі до затримок

L2ARC не безкоштовний: він додає цикли CPU для перевірки контрольних сум, обробки стиснення й управління кешем. Якщо хост має запас CPU і навантаження карає хвильові затримки читання (p95/p99 важливі), L2ARC може бути вигідним компромісом.

4) Ви готові терпіти поведінку «прогріву» або маєте persistent L2ARC

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

5) Ваш додаток виконує повторні читання, а не лише стрімінг

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

Коли ARC достатньо (а L2ARC — відволікання)

1) Ваш пул вже на NVMe/SSD і не є вузьким місцем

Якщо пул — швидкі SSD і ваш додаток обмежений CPU або блокуваннями, L2ARC цього не виправить. Ви просто додасте ще один шар складності.

2) У вас немає запасу пам’яті

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

3) Проблема в записах, а не у читаннях

Якщо питання — затримка синхронних записів (бази даних, NFS із sync, шторми flush у ВМ), вам потрібен SLOG. Якщо проблема — пропускна здатність записів, дивіться на розкладку vdev, recordsize і смугу пристроїв. L2ARC тут мало що допоможе.

4) Ваша робоча множина практично «занадто велика для кешу»

Якщо активна множина — кілька терабайт, а пропонований L2ARC — 400 GB, це може не змінити коефіцієнт хітів. L2ARC корисний, коли він може утримувати значну частку повторно читаної множини.

Вибір NVMe-пристрою: нудні деталі, що мають значення

Для L2ARC потрібен пристрій, який може витримувати змішане випадкове читання й постійний потік записів без раптового падіння продуктивності, коли його SLC-кеш вичерпується. Побутові NVMe можуть виглядати відмінно в бенчмарках, а потім тротлитися або колапсувати під тривалими записами — саме такий сценарій може створити L2ARC при великому обігу в ARC.

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

Витривалість (TBW/DWPD) має значення. L2ARC може записувати постійно. Якщо ви додаєте його «щоб заощадити», не вибирайте пристрій, який швидко стане витратним ресурсом.
Захист від втрати живлення корисний. L2ARC — не журнал записів, але раптова втрата живлення може створити неприємні сюрпризи в поведінці пристрою, і персистентний L2ARC виграє від прогнозованої цілісності носія.
Терміка реальна. NVMe можуть тротлитися при тривалих записах. Якщо у сервера тісний потік повітря, L2ARC може ненароком стати обігрівачем із падінням продуктивності.
Не діліть пристрій з іншими інтенсивними I/O. «Кешовий NVMe», на якому також лежать логи, контейнери і база даних, швидко навчить вас про контенцію.

Розмір L2ARC: ємність, запас і очікування

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

Емпіричні правила, що витримують продакшн:

Починайте з малого. Скромний L2ARC (десятки до кількох сотень ГБ) може дати більшість вигоди без надмірних накладних витрат.
Краще більше RAM, ніж більше L2ARC. Якщо можна додати RAM — зробіть це спочатку. Попадання в ARC дешевше і передбачуваніше, ніж у L2ARC.
Вимірюйте коефіцієнт хітів і затримку, а не враження. L2ARC може зробити графіки «красивішими», поки p99 затримка залишається поганою через інше вузьке місце.
Очікуйте прогріву. Холодний кеш означає повернення до продуктивності пулу, поки навантаження не відтворить достатньо читань.

Регулювання, що дійсно впливає

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

Ключові поняття:

Feed rate: Швидкість, з якою L2ARC заповнюється евіктованими буферами ARC. Вища швидкість прогріває швидше, але збільшує навантаження на запис.
Політика допуску: Чи кешувати лише певні типи даних (метадані проти даних) і чи віддавати пріоритет часто використовуваним блокам.
Взаємодія з prefetch: Кешування предофрейджених даних може бути марнотратним при потокових навантаженнях.
Персистентний L2ARC: Корисний для середовищ з частими перезавантаженнями, але змінює поведінку імпорту та операційні очікування.

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

Міні-історія №1: Інцидент через неправильне припущення

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

Один інженер з добрими намірами запропонував L2ARC на NVMe. Припущення: «NVMe cache = швидші читання = проблема вирішена». Додали великий кеш-пристрій, і перший день був кращим — деякі завантаження пройшли швидше, служба підтримки заспокоїлася. Потім відбулося тижневе планове перезавантаження.

Після перезавантаження продуктивність впала. Не просто повернулася до бази — гірше. Хост почав трястися: ARC зменшився через обмеженість пам’яті, заголовки L2ARC з’їли більше RAM, ніж очікували, і кеш був холодним. Ранковий шторм завантаження вдарив по повільному пулу, черга гіпервізора виросла. Затримки зросли, і кілька ВМ відчули тайм-аути I/O. Менеджмент отримав інцидент-звіт, що починався словами «Нещодавно ми внесли зміну…» і закінчувався новим процесом погодження.

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

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

Платформа для обробки даних мала об’єктний сторедж на ZFS для проміжних артефактів. Читання були «достатньо випадкові», і хтось помітив, що ARC hit rate не вражає. Команда додала висококласний споживчий NVMe як L2ARC і вирішила «зробити це дійсно робочим», підвищивши feed rate і кешуючи агресивніше.

Через кілька днів NVMe почав видавати помилки медіа. SMART виглядав погано. Причина не була містичною: навантаження мало великий churn, пристрій постійно записувався, і поведінка тривалих записів під нагрівом не відповідала специфікації. Сервер не «падав», бо NVMe поганий; він падав, бо навантаження перетворило кеш у бігову доріжку записів.

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

Вони замінили пристрій на NVMe з підвищеною витривалістю, знизили feed і змінили політику допуску, щоб уникнути кешування потоків із великою кількістю prefetch. Важливіша зміна: визнали, що навантаження фундаментально стрімінгове, і змінили пайплайн, щоб зменшити повторні читання. L2ARC став скромною допомогою, а не основною стратегією.

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

Додаток у фінансовій сфері працював на ZFS, з жорсткими вікнами обслуговування і малою терпимістю до несподіванок. Команда хотіла L2ARC для великого довідкового набору даних, який багато разів запитували в робочі години. Вони зробили непопулярну річ: поетапно підхід.

Спочатку виміряли: розмір ARC, ARC hit ratio, промахи кешу, розподіл затримок читання і I/O пулу. Встановили базу під час піку і в тихий час. Потім додали невеликий L2ARC на серверний NVMe з гарною витривалістю. Без налаштувань спочатку; просто спостерігали.

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

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

Практичні завдання (команди + інтерпретація)

Команди нижче припускають Linux-систему з встановленим OpenZFS. Підлаштуйте шляхи під свій дистрибутив. Інтенція тут операційна: «запустіть це, прочитайте те, вирішіть далі».

Завдання 1: Ідентифікувати розклад пулу і поточні пристрої кешу

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

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            sda                     ONLINE       0     0     0
            sdb                     ONLINE       0     0     0
        cache
          nvme0n1                   ONLINE       0     0     0

errors: No known data errors

Інтерпретація: Підтверджує, чи існує L2ARC («cache» секція) і показує помилки. Якщо ви бачите read/write/cksum помилки на пристрої кешу — ставтесь до нього як до відмовного компонента, а не «лише кешу».

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

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

Інтерпретація: Якщо secondarycache=none, L2ARC не допоможе. Якщо primarycache=metadata, ви навмисно тримаєте ARC лише для метаданих — це робочий варіант для деяких навантажень, але він змінює очікування.

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

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep '^(size|c_max|c_min|memory_throttle_count)'
size                            4    34359738368
c_min                           4    8589934592
c_max                           4    68719476736
memory_throttle_count           4    0

Інтерпретація: Розмір ARC — поточне використання; c_max — це стеля. Ненульовий memory_throttle_count вказує, що ARC змушений зменшуватися через тиск по пам’яті — часто ознака того, що додавання L2ARC може нашкодити, якщо покращити накладні витрати.

Завдання 4: Виміряти ARC hit ratio проти промахів (швидка перевірка)

cr0x@server:~$ awk '
/^hits /{h=$3}
/^misses /{m=$3}
END{
  total=h+m;
  if(total>0) printf("ARC hit%%: %.2f\n", (h/total)*100);
}' /proc/spl/kstat/zfs/arcstats
ARC hit%: 92.14

Інтерпретація: Високий ARC hit% часто означає, що ARC уже працює добре. Якщо продуктивність усе ще погана, вузьке місце може бути не в кешуванні читань.

Завдання 5: Перевірити ефективність L2ARC (коефіцієнт хітів та розмір)

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep '^(l2_size|l2_hits|l2_misses|l2_read_bytes|l2_write_bytes)'
l2_hits                         4    1843200
l2_misses                       4    921600
l2_size                         4    214748364800
l2_read_bytes                   4    9876543210
l2_write_bytes                  4    45678901234

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

Завдання 6: Спостерігати поведінку ARC/L2ARC у реальному часі (one-liner)

cr0x@server:~$ sudo arcstat 1
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c  l2hits  l2miss  l2miss%  l2read  l2write
12:00:01   320    22      6     3   14    19   86     0    0   32G   64G     120      40       25     60M    280M

Інтерпретація: Дивіться, чи корелюють промахи з болючою затримкою й чи L2ARC суттєво зменшує промахи. Якщо L2ARC постійно пише під час вашої латентності, подумайте про зменшення feed/налаштування допуску.

Завдання 7: Підтвердити стан пристрою і зношування (NVMe SMART)

cr0x@server:~$ sudo nvme smart-log /dev/nvme0n1
Smart Log for NVME device:nvme0n1 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 48 C
available_spare                     : 100%
percentage_used                     : 7%
data_units_read                     : 12,345,678
data_units_written                  : 98,765,432
media_errors                        : 0
num_err_log_entries                 : 0

Інтерпретація: Швидке зростання percentage_used після додавання L2ARC — підказка, що ви перетворюєте NVMe на записове навантаження. Температура, що наближається до тротлінгу, — також червоний прапорець.

Завдання 8: Перевірити затримку читання на рівні пулу й мікс I/O

cr0x@server:~$ sudo zpool iostat -v tank 1 5
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  ----- -----  ----- -----
tank        3.20T  6.80T    850   220   85.0M  12.0M
  mirror-0  3.20T  6.80T    850   220   85.0M  12.0M
    sda         -      -    430   110   42.5M   6.0M
    sdb         -      -    420   110   42.5M   6.0M
cache                          -      -    200     0   20.0M   0.0M
  nvme0n1                      -      -    200     0   20.0M   0.0M

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

Завдання 9: Додати пристрій L2ARC безпечно

cr0x@server:~$ sudo zpool add tank cache /dev/nvme0n1

Інтерпретація: Це приєднує весь NVMe як кеш. У багатьох продакшн-налаштуваннях краще використовувати розділи й стабільні /dev/disk/by-id імена; все ж це основна дія.

Завдання 10: Видалити пристрій L2ARC безпечно

cr0x@server:~$ sudo zpool remove tank nvme0n1

Інтерпретація: Пристрої кешу можна видаляти. Якщо ви діагностуєте проблему або вибрали неправильний диск, видалення просте — не витягуйте пристрій без підготовки.

Завдання 11: Встановити політику dataset для того, що потрапляє в L2ARC

cr0x@server:~$ sudo zfs set secondarycache=metadata tank/datasets/vmstore
cr0x@server:~$ sudo zfs get secondarycache tank/datasets/vmstore
NAME                  PROPERTY        VALUE     SOURCE
tank/datasets/vmstore  secondarycache  metadata  local

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

Завдання 12: Перевірити й підкоригувати ліміти ARC (обережно)

cr0x@server:~$ sudo bash -c 'echo 68719476736 > /sys/module/zfs/parameters/zfs_arc_max'
cr0x@server:~$ cat /sys/module/zfs/parameters/zfs_arc_max
68719476736

Інтерпретація: Якщо у системи є RAM, але ARC штучно обмежений, підняття zfs_arc_max може дати кращий результат, ніж будь-який L2ARC. Не ставте так високо, щоб ядро й додатки постраждали від нестачі пам’яті.

Завдання 13: Перевірити вплив prefetch (на високому рівні)

cr0x@server:~$ cat /sys/module/zfs/parameters/zfs_prefetch_disable
0

Інтерпретація: Prefetch корисний для послідовних читань, але може забруднювати кеш при деяких шаблонах. Вимикати prefetch глобально рідко є першим кроком; замість цього розгляньте політику кешування на рівні dataset або налаштування допуску для L2ARC, якщо ваша імплементація це підтримує.

Завдання 14: Підтвердити стиснення й логічні vs фізичні читання

cr0x@server:~$ sudo zfs get -o name,property,value compressratio tank/datasets/vmstore
NAME                  PROPERTY       VALUE
tank/datasets/vmstore  compressratio  1.78x

Інтерпретація: Стиснення збільшує ефективну ємність кешу. Коєфіцієнт 1.78x означає, що ваші ARC/L2ARC зберігають менше фізичних даних для того самого логічного робочого набору.

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

Це послідовність «повільно і люди дивляться». Ви можете пройти її за 5–15 хвилин і отримати робочу гіпотезу.

Перше: Це читання чи запис?

cr0x@server:~$ sudo zpool iostat -v tank 1 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  ----- -----  ----- -----
tank        3.20T  6.80T    900   120   90.0M   8.0M

Інтерпретація: Якщо домінують записи й проблема в затримці — дивіться на sync-поведінку, SLOG, txg і fsync-шаблони додатків. L2ARC не перший відповідач тут.

Друге: Ми пропускаємо кеш чи пристрій є вузьким місцем?

cr0x@server:~$ awk '
/^hits /{h=$3}
/^misses /{m=$3}
/^l2_hits /{l2h=$3}
/^l2_misses /{l2m=$3}
END{
  total=h+m;
  l2total=l2h+l2m;
  if(total>0) printf("ARC hit%%: %.2f\n", (h/total)*100);
  if(l2total>0) printf("L2ARC hit%%: %.2f\n", (l2h/l2total)*100);
}' /proc/spl/kstat/zfs/arcstats
ARC hit%: 71.03
L2ARC hit%: 62.50

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

Третє: Чи сам NVMe-кеш є вузьким місцем?

cr0x@server:~$ sudo nvme smart-log /dev/nvme0n1 | egrep 'temperature|critical_warning|media_errors|percentage_used'
temperature                         : 72 C
critical_warning                    : 0x00
percentage_used                     : 31%
media_errors                        : 0

Інтерпретація: Висока температура може вказувати на тротлінг. Швидко зростаюче зношування натякає, що політика кешу занадто записоємна для класу пристрою.

Четверте: Чи тиск пам’яті саботує ARC?

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep '^(size|c_max|memory_throttle_count)'
size                            4    10737418240
c_max                           4    17179869184
memory_throttle_count           4    921

Інтерпретація: Якщо memory_throttle_count росте, ARC стискається. Додавання L2ARC у цьому стані часто погіршує ситуацію. Розгляньте додавання RAM, зменшення ARC cap лише при необхідності й виправлення реальних споживачів пам’яті.

П’яте: Переконайтеся, що ви не женетеся за неправильною проблемою

cr0x@server:~$ sudo iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          22.10    0.00    6.40    1.20    0.00   70.30

Device            r/s     w/s   rkB/s   wkB/s  await  %util
sda             55.0    12.0  6400.0  1100.0  18.2   92.0
nvme0n1        210.0    95.0 24000.0 33000.0   1.9   78.0

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

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

Помилка 1: Використовувати L2ARC для виправлення sync write latency

Симптом: Користувачі скаржаться на повільні коміти/транзакції; метрики показують сплески latency запису; метрики читання не є проблемою.

Виправлення: Оцініть sync-навантаження: розгляньте правильний SLOG-пристрій, перевірте налаштування sync (і чи дозволено їх змінювати) і профілюйте fsync-шаблони. L2ARC тут не має значення.

Помилка 2: Перерозмірення L2ARC на хості з малою RAM

Симптом: Після додавання кешу ARC зменшився, memory_throttle_count виріс, а загальна затримка погіршилась — особливо після завантаження.

Виправлення: Зменште або видаліть L2ARC, додайте RAM і підтвердьте, що ARC max/min розумні. Якщо зберігаєте L2ARC — зробіть його скромним і вимірюйте.

Помилка 3: Кешування потокових читань і заповнення L2ARC «сміттям»

Симптом: L2ARC write bytes швидко ростуть, L2ARC hit% низький, зношування NVMe збільшується, а виграш у продуктивності мінімальний.

Виправлення: Встановіть secondarycache=metadata для потокових dataset або інакше обмежте допуск; уникайте кешування prefetch-важких потоків, якщо можливо.

Помилка 4: Спільне використання L2ARC NVMe з іншими сервісами

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

Виправлення: Виділіть пристрій (або принаймні ізолюйте розділами й I/O controls). Пристрій кешу не повинен бути загальним scratch-диском у продакшні.

Помилка 5: Очікування миттєвого покращення після додавання L2ARC

Симптом: «Додали кеш і нічого не змінилося». Потім через дні — краще або гірше — залежно від churn навантаження.

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

Помилка 6: Ігнорування терміки NVMe і витривалості

Симптом: Тротлінг, раптові падіння продуктивності, стрибки SMART wear або помилки носія після «успішного» розгортання.

Виправлення: Використовуйте NVMe з витривалістю, забезпечте обдув, моніторьте температуру й зношування, і налаштуйте feed/admission L2ARC, щоб знизити інтенсивність записів.

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

Покроково: вирішуємо, чи потрібен L2ARC

Підтвердьте, що проблема — затримка читань/IOPS. Використовуйте zpool iostat і системні інструменти; не припускайте.
Виміряйте ефективність ARC. Якщо ARC hit% вже високий — зосередьтесь на іншому.
Оцініть розмір робочої множини. Навіть приблизно: «скільки даних перечитується під час пікового години?» Якщо це набагато більше, ніж допустимий NVMe — L2ARC не диво.
Перевірте запас RAM. Якщо хост обмежений пам’яттю — плануйте RAM спочатку.
Розгляньте політику кешування dataset. Якщо більшість читань потокові — L2ARC може нашкодити, якщо не обмежити до метаданих або гарячих піднаборів.
Оцініть альтернативи. Налаштування recordsize/volblocksize, стиснення, спеціальний vdev для метаданих або просто швидші vdevs можуть дати кращий ROI.

Покроково: безпечне розгортання L2ARC

Виберіть правильний NVMe. Витривалість і стійка продуктивність важливіші за яскраві бенчмарки.
Зняття базових метрик. Захопіть ARC/L2ARC stats, zpool iostat, розподіл затримок під час піку.
Додайте спочатку скромний пристрій кешу. Не починайте з «максимально великого».
Залиште дефолти на початку. Спостерігайте принаймні один робочий цикл (день/тиждень).
Перевірте поведінку після перезавантаження. Якщо продуктивність після перезавантаження неприйнятна — розгляньте persistent L2ARC або прийміть час прогріву.
Встановіть політику secondarycache на dataset. Особливо для відомих потокових dataset.
Моніторьте стан NVMe. Температура, зношування, помилки медіа; ставте алерти до несподіваних відмов.
Задокументуйте відкат. Практикуйте zpool remove і підтвердіть, що система поводиться очікувано.

FAQ

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

Ні. L2ARC призначений для читань. Якщо проблема — latency синхронних записів, дивіться в бік SLOG і вибору пристроїв. Якщо це пропускна здатність, перевіряйте розкладку vdev і смугу пристроїв.

2) Що краще купити: більше RAM чи NVMe для L2ARC?

Зазвичай більше RAM виграє. Попадання в ARC швидше і простіше, ніж у L2ARC, і RAM не вводить конфлікти по пристрою чи питання витривалості. L2ARC доречний, коли RAM практично не може вмістити робочу множину.

3) Якого розміру повинен бути L2ARC?

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

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

Поширені причини: тиск пам’яті, що зменшив ефективний ARC; заповнення L2ARC потоковими/pretech даними; контенція на пристрої кешу; NVMe, що не витримує шаблон записів і починає тротлитися.

5) Чи можна використовувати споживчий NVMe для L2ARC?

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

6) Кешувати лише метадані чи все?

Кешування тільки метаданих часто є «безпечним дефолтом» для змішаних навантажень або потокових dataset. Кешування всього може допомогти для ВМ і баз даних, але також збільшить churn і зношування, якщо шаблон доступу не є повторнопримінним.

7) Чи усуває persistent L2ARC прогрів?

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

8) Як дізнатися, що L2ARC дійсно використовується?

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

9) Чи те саме L2ARC і special vdev?

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

Висновок

L2ARC на NVMe може бути дієвим інструментом: він зменшує затримку читання і підвищує IOPS читання, коли ваша гаряча множина більша за RAM, а пул повільніший за NVMe. Але він не замінює ARC і не є універсальним рішенням для продуктивності.

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

Схожі статті

ZFS: використання NVMe як L2ARC — коли ARC замало