Розмір L2ARC у ZFS: коли 200 ГБ кращі за 2 ТБ

Ментальна модель: чим L2ARC справді є

ARC — це кеш першого рівня: у пам’яті, швидкий і ретельно оптимізований. L2ARC — це не «ARC на SSD». Це кеш другого рівня для блоків, які вже були в ARC і були викинуті. Ця деталь — ключова.

ARC і L2ARC вирішують різні завдання

ARC — це місце, куди ZFS прагне: він кешує нещодавно й часто використовувані блоки, метадані і адаптується між MRU (свіже) та MFU (часте) навантаженнями. Попадання в ARC дешево обходиться.

L2ARC — кеш-жертва. Він зберігає дані, яких ARC не зміг утримати. Отже, L2ARC допомагає лише коли:

• Ваш робочий набір більший за оперативну пам’ять, але все ще досить малий, щоб значимо вміститись в L2ARC.
• Існує повторне використання даних. L2ARC нічого не дає для одноразових читань.
• Штраф за промах по диску достатньо великий, щоб попадання в SSD суттєво покращувало латентність.

Ось чого люди забувають: L2ARC витрачає RAM на зберігання вказівників SSD

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

Також L2ARC не безкоштовно заповнюється. Він споживає I/O-пропускну здатність і CPU-цикли для запису в кеш-пристрій. При сильному «чарнінгу» (churn) це може перетворитись на самонанесений тиск.

Що ви фактично підбираєте за розміром

Коли ви «підбираєте розмір L2ARC», ви балансуватимете між:

• зростанням коефіцієнта промахів → попадань (наскільки читання уникають повільніших носіїв)
• скороченням ARC (RAM, витрачена на метадані L2ARC і на його підживлення)
• підсиленням записів (L2ARC fill-записи; плюс будь-які функції персистентності)
• профілем латентності (NVMe швидкий, але не безкоштовний; і не всі промахи рівнозначні)
• поведінкою при відмовах і відновленні (час прогріву кешу; проблеми після перезавантажень; втрата пристрою)

Ідея у вільній інтерпретації від Werner Vogels (CTO Amazon): Все ламається, весь час — проектуйте та експлуатуйте з цією реальністю.

Це стосується й кешів. L2ARC — оптимізація продуктивності. Ставтесь до неї як до прапора фічі з планом відкату.

Цікаві факти та трохи історії

Трохи контексту робить ручки менш містичними. Коротко, конкретно:

1. L2ARC з’явився на ранніх версіях Solaris ZFS як спосіб розширити кеш поза межі RAM, спочатку націлений на корпоративні флеш-пристрої.
2. ARC з’явився до сучасного тренду «page cache + складні політики»; ZFS побудував узгоджений кеш зі своєю логікою викидання замість повної опори на системний page cache.
3. Історично L2ARC був неперсистентним: перезавантаження означало холодний кеш і довгий прогрів; пізніша робота OpenZFS додала опції персистентності L2ARC на деяких платформах.
4. Ранні дизайни L2ARC обмежувались витривалістю SSD; підживлення L2ARC могло писати значно більше, ніж очікували.
5. Накладні витрати на метадані завжди були податком; коли ARC став розумнішим і більшим, L2ARC інколи виявлявся менш привабливим для загальних навантажень.
6. L2ARC кешує лише читання; він не прискорює синхронні записи (це вже зона SLOG, і там також нюанси).
7. Special vdev змінив правила гри: розміщення метаданих (і, за бажанням, малих блоків) на флеші може обіграти L2ARC, бо змінює місце зберігання, а не лише кешування.
8. NVMe зробив «великі L2ARC» доступними, через що частіше бачимо випадки, коли люди надто їх збільшують і виявляють удар по RAM/метаданих.

Чому 200 ГБ може виграти у 2 ТБ

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

1) У вашому робочому наборі є «гаряче ядро» і «холодний хвіст»

Більшість продакшн-навантажень саме такі. Думайте: піки завантаження VМ при старті проти довготривалих користувацьких даних; індекси баз даних проти історичних таблиць; артефакти збірок проти артефактів минулого тижня.

200 ГБ L2ARC, який вміщує гарячий хвіст ARC-викидів, може дати високий коефіцієнт попадань. 2 ТБ L2ARC може затягнути і холодний хвіст, марнуючи RAM-метадані та пропускну здатність підживлення. Коли так відбувається, ARC зменшується, гарячі метадані виходять з пам’яті, і ви втрачаєте найдешевші попадання.

2) L2ARC конкурує з ARC за RAM (опосередковано)

Продуктивність ZFS зазвичай залежить від пам’яті. Не «більше пам’яті — добре» в лозунговому сенсі — конкретно: чи вистачає вам ARC, щоб тримати метадані та гарячі блоки?

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

3) L2ARC має швидкість заповнення; величезні кеші не встигають

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

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

4) Не всі «попадання» рівнозначні

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

5) «Штраф випадкового читання» — це місце, де L2ARC виправдовує себе

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

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

Метод розрахунку розміру, що не спирається на відчуття

Якщо запам’ятати тільки одне правило: не розмірюйте L2ARC за розміром диска; розмірюйте його за виміряним повторним використанням і запасом RAM.

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

Почніть з трьох питань:

• Чи обмежені ми латентністю читань з пулу?
• Чи високі потрапляння ARC, але все одно недостатні, тобто робочий набір перевищує RAM?
• Чи є повторне використання в потоці викидів (тобто, чи L2ARC дійсно буде влучати)?

Якщо не можете це продемонструвати, стандартна рекомендація нудна: додайте RAM або виправте навантаження.

Крок 2: Оцініть «L2-гідний» робочий набір

Ви шукаєте блоки, які:

• Часто доступні, але не настільки часто, щоб залишатися в ARC під навантаженням
• Дорогі для отримання з пулу (випадкові читання на HDD або затримка віддалого SAN)
• Достатньо стабільні, щоб виграти від прогріву кешу

На практиці цей «L2-гідний» набір часто набагато менший за загальний розмір датасету. Це можуть бути 50–300 ГБ блоків ОС VM або кілька сотень гігабайт індексів БД, а не «всі 12 ТБ користувацьких файлів».

Крок 3: Переконайтеся в запасі RAM для метаданих ARC і заголовків L2ARC

Перевеликий L2ARC може позбавити ARC ресурсів. Ознака: розмір ARC перестає рости, промахи метаданих зростають, і система стає «смикливою» під навантаженням.

Працездатне правило: якщо ви вже боретесь з тиском на ARC, не додавайте L2ARC зараз. Спершу виправте пам’ять, перемістіть метадані на special vdev або зменшіть робочий набір.

Крок 4: Виберіть клас пристрою і витривалість свідомо

L2ARC пише. Не постійно, як журнал, але достатньо, щоб мати значення. Consumer QLC може підійти для скромних кешів із консервативним підживленням; він також може швидко вмерти під інтенсивним churn.

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

Крок 5: Почніть з малого, вимірюйте, а потім зростайте

Не встановлюйте 2 ТБ, бо була знижка. Встановіть 200–400 ГБ. Вимірюйте коефіцієнт попадань, латентність, поведінку ARC та навантаження на записи протягом тижня. Потім вирішіть, чи збільшувати.

Жарт №2: L2ARC наче корпоративний канал у Slack — корисний, коли кураторований, катастрофічний, коли всі скидають туди все підряд.

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

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

Завдання 1: Підтвердьте конфігурацію пулу та vdev (бо без цього нічого не має сенсу)

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 00:32:11 with 0 errors on Tue Dec 24 02:14:22 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
          nvme0n1                    ONLINE       0     0     0

errors: No known data errors

Значення: У вас RAIDZ2 на HDD з одним NVMe як кеш-пристрій. Випадкові читання на HDD дорогі, тож L2ARC може бути корисним.

Рішення: Якби це був повністю NVMe пул або дзеркальні SSD, я б скептично ставився до користі L2ARC і зосередився спочатку на ARC та навантаженні.

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

cr0x@server:~$ arc_summary | head -n 25
ARC Summary:
        Memory Throttle Count:        0
        ARC Size:                     22.5 GiB
        Target Size:                  24.0 GiB
        Min Size (Hard Limit):        8.0 GiB
        Max Size (High Water):        24.0 GiB
        Most Recently Used Cache Size: 7.1 GiB
        Most Frequently Used Cache Size: 13.8 GiB

Значення: ARC майже в межі. Це може бути нормально або ознакою обмеженості пам’яті.

Рішення: Якщо ARC закріплений на максимумі й ОС свопить або сервіси відчувають брак пам’яті, не додавайте L2ARC — додайте RAM або зменшіть ARC max лише як крайній захід.

Завдання 3: Виміряйте коефіцієнт попадань ARC і промахи даних

cr0x@server:~$ arcstat 1 5
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:01:01  8320   410      4   320    3    62    1    28    0   22G  23.8G
12:01:02  8011   398      4   310    3    59    1    29    0   22G  23.8G
12:01:03  8550   460      5   370    4    61    1    29    0   22G  23.8G
12:01:04  7902   402      5   322    4    55    1    25    0   22G  23.8G
12:01:05  8122   405      4   330    4    53    1    22    0   22G  23.8G

Значення: Промахи ARC ≈ 4–5%, промахи за даними домінують. Це не катастрофа. Чи допоможе L2ARC — залежить від вартості цих промахів.

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

Завдання 4: Перевірте наявність L2ARC і його коефіцієнт попадань

cr0x@server:~$ arc_summary | sed -n '60,110p'
L2ARC Summary:
        L2ARC Size:                           186.2 GiB
        L2ARC Evict Misses:                   0
        L2ARC Hits:                           1823124
        L2ARC Misses:                         9311042
        L2ARC Read Hit Ratio:                 16.4%
        L2ARC Writes:                         412019

Значення: Коефіцієнт попадань L2ARC ≈ 16%. На HDD-пулах це може бути суттєво, на SSD — менше.

Рішення: Якщо hit ratio у однозначних відсотках і пристрій зайнятий, зменшіть або видаліть L2ARC і займіться іншим. Якщо він >15–30% і читання спрощуються, тримайте й розгляньте помірне зростання.

Завдання 5: Перевірте поведінку підживлення L2ARC і чи не насичений пристрій

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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.12    0.00    3.21    1.02    0.00   85.65

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await wareq-sz  aqu-sz  %util
nvme0n1          820.0  89200.0     0.0   0.00    0.35   108.78   290.0  38100.0    1.90   131.38    0.80  48.00

Значення: NVMe не завантажений на повну (%util 48%). Добре. Якби був близько до 100% з високим w_await, підживлення L2ARC могло б шкодити.

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

Завдання 6: Підтвердьте, що пул — джерело латентності

cr0x@server:~$ zpool iostat -v tank 1 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        38.2T  12.1T  1400   520     180M  62.1M
  raidz2-0  38.2T  12.1T  1400   520     180M  62.1M
    sda         -      -   230    90    30.1M  10.2M
    sdb         -      -   240    85    29.8M  10.1M
    sdc         -      -   225    88    29.6M  10.3M
    sdd         -      -   235    86    30.2M  10.4M
    sde         -      -   240    86    30.5M  10.2M
    sdf         -      -   230    85    29.8M  10.1M
cache           -      -   710   260     86.0M  38.1M
  nvme0n1      -      -   710   260     86.0M  38.1M
----------  -----  -----  -----  -----  -----  -----

Значення: Пристрій кешу робить значні читання. Це L2ARC, який «платить оренду».

Рішення: Якщо «cache» показує майже нуль читань, а промахи високі, L2ARC не використовується (або не може прогрітися). Дослідіть churn, невідповідність recordsize або потокове навантаження.

Завдання 7: Виявляйте потокові читання, яким L2ARC не допоможе

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

Значення: Датасет кешує і в ARC, і в L2ARC, і має recordsize 128K. Великі послідовні сканування можуть знищити корисність кешу.

Рішення: Для потокових/резервних датасетів встановіть secondarycache=none (або навіть primarycache=metadata), щоб захистити кеш для даних, чутливих до латентності.

Завдання 8: Застосуйте політику кешу на рівні датасету (акуратно, вибірково)

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

Значення: Резервні читання не будуть засмічувати L2ARC. ARC може все ще кешувати залежно від налаштування primarycache.

Рішення: Робіть це, коли змішані навантаження і резервні/відновні роботи ламають показники кеша.

Завдання 9: Перевірте тиск на метадані і чи краще спеціальний vdev

cr0x@server:~$ arc_summary | sed -n '25,60p'
ARC Miscellaneous:
        Deleted:                            112.3 MiB
        Mutex Misses:                       0
        Demand Data Hits:                   51234123
        Demand Data Misses:                 9123421
        Demand Metadata Hits:               88123411
        Demand Metadata Misses:             923412

Значення: Промахи метаданих є, але не вибухові. Якби промахи метаданих були величезні і латентність стрибала під час обходів директорій/операцій VM, спеціальний vdev для метаданих міг би обіграти L2ARC.

Рішення: Якщо біль ваш — метадані (патерни типу VMFS, багато дрібних файлів, обходи директорій), розгляньте special vdev перед збільшенням L2ARC.

Завдання 10: Переконайтеся, що ви не плутаєте SLOG з L2ARC

cr0x@server:~$ zpool status tank | sed -n '1,25p'
  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
        logs
          nvme1n1                    ONLINE       0     0     0
        cache
          nvme0n1                    ONLINE       0     0     0

Значення: У вас окремий лог-пристрій (SLOG) і кеш-пристрій (L2ARC). Добре розділено.

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

Завдання 11: Перевірте, чи робоче навантаження саме читає (а не чекає блокувань чи CPU)

cr0x@server:~$ pidstat -dru 1 3
Linux 6.8.0 (server)  12/26/2025  _x86_64_  (32 CPU)

12:10:11      UID       PID  %usr %system  %wait    %CPU   CPU  kB_rd/s  kB_wr/s  Command
12:10:12      999     18322  2.00    0.50   15.00    2.50     6  1200.00   200.00  postgres
12:10:12        0      1421  0.10    0.20    0.00    0.30     2     0.00     0.00  zfs

Значення: Додаток показує %wait. Це може бути I/O wait, а може бути очікування блокувань залежно від стеку. Проте це сигнал корелювати з графіками сховища.

Рішення: Якщо CPU завантажений або додаток блокується, зміни розміру L2ARC не допоможуть. Не займайтесь «театром кешу».

Завдання 12: Спостерігайте реальну латентність I/O на рівні пристрою

cr0x@server:~$ iostat -x 1 3 sda
Device            r/s     rkB/s   r_await  w/s     wkB/s   w_await  aqu-sz  %util
sda              220.0   30100.0   18.20  85.0   10200.0   6.40     4.10   98.00
sda              235.0   31000.0   21.50  92.0   11000.0   7.10     4.80   99.00
sda              210.0   29000.0   16.80  80.0    9800.0   5.90     3.70   96.00

Значення: HDD насичений і read await високий. Якщо L2ARC може абсорбувати частину читань, ви знизите це.

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

Завдання 13: Підтвердьте стиснення і вирівнювання recordsize (ефективність кешу залежить від цього)

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

Значення: recordsize 16K для датасету бази даних; це може покращити локальність і корисність кешу для OLTP-патернів.

Рішення: Якщо ви кешуєте величезні 1M записи для випадкових читань, ви можете марнувати кеш. Налаштуйте recordsize під датасет.

Завдання 14: Швидко оцініть запас пам’яті

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           128Gi        41Gi        12Gi       1.0Gi        75Gi        78Gi
Swap:           16Gi       0.0Gi        16Gi

Значення: Достатньо доступної пам’яті; ARC може бути великим без голодування користувацьких процесів.

Рішення: Якщо доступної пам’яті мало і swap активний, виправте це спочатку. L2ARC не замінює RAM, коли ОС задихається.

Завдання 15: Базовий рівень записів L2ARC (перевірка витривалості)

cr0x@server:~$ sudo smartctl -a /dev/nvme0 | sed -n '1,80p'
SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        41 Celsius
Available Spare:                    100%
Percentage Used:                    3%
Data Units Read:                    18,240,112
Data Units Written:                 9,882,441
Host Read Commands:                 312,114,901
Host Write Commands:                210,441,022

Значення: «Data Units Written» росте з підживленням L2ARC і навантаженням. Слідкуйте за цим у часі.

Рішення: Якщо витривалість диска швидко з’їдається, зменшіть churn L2ARC (політики датасетів, менший L2ARC, кращий ARC) або використайте більш витривалий накопичувач.

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

Ви в інциденті. Немає часу на філософські дебати про кешування. Ось що перевірити спочатку, потім, щоб знайти вузьке місце без самообману.

Перше: чи це взагалі сховище?

• Перевірте завантаження CPU та чергу виконання. Якщо CPU завантажений, тюнінг сховища — відволікання.
• Перевірте очікування на рівні додатку (блокування БД, пули потоків). Графіки сховища можуть виглядати винними за асоціацією.

Друге: якщо це сховище — це читання, записи чи метадані?

• Читання: висока латентність читань на HDD vdev; зростає miss% в ARC; L2ARC читається значно.
• Синхронні записи: стрибки латентності корелюють з fsync; метрики SLOG і латентність пристрою важливі.
• Метадані: повільні обходи директорій; повільні операції VM; високі промахи метаданих; special vdev може допомогти більше.

Третє: чи кеш зараз допомагає чи шкодить?

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

Четверте: оберіть правильний важіль

• Додайте RAM, коли ARC обмежений і промахи метаданих болючі.
• Додайте чи налаштуйте L2ARC, коли промахи читань дорогі і дані повторно використовуються.
• Додайте special vdev, коли домінують метадані та малі блоки.
• Налаштуйте політики датасетів, коли резервні копії або скани засмічують кеш.
• Виправте навантаження, коли шаблони доступу патологічні (великі випадкові читання, невідповідний recordsize, необмежені скани).

Три короткі історії з практики

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

Компанія працювала віртуалізаційний кластер на ZFS-сервері: RAIDZ2 HDD для ємності, пара NVMe для «продуктивних речей». Команда вважала, що L2ARC — це фактично «більше RAM, але дешевше», тож вони вирізали більшу частину NVMe під багатотерабайтний L2ARC. Велике число — велика перемога, чи не так?

Місяць потому рутинне перезавантаження перетворилося на повільний аутедж. Після старту латентність VM була жахливою кілька годин. Не «трохи погано», а багато скарг від орендарів. Менеджмент запитав, чи команда змінювала щось у сховищі. Відповідь була «ні», технічно — правда, оперативно — марна.

Справжня причина: L2ARC тримав багато прогрітих блоків, від яких залежав робочий набір у бізнес-години. Перезавантаження стерло кеш. ARC самостійно не міг утримати набір. L2ARC дуже довго прогрівався, бо швидкість підживлення не встигала за churn. Ще гірше, під час прогріву він писав у кеш, споживаючи I/O, поки орендарі чекали на читання.

Виправлення не було героїчним. Зменшили L2ARC до кількох сотень гігабайтів, виключили резервні датасети з secondarycache і задокументували вікно прогріву після перезавантаження. Несподіваний результат: менший L2ARC дав стабільнішу продуктивність і коротший «постперезавантажувальний дискомфорт».

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

Інша команда хостила кластер баз даних на ZFS. Вони побачили промахи читання і вирішили «вкластися по повній»: величезний L2ARC, агресивні налаштування підживлення і новий NVMe лише під кеш. Графіки на день виглядали чудово. Коефіцієнт попадань виріс. Всі відчували себе розумними.

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

До того ж вони витрачали RAM на метадані L2ARC, що тихо зменшило здатність ARC тримати дійсно гарячі метадані. Більше промахів ARC. Більше дискового трафіку. Далі ви вже здогадуєтесь.

План відкату врятував: відключили агресивне підживлення, зменшили L2ARC і перемістили метадані на special vdev. Продуктивність повернулась до базової. З того часу вони ставились до L2ARC як до скальпеля, а не способу життя.

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

Медіа-платформа мала флотацію ZFS зі змішаними навантаженнями: завантаження користувачів, читання для транскодування, аналітичні скани та нічні бекапи. Вони ніколи не довіряли кешам безумовно. Було правило: кожен високопропускний датасет отримує явну політику кешу, а кожен диск кешу має моніторинг витривалості з оповіщенням.

Одного вечора аналітика змінила робочі завдання і почала великі сканування по датасету, що все ще мав secondarycache=all. Коефіцієнт попадань L2ARC впав, записи NVMe стрибнули, і інтерактивні навантаження відчули підвищену латентність. Система не впала; просто стало некомфортно.

On-call виконував їхній рукопис: перевірив arcstat, підтвердив churn L2ARC, ідентифікував датасет за розкладом навантаження і змінив політику датасету. Вони встановили secondarycache=none на аналітичному датасеті, primarycache залишили. За кілька хвилин L2ARC стабілізувався і інтерактивна продуктивність відновилась.

Без героїзму. Без «переробки сховища». Просто нудна гігієна: політики кешування на рівні датасету і спостереження за диском кешу як за продакшн-пристроєм — бо ним він і є.

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

1) Симптом: продуктивність погіршилась після додавання великого L2ARC

Корінь: Накладні витрати метаданих L2ARC і churn підживлення зменшують ефективний ARC і додають навантаження записами; кеш зберігає блоки з низьким повторним використанням.

Виправлення: Зменшіть L2ARC; виключіть потокові датасети (secondarycache=none); підтвердьте запас ARC; подумайте про додавання RAM замість L2ARC.

2) Симптом: коефіцієнт попадань L2ARC низький (однозначні відсотки) і не зростає

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

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

3) Симптом: відмінний коефіцієнт попадань L2ARC, але латентність не покращується

Корінь: Вузьке місце не в повільних читаннях (CPU, блокування, мережа, синхронні записи, фрагментація vdev). Або пул вже SSD-швидкий.

Виправлення: Корелюйте латентність додатку з r_await пристрою; перевірте SLOG для синхронних навантажень; перевірте CPU і планувальник; не купуйте кеш без потреби.

4) Симптом: після перезавантаження/відмови система повільна години

Корінь: Неперсистентний L2ARC (або неефективна персистентність) плюс надто великий кеш із повільним прогрівом; робочий набір залежить від кешованих блоків.

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

5) Симптом: NVMe кеш-накопичувач зношується швидше, ніж очікувалось

Корінь: Високий churn і постійні записи підживлення; L2ARC використовується як злив для холодних даних.

Виправлення: Зменшіть розмір кешу; вимкніть L2ARC для скануючих датасетів; виберіть диск з відповідною витривалістю; моніторьте SMART «Percentage Used» і тренди записаних байтів.

6) Симптом: списки директорій, операції VM і «малі IO» повільні

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

Виправлення: Розгляньте special vdev для метаданих/малих блоків; підтвердьте поведінку промахів метаданих; забезпечте достатньо RAM для метаданих в ARC.

7) Симптом: пристрій кешу завантажений на 100% з високою латентністю записів

Корінь: Підживлення L2ARC конкурує з читаннями; пристрій кешу надто малий/повільний для churn; агресивне підживлення.

Виправлення: Обмежте швидкість підживлення/налаштування де можливо; зменшіть L2ARC; перейдіть на швидший NVMe; зменшіть кількість eligible датасетів.

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

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

1. Медіа пулу: HDD-важка або бекенд з великою затримкою? Якщо так, L2ARC може допомогти. Повністю NVMe? Будьте скептичні.
2. ARC забитий і все ще є промахи: Підтвердьте, що ARC на/поблизу максимуму і що промахи мають значення.
3. Існує повторне використання: Підтвердьте, що навантаження повертається до тих самих даних (не суто стрімінг).
4. Запас RAM: Переконайтеся, що користувацьке середовище не свопить; ARC може дозволити собі накладні метадані.
5. Операційна толерантність: Чи готові ви до прогріву після перезавантаження? Якщо ні, тримайте L2ARC малим або плануйте персистентність.

Покроково: безпечне розмірювання L2ARC

1. Базова лінія протягом 7 днів. Захопіть: arcstat miss%, L2ARC hit%, латентність пристроїв пулу і завантаження пристрою кешу.
2. Встановіть політики датасетів. Спершу виключіть бекапи/скани з L2ARC (secondarycache=none).
3. Почніть з 200–400 ГБ. Краще «маленький і прогрітий», ніж «величезний і застарілий».
4. Переконайтесь, що він використовується. Перевірте zpool iostat — читання «cache» та коефіцієнт попадань L2ARC.
5. Слідкуйте за поведінкою RAM. Розмір ARC, промахи метаданих і доступність системної пам’яті.
6. Слідкуйте за витривалістю. Відстежуйте записи NVMe і «Percentage Used» з часом.
7. Збільшуйте лише за доказами. Якщо коефіцієнт попадань росте і латентність падає без голодування ARC — масштабуйтесь по кроках.
8. Майте план відкату. Можливість від’єднати пристрій кешу і швидко повернути політики датасетів.

Коли зупинитися при збільшенні L2ARC

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

FAQ

1) Чи варто L2ARC на повністю SSD або NVMe пулі?

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

2) Чому менший L2ARC прогрівається швидше?

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

3) Чи може L2ARC призвести до збільшення латентності навіть при кращому коефіцієнті попадань?

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

4) Чи варто купувати RAM замість L2ARC?

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

5) Чи допомагає L2ARC записам?

Ні. L2ARC — кеш читань. Якщо ваш біль — синхронні записи, дивіться на SLOG, налаштування sync і fsync-поведінку додатку.

6) Які налаштування датасету найбільше впливають на поведінку L2ARC?

secondarycache контролює право доступу до L2ARC. primarycache — право до ARC. recordsize впливає на гранулярність і ефективність кешу. Стиснення допомагає вмістити більше логічних даних на кешований обсяг.

7) Чи краще special vdev за L2ARC?

Різні інструменти для різних задач. Special vdev змінює розміщення метаданих (і, за бажанням, малих блоків), часто передбачувано покращуючи латентність для метаданих-важких навантажень. L2ARC кешує те, що ARC викинув. Якщо вузьке місце — метадані і малі випадкові читання, special vdev часто краще, ніж «ще L2ARC».

8) Який хороший цільовий коефіцієнт попадань L2ARC?

Чарівного числа немає. На HDD-пулах навіть 10–20% може бути великим виграшем, якщо це попадання по дорогим читанням. На швидких SSD-пулах вам може знадобитись значно більше, щоб виправдати накладні витрати. Завжди пов’язуйте це зі зниженням латентності і read await на HDD.

9) Як захистити кеш від бекапів і сканів?

Розмістіть їх в окремому(их) датасеті(ах) і встановіть secondarycache=none. Для особливо агресивних потоків розгляньте primarycache=metadata залежно від патернів доступу.

10) Що станеться, якщо пристрій L2ARC вийде з ладу?

ZFS продовжить працювати; це кеш-пристрій, а не сховище даних. Але відмова може створити операційний шум: помилки I/O, таймаути і зміни продуктивності в міру зникнення попадань кешу. Моніторьте та будьте готові акуратно від’єднати пристрій.

Висновок: практичні кроки далі

Якщо ви збираєтеся купити 2 ТБ «кешу», бо ваш ZFS-бокс «відчувається повільним», зупиніться. Спершу виміряйте. Найкращий розмір L2ARC рідко «якнайбільший». Це «настільки малий, наскільки потрібно, щоб захопити повторні промахи без крадіжки обіду у ARC».

Кроки, які можна зробити цього тижня

1. Запустіть arcstat у піковий час і корелюйте miss% з помітною для користувачів латентністю.
2. Перелікуйте датасети і позначте стримерів: бекапи, аналітичні скани, масові копії. Встановіть secondarycache=none для них.
3. Якщо у вас вже є L2ARC, перевірте коефіцієнт попадань і завантаження пристрою кешу. Якщо він має низький hit і високу зайнятість, зменшіть його.
4. Прийміть рішення: якщо ви обмежені пам’яттю, купіть RAM перед купівлею кешу.
5. Якщо метадані — ваша біда, плануйте special vdev замість великого L2ARC.

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