ZFS дає вам суперсилу: він перетворює вільну RAM в ARC, кеш для читання, який може зробити звичайні жорсткі диски підозріло здібними. Потім хтось помічає зайвий SSD, і починається розмова: zpool add ... cache ... — а далі вже згадується L2ARC.
Іноді L2ARC — це чистий виграш. Іншим разом це повільний інцидент: метання кешу, зношування SSD і бюджет пам’яті, який тихо випаровується на метадані. Це керівництво для продакшену, яке я б хотів, щоб усі прочитали перед тим, як натиснути zpool add ... cache ... у п’ятницю ввечері.
Що таке L2ARC насправді (і чим він не є)
L2ARC — це кеш читання другого рівня для ZFS. ARC живе в RAM. L2ARC — на швидких пристроях (зазвичай SSD/NVMe). Мета проста: коли ваш робочий набір не вміщується в RAM, тримайте «наступні за цінністю» блоки на SSD замість звертання до повільних дисків або віддаленого сховища.
Але L2ARC не чарівна галочка «зробити сховище швидшим». Він селективний. Він опортуністичний. У нього є накладні витрати. І у нього є характер.
Що таке L2ARC
- Кеш даних, які вже були прочитані (і, залежно від налаштувань та реалізації, іноді також префетчі або метадані).
- Підживлюється з ARC: блоки спочатку потрапляють в ARC, потім деякі промотяться в L2ARC.
- Найкорисніший, коли ваше навантаження має повторні читання, і робочий набір більший за RAM, але менший за RAM+L2ARC (і достатньо стабільний, щоб прогрітися).
Чим L2ARC не є
- Не є кешем для записів (це інша розмова про SLOG/ZIL).
- Не замінює RAM. ARC все ще виконує основну роботу, а L2ARC може споживати RAM для роботи.
- Не гарантує зниження латентності. Якщо вузьке місце — CPU, фрагментація, синхронні записи або мережа, L2ARC може нічого не дати — або додати нові проблеми.
Короткий жарт, як годиться: L2ARC — як абонемент у спортзал — приємно мати, але результати залежать від того, чи з’являєшся ти регулярно.
Факти та історія: чому L2ARC поводиться так, а не інакше
Трохи контексту допомагає. L2ARC не з’явився в еру доступних NVMe і гігантської RAM. Він народився в часи, коли «швидке» означало «кілька пристойних SSD і надія». Кілька конкретних фактів та історичних зауважень, що мають значення на практиці:
- ARC передував сучасній NVMe економіці. ARC розробляли так, щоб агресивно використовувати RAM, бо RAM була найшвидшим сховищем, яке можна було купити без спеціального погодження.
- L2ARC створювали як продовження ARC, а не як окрему систему кешування. Ось чому метадані ARC і політики сильно впливають на те, що потрапляє в L2ARC.
- Ранні версії L2ARC не були постійними після перезавантаження. Перезавантаження означало холодний кеш і тривале прогрівання. Пізніша робота OpenZFS ввела концепції персистентного L2ARC, але вам все одно треба перевірити поведінку на вашій платформі.
- Витривалість SSD колись була ключовим обмеженням. Кормлення L2ARC могло записувати багато даних. Старі SLC/SATA диски це витримували; дешеві споживчі TLC могли драматично вмерти, якщо використовувати їх як місце для логоподібного скидання.
- ARC адаптивний, але не всезнаючий. Він реагує на патерни доступу, які бачив; він не прогнозує ваш наступний пакетний джоб, ранковий шторм лінійок логінів чи квартальний аналітичний запуск.
- Метадані ZFS можуть домінувати в I/O на деяких навантаженнях. Якщо ви обходите директорії, робите бекапи або маєте churn образів ВМ, промахи по метаданих можуть завдати більше шкоди, ніж промахи по даних.
- Назва «кеш другого рівня» трохи вводить в оману. Це не класичний інклюзивний L2 CPU кеш. Блоки можуть бути і в ARC, і в L2ARC, і система платить накладні витрати, щоб це відстежувати.
- Сучасні альтернативи змінили дерево рішень. Спеціальні vdev для метаданих/малих блоків і швидші первинні vdev часто кращі за «додати L2ARC», особливо для пулів з випадковими операціями читання.
Як L2ARC працює під капотом
Будемо точними щодо шляху даних, бо більшість інцидентів з L2ARC починаються з нечіткого уявлення.
Шлях читання на практиці
Коли додаток просить блок:
- ZFS перевіряє ARC (RAM). Якщо збіг: найшвидше, робота завершена.
- Якщо промах в ARC, ZFS перевіряє, чи є блок в L2ARC (SSD). Якщо збіг: ви платите SSD-латентність і невеликий CPU-наклад, але уникаєте повільного диска або мережі.
- Якщо промах в L2ARC: ZFS читає з основних vdev (HDD/SSD), потім блок потрапляє в ARC. Пізніше він може бути записаний в L2ARC залежно від політики та швидкості підживлення.
Підживлення L2ARC не безкоштовне
L2ARC не наповнюється магією; його записують. Ці записи беруться з буферів, якими керує ARC, і регулюються параметрами, що обмежують агресивність записування в L2ARC. Це означає:
- Якщо ваше навантаження змінюється швидко, L2ARC може проводити час, кешуючи «новини вчорашнього дня».
- Якщо швидкість підживлення занадто агресивна, ви можете створити тиск записи, зношування SSD і CPU-наклад, одночасно вкравши простір ARC для заголовків/метаданих.
Проблема накладних витрат на RAM (те, що люди забувають)
Щоб бути корисним, L2ARC має знати, що на ньому є. Це відображення не зберігається повністю на SSD; ZFS тримає метадані в RAM, щоб швидко вирішувати, чи закешовано запитуваний блок і де він знаходиться.
Операційний переклад: великий L2ARC-пристрій може тихо споживати помітну кількість RAM. Якщо у вас вже не вистачає пам’яті, додавання L2ARC може зменшити ефективність ARC і збільшити метання елементів — перетворивши кеш читання на податкове навантаження на продуктивність.
Ефективність кешу залежить від локальності доступу
L2ARC працює найкраще, коли є «повторне використання»: ті самі блоки читають знову й знову протягом хвилин/годин/днів. Якщо ваше навантаження — одноразове сканування по набору даних (стрімінгові читання, бекапи, великі аналітичні запити), L2ARC здебільшого фіксує ваш шлях і потім забуває — після того, як стягне плату за «сувенірні фотографії».
Другий жарт, як годиться: у продакшені L2ARC невинний, поки не доведено протилежне, але у нього чудові адвокати і підозрілий звіт витрат.
Коли L2ARC допомагає (і що означає «допомагає»)
L2ARC не про те, щоб зробити ваші найшвидші читання ще швидшими. Він про те, щоб перетворити ваші найповільніші типові читання на просто «досить швидкі» читання. Кращі кандидати мають кілька спільних характеристик.
Підходить добре
- Навантаження з переважанням читання, де активний набір більший за RAM, але може вміститись у RAM+L2ARC.
- Стабільні робочі набори: шторм завантаження VDI, бінарні файли web/app серверів, шари образів контейнерів, що повторно використовуються, спільні бібліотеки на збіркових машинах, репозиторії пакетів.
- Чутливі до латентності випадкові читання з HDD-пулів, де кожен промах коштує мілісекунди.
- Середовища, де не можна додати достатньо RAM (вартість, слоти, обмеження платформи), але можна додати правильно підібраний і довговічний SSD.
Як виглядає успіх (вимірювано)
У реальних системах «L2ARC допоміг» зазвичай означає:
- Показник попадань ARC залишається високим, а показник попадань L2ARC має сенс (не просто шум).
- Кількість операцій читання з диска падає або латентність читання знижується при тому ж навантаженні.
- Хвостова латентність додатка покращується (p95/p99), а не лише середня пропускна здатність.
- Наклад CPU залишається прийнятним; ви не обміняли дискову латентність на час ядра.
Зауважте: користь може бути навіть при помірному рівні попадань
Якщо ваш пул базується на HDD, навіть помірний рівень попадань L2ARC може бути цінним. Замінити 10 ms випадкового читання на 100 µs–1 ms SSD-читання змінює форму черги і зменшує блокування голівок черги. Але треба перевірити: якщо система вже заблокована іншим вузьким місцем, ви просто перемістите винуватця.
Коли L2ARC шкодить: режими відмов
L2ARC не «шкодить», бо SSD повільні. Він шкодить, бо ви додаєте підсистему зі своїми ресурсними витратами, і ці витрати проявляються саме там, де ZFS чутливий: пам’ять, CPU і планування I/O.
Режим відмов 1: Тиск на пам’ять і крах ARC
Класичний випадок: ви додаєте великий L2ARC-пристрій на сервер, який і так працював нормально з ARC. Раптом хост починає свопити, ARC стискається, метання витіснень зростає, і все стає повільнішим — навіть читання, які раніше потрапляли в ARC.
Шаблон симптомів: більше page fault-ів, зростання системного CPU, коливання розміру ARC і стрибки латентності під навантаженням. Люди звинувачують «SSD», але зазвичай це економіка пам’яті.
Режим відмов 2: Метання кешу і нескінченне прогрівання
Якщо ваш робочий набір змінюється швидше, ніж L2ARC встигає адаптуватися, він стає музеєм блоків, які вас колись цікавили. Ви платите за підживлення і отримуєте мало попадань. Це часто трапляється при:
- Великих послідовних скануваннях
- Вікнах бекапів, що торкаються всього одноразово
- Великих аналітичних запитах, що лінійно проходять набори даних
- CI системах, що пропускають багато унікальних артефактів
Режим відмов 3: Записова ампліфікація SSD і передчасне зношування
L2ARC-пристрої записуються. Кеш постійно освіжається. При деяких навантаженнях обсяг записів може бути суттєвим. Якщо ви використаєте споживчий SSD з посередньою витривалістю і поганою поведінкою при стійких записах, ви можете отримати:
- Падіння продуктивності SSD після вичерпання SLC-кешу
- Фонове GC, що підсилює латентність
- Витрати витривалості, що перетворюються на дотичну заміну
Режим відмов 4: Інверсія латентності
Іноді L2ARC може додати «середню швидкість», яка повільніша за ARC, але все ж витрачає CPU та ресурси черг. Якщо ваш базовий пул вже SSD/NVMe і ARC достатній, попадання в L2ARC можуть бути повільнішими за добре налаштоване читання з пулу — особливо якщо пристрій L2ARC розділяє контролер, зайнятий або обмежений.
Режим відмов 5: Операційна складність, на яку ви не заклали час
Додавання L2ARC означає ще один клас пристроїв для моніторингу, заміни та планування ємності. Це також ускладнює аналіз продуктивності: тепер читання може походити з ARC, L2ARC або пулу, і вам потрібно знати, який шлях домінує опівночі.
Три корпоративні міні-історії з фронту
Міні-історія №1: Інцидент, спричинений неправильною передумовою («SSD cache = більше швидкості»)
Налаштування здавалося розумним: середній корпоративний файловий сервіс на RAIDZ2 HDD-пулі, багато клієнтів і постійна скарга, що понеділки повільні. Хтось додав великий SATA SSD як L2ARC на вихідних. Квиткова черга втихла приблизно на годину в понеділок. Потім панель моніторингу загорілася як ігровий автомат.
Латентність зросла. Системний CPU піднявся. Сервер почав свопити. Команда додатку наполягала: «але ми додали SSD, це має бути швидше». Тим часом графіки зберігання показували, що HDD-пул навіть не був завантажений; проблема була в тиску пам’яті і метанні reclaim. Заголовки L2ARC з’їли RAM, ARC звузився, і гарячі метадані перестали вміщатися. Система виконувала більше реального I/O, ніж раніше.
Неправильна передумова була тонкою: вони вірили, що L2ARC замінить звертання до диска без впливу на інші ресурси. Насправді L2ARC потребує RAM для індексації, і ця RAM була віднята у самого ARC, що робив систему терпимою. Коли ОС почала свопити, кожна «оптимізація» перетворилася на самонанесений відмову в обслуговуванні.
Виправлення було банальним: видалити L2ARC, додати RAM і вирішити реальну проблему — метадані під час сценаріїв логіну. Пізніша спроба використала набагато менший L2ARC-пристрій і налаштувала очікування. Великий виграш зрештою прийшов від зменшення метаданного шторму і переміщення найчастіше використовуваних малих файлів на швидше первинне сховище.
Міні-історія №2: Оптимізація, що відплатилася («Давайте кешувати активніше»)
Кластер віртуалізації мав datastore на ZFS. Читання були гострими: шторм завантаження, цикли патчування і випадкові «всі одночасно залогінилися» події. L2ARC встановили і він здався трохи корисним. Потім хтось вирішив налаштувати його агресивніше — швидше підживлення, великий пристрій і «кешувати більше речей». Графіки виглядали чудово під час першого тестового вікна — зазвичай це ознака дорогої помилки.
Через два тижні підтримка почала фіксувати періодичні стрибки латентності. Не постійні, не передбачувані. Команда гіпервізора звинуватила мережу. Мережа звинуватила зберігання. Зберігання звинуватило «невідоме». Єдиним постійним сигналом було те, що пристрій L2ARC інколи досягав 100% зайнятості в години піку, і сервер проводив дивно багато часу в ядрових потоках.
Відплата полягала в записовій ампліфікації і конкуренції. Інтенсивніше підживлення L2ARC збільшило запис на кеш-пристрій, який конкурував з легітимним I/O пулу в тому ж контролерному шляху. Внутрішній GC SSD почав проявлятися як джерело джіттера латентності. Система не була «повільнішою» у середньому; вона стала менш стабільною, що користувачі відчувають як «вона зламана».
Кінцеве рішення: зменшити налаштування, перемістити кеш-пристрій на менш навантажений шлях і пріоритезувати стабільну латентність над синтетичною пропускною здатністю. L2ARC залишився, але його почали використовувати як скальпель, а не як трактор.
Міні-історія №3: Сумна, але правильна практика, що врятувала день («Спочатку виміряй, змінюй один раз»)
Команда платформ даних хотіла L2ARC для аналітичного сервісу. Запит прийшов із відчуттям терміновості — скарги на продуктивність були гучні, і хтось уже замовив NVMe-диски. SRE на дзвінку зробив найменш захопливу річ: взяв базовий замір і відмовився його пропустити.
Вони зняли ARC-статистику, латентність пулу і p95 читань на рівні додатка під нормальною навантаженням і під відомою важкою задачею. Також перевірили, що біль проблеми — випадкові читання з холодих даних, а не насичення CPU або сусідська ВМ. Базовий замір показав несподіване: ARC вже добре працював, і більшість промахів були довгими послідовними читаннями, викликаними пакетними скануваннями. L2ARC кешував би вчорашні скани і був би марним сьогодні.
Замість розгортання L2ARC вони витратили бюджет NVMe на додавання спеціального vdev для метаданих і малих блоків у тестовому пулі, і підкоригували recordsize/compression для робочого навантаження. Це не було гламурно. Але скарги «повільний список директорій» і «перший запит жахливий» різко зменшилися, і система стала прогнозованішою під навантаженням.
Практика, що врятувала день, була не секретним тюнінгом. Це була дисципліна: виміряти фактичний тип промахів і потім вибрати механізм, що його вирішує. L2ARC чудовий, коли промах — «гарячі дані не вміщаються в RAM». Він посередній, коли промах — «ми скануємо все одноразово».
План швидкої діагностики
Це порядок дій «приходжу на інцидент». Мета — за хвилини виявити вузьке місце, а не виграти суперечку в Slack.
Крок 1: Чи це тиск на пам’ять або поведінка кешу?
- Перевірте свопінг/пейджинг і стабільність розміру ARC.
- Якщо система свопить, L2ARC підозрюваний до доказу зворотного.
Крок 2: Звідки читаються дані — ARC, L2ARC чи диск?
- Перегляньте показники попадань/промахів ARC/L2ARC і швидкості читань.
- Підтвердьте, чи L2ARC дійсно обслуговує читання (а не просто записується).
Крок 3: Чи сам пристрій L2ARC є вузьким місцем?
- Шукайте високу завантаженість, високий await або тротлінг на кеш-пристрої.
- Слідкуйте за стрибками латентності, що відповідають GC SSD.
Крок 4: Чи повільний базовий пул з іншої причини?
- Перевірте латентність I/O пулу і глибину черги.
- Шукайте фрагментацію, диск у нездоровому стані або проблему контролерного шляху.
Крок 5: Перевірте відповідність робочого навантаження
- Якщо це послідовні сканування, L2ARC рідко допоможе.
- Якщо це малі випадкові читання з повторним використанням, L2ARC може бути цінним.
Контрольні списки / покроковий план (з командами)
Ці завдання передбачають Linux з OpenZFS. Команди реалістичні, але деякі шляхи/файли залежать від дистрибутива та версії ZFS. Мета — повторювані операції: спостереження, рішення, зміна, перевірка.
Завдання 1: Перевірте стан пулу перед тим, як звинувачувати кеш
cr0x@server:~$ sudo zpool status -v
pool: tank
state: ONLINE
scan: scrub repaired 0B in 02:31:10 with 0 errors on Sun Dec 22 03:10:11 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
cache
nvme0n1 ONLINE 0 0 0
errors: No known data errorsІнтерпретація: Якщо пул не чистий, симптоми продуктивності можуть бути побічними ефектами (повтори, resilvering, checksum помилки). Виправте здоров’я перш за все.
Завдання 2: Підтвердьте пристрої L2ARC і спосіб їх підключення
cr0x@server:~$ sudo zpool list -v
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
tank 72.5T 51.2T 21.3T - - 28% 70% 1.00x ONLINE -
raidz2 72.5T 51.2T 21.3T - - 28% 70%
sda - - - - - - -
sdb - - - - - - -
sdc - - - - - - -
sdd - - - - - - -
cache - - - - - - -
nvme0n1 1.8T 820G 1.0T - - - -Інтерпретація: Пристрої L2ARC відображаються під cache. Якщо ви очікували дзеркальний кеш і бачите лише один пристрій — це ризик, на який ви могли не погоджуватись.
Завдання 3: Зробіть знімок «що відбувається зараз» на одному екрані
cr0x@server:~$ sudo zpool iostat -v tank 1 5
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
tank 51.2T 21.3T 1.20K 650 210M 95.4M
raidz2 51.2T 21.3T 1.20K 650 210M 95.4M
sda - - 310 160 54.0M 23.4M
sdb - - 280 170 48.9M 24.2M
sdc - - 320 150 56.1M 21.9M
sdd - - 290 170 51.0M 25.9M
cache - - 1.80K 0 290M 0
nvme0n1 - - 1.80K 0 290M 0
---------- ----- ----- ----- ----- ----- -----Інтерпретація: Якщо читання з кеш-пристрою високі, а читання з пулу низькі — L2ARC активно обслуговує. Якщо читання з кешу близькі до нуля, L2ARC не допомагає (або ще прогрівається, або навантаження не повторюється).
Завдання 4: Перевірте заголовні статистики ARC і L2ARC
cr0x@server:~$ grep -E "^(size|c_max|c_min|hits|misses|l2_hits|l2_misses)" /proc/spl/kstat/zfs/arcstats
size 4 68424495104
c_max 4 82463372032
c_min 4 10307921510
hits 4 12943923810
misses 4 1829381021
l2_hits 4 540128112
l2_misses 4 128925291Інтерпретація: ARC ≈ 68 GiB, max ≈ 82 GiB. L2ARC має попадання; тепер порахуйте, чи цей рівень попадань має значення для вашого вікна навантаження, а не для всього часу з моменту завантаження.
Завдання 5: Порахувати швидкі коефіцієнти попадань (ARC та L2ARC)
cr0x@server:~$ python3 - <<'PY'
import re
stats={}
with open("/proc/spl/kstat/zfs/arcstats") as f:
for line in f:
parts=line.split()
if len(parts)==3:
stats[parts[0]]=int(parts[2])
hits=stats.get("hits",0); misses=stats.get("misses",0)
l2h=stats.get("l2_hits",0); l2m=stats.get("l2_misses",0)
arc_total=hits+misses
l2_total=l2h+l2m
print(f"ARC hit ratio: {hits/arc_total:.3f} ({hits}/{arc_total})" if arc_total else "ARC: n/a")
print(f"L2ARC hit ratio: {l2h/l2_total:.3f} ({l2h}/{l2_total})" if l2_total else "L2ARC: n/a")
PY
ARC hit ratio: 0.876 (12943923810/14773304831)
L2ARC hit ratio: 0.807 (540128112/669053403)Інтерпретація: Високі сумарні коефіцієнти можуть вводити в оману, якщо навантаження змінилося. Перемірюйте дельти за 60–300 секунд під час проблемного періоду.
Завдання 6: Вибірка дельт ARC/L2ARC в часі (метод для реального інциденту)
cr0x@server:~$ for i in {1..5}; do
awk '($1=="hits"||$1=="misses"||$1=="l2_hits"||$1=="l2_misses"){print $1,$3}' /proc/spl/kstat/zfs/arcstats
sleep 2
done
hits 12943990112
misses 1829390029
l2_hits 540132882
l2_misses 128925900
hits 12944081201
misses 1829409110
l2_hits 540139551
l2_misses 128926499
hits 12944174500
misses 1829428800
l2_hits 540146002
l2_misses 128927101
hits 12944260110
misses 1829442301
l2_hits 540151774
l2_misses 128927690
hits 12944350990
misses 1829461988
l2_hits 540158441
l2_misses 128928291Інтерпретація: Порахуйте дельти між зразками. Якщо дельти L2ARC показують мало попадань і багато промахів, він не входить значно в шлях читання.
Завдання 7: Підтвердіть, що ви не свопите (тихий вбивця продуктивності)
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 128Gi 97Gi 2.1Gi 1.2Gi 29Gi 24Gi
Swap: 8.0Gi 1.6Gi 6.4Gi
cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
5 0 1652280 2211140 112000 23210400 12 28 3180 1200 5200 9800 12 18 55 15 0
6 1 1652280 1976200 111900 23180200 0 64 4020 990 5600 10100 10 22 50 18 0Інтерпретація: Ненульові значення swap-in/swap-out під час навантаження — червоний прапор. Якщо ви бачите стійкі si/so, вирішіть проблему пам’яті до налаштувань L2ARC.
Завдання 8: Визначте, чи насичений пристрій L2ARC
cr0x@server:~$ iostat -x 1 5
Linux 6.8.0 (server) 12/25/2025 _x86_64_ (32 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
11.20 0.00 18.90 14.30 0.00 55.60
Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s w_await aqu-sz %util
nvme0n1 1800.0 297000.0 0.0 0.00 1.40 165.0 40.0 8000.0 3.10 2.80 96.00
sda 300.0 54000.0 2.0 0.60 10.20 180.0 160.0 24000.0 9.50 5.10 88.00Інтерпретація: Якщо пристрій кешу стоїть близько до ~100% зайнятості з ростом await, він може стати вузьким місцем — особливо якщо попадання L2ARC домінують.
Завдання 9: Перегляньте L2ARC-пов’язані kstat для розміру і поведінки підживлення
cr0x@server:~$ grep -E "^(l2_size|l2_asize|l2_hdr_size|l2_write_bytes|l2_read_bytes|l2_writes_sent|l2_evicts)" /proc/spl/kstat/zfs/arcstats
l2_size 4 912345678912
l2_asize 4 1000204886016
l2_hdr_size 4 2147483648
l2_write_bytes 4 18765432109876
l2_read_bytes 4 7654321098765
l2_writes_sent 4 987654321
l2_evicts 4 123456789Інтерпретація: l2_hdr_size — це накладні витрати RAM для ведення обліку L2ARC. Якщо він становить кілька GiB і у вас немає запасу пам’яті, ваш «кеш» може платити за RAM за преміум-ставкою.
Завдання 10: Додати пристрій L2ARC безпечно (і перевірити)
cr0x@server:~$ sudo zpool add tank cache /dev/disk/by-id/nvme-SAMSUNG_MZQLB1T9HAJR-00007_S4XXXXXXXXX
cr0x@server:~$ sudo zpool status -v 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
cache
nvme-SAMSUNG_MZQLB1T9HAJR-00007_S4XXXXXXXXX ONLINE 0 0 0Інтерпретація: Завжди використовуйте стабільні шляхи пристроїв (by-id). Після додавання вам все одно потрібно перевірити, що пристрій обслуговує читання і не призводить до тиску пам’яті на хості.
Завдання 11: Видалити пристрій L2ARC під час усунення несправностей
cr0x@server:~$ sudo zpool remove tank nvme0n1
cr0x@server:~$ sudo 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
errors: No known data errorsІнтерпретація: Видалення L2ARC зазвичай безпечне, бо це кеш. Реальний ризик — падіння продуктивності, якщо ви насправді отримували вигоду. Використовуйте це як важіль для A/B тесту.
Завдання 12: Відрізнити L2ARC від SLOG (люди їх постійно плутають)
cr0x@server:~$ sudo zpool status -v tank
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
nvme1n1 ONLINE 0 0 0
nvme2n1 ONLINE 0 0 0
logs
mirror-1 ONLINE 0 0 0
nvme3n1 ONLINE 0 0 0
nvme4n1 ONLINE 0 0 0Інтерпретація: Пристрої під logs — це SLOG (для пришвидшення синхронних записів). Пристрої під cache — це L2ARC (кеш читання). Різні проблеми — різні виправлення.
Завдання 13: Спостерігайте за поведінкою на рівні dataset (compression, recordsize)
cr0x@server:~$ sudo zfs get -o name,property,value,source compression,recordsize,primarycache,secondarycache tank/vmstore
NAME PROPERTY VALUE SOURCE
tank/vmstore compression lz4 local
tank/vmstore recordsize 128K local
tank/vmstore primarycache all default
tank/vmstore secondarycache all defaultІнтерпретація: Якщо secondarycache=none, L2ARC не буде кешувати цей dataset. Це може бути свідомо (щоб уникнути забруднення кешу) або випадково (чому L2ARC марний?).
Завдання 14: Виключіть набори, що інтенсивно скануються, з L2ARC, щоб зменшити метання
cr0x@server:~$ sudo zfs set secondarycache=none tank/backups
cr0x@server:~$ sudo zfs get secondarycache tank/backups
NAME PROPERTY VALUE SOURCE
tank/backups secondarycache none localІнтерпретація: Це один з найбільш рентабельних налаштувань: не дозволяйте бекапам/сканам засмічувати L2ARC одноразовими читаннями.
Завдання 15: Підтвердіть TRIM-поведінку для SSD-кеш-пристроїв
cr0x@server:~$ sudo zpool get autotrim tank
NAME PROPERTY VALUE SOURCE
tank autotrim on localІнтерпретація: TRIM може допомогти стійкій продуктивності SSD. Чи вмикати — залежить від ваших SSD та версії ядра/ZFS, але «ніколи не вмикати» часто — успадкована інерція.
Завдання 16: Створіть швидкий бенчмарк до/після, який не брешить
cr0x@server:~$ sudo bash -c 'echo 3 > /proc/sys/vm/drop_caches'
cr0x@server:~$ sudo zpool iostat -v tank 1 3
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
tank 51.2T 21.3T 900 10 180M 1.2M
cache - - 20 0 2.0M 0
nvme0n1 - - 20 0 2.0M 0Інтерпретація: Скидання кешів — руйнівна дія і не відображає «реальне життя», але може показати, чи ваше навантаження взагалі потрапляє в L2ARC. Використовуйте обережно, бажано на тестовій системі або в контрольованому вікні.
Поширені помилки: симптоми та виправлення
Помилка 1: Використовувати L2ARC для виправлення проблеми запису
Симптом: Повільні синхронні записи, затримка комітів бази даних, NFS з sync страждає, але читання в порядку.
Виправлення: L2ARC не допоможе. Дослідіть SLOG, налаштування синхронності, латентність лог-пристроїв і патерни записів додатку. Підтвердіть командою zpool iostat і метриками навантаження.
Помилка 2: Додавання великого L2ARC-пристрою на хост з обмеженою пам’яттю
Симптом: Після додавання L2ARC розмір ARC падає, використання свапу зростає, CPU збільшується, латентність погіршується.
Виправлення: Видаліть або зменшіть L2ARC. Додайте RAM. Перевірте l2_hdr_size і пейджинг (vmstat). L2ARC не має бути «безкоштовним простором».
Помилка 3: Кешування наборів з інтенсивними скануваннями і «отруєння» кешу
Симптом: Записи в L2ARC великі, коефіцієнт попадань L2ARC низький, і продуктивність погіршується під час вікон бекапів/сканів.
Виправлення: Встановіть secondarycache=none для наборів, що скануються (бекапи, тимчасові аналітичні дані, одноразові ETL результати). Залиште L2ARC для повторного використання читань.
Помилка 4: Вибір неправильного SSD (споживчий диск, погане стійке записування, поганий firmware)
Симптом: Пристрій кешу показує періодичні стрибки латентності, продуктивність «добре, потім жахливо», індикатори зношування SSD швидко ростуть.
Виправлення: Використовуйте корпоративні SSD з прогнозованою QoS і адекватною витривалістю. Моніторьте SMART-показники зношування. Розгляньте оверпропершинування і TRIM.
Помилка 5: Очікування миттєвого покращення відразу після включення L2ARC
Симптом: «Ми додали L2ARC і нічого не змінилося».
Виправлення: L2ARC прогрівається з часом. Підтверджуйте дельти попадань/промахів під час навантаження. Якщо робочий набір не повторюється, він може ніколи не допомогти.
Помилка 6: L2ARC на вже швидких all-NVMe пулах без ясного вузького місця
Симптом: Немає відчутного виграшу, іноді трохи гірша латентність через накладні витрати.
Виправлення: Віддайте перевагу більшій RAM (більший ARC) або налаштуванню робочого набору/дейтасету. На дуже швидких пулах додатковий шар може бути зайвою складністю.
Питання та відповіді (FAQ)
1) Чи кешує L2ARC записи?
Ні. L2ARC — кеш читання. Записи йдуть у пул (і, можливо, у ZIL/SLOG для синхронної семантики). Якщо у вас проблема з латентністю записів — дивіться в інше місце.
2) Чому додавання SSD-кешу може погіршити продуктивність?
Тому що L2ARC має накладні витрати: споживає RAM для метаданих кешу, CPU для керування і I/O пропускну здатність для наповнення. Якщо ці витрати перевищують збережені звертання до диска — або спричиняють свопінг — продуктивність падає.
3) Якого розміру має бути мій L2ARC?
Достатньо великого, щоб вмістити «теплу, але не найгарячішу» частину робочого набору, але не настільки великого, щоб накладні метадані з’їли ваш RAM-бюджет. На продакшені правильний розмір зазвичай обмежується пам’яттю перш за все, а не ємністю SSD.
4) Як дізнатися, чи L2ARC дійсно використовується?
Подивіться zpool iostat -v на читаннях кеш-пристрою і перевірте дельти l2_hits у /proc/spl/kstat/zfs/arcstats під час вікна навантаження. Життєві статистики можуть вводити в оману.
5) Чи варто мені дзеркалити L2ARC-пристрої?
Зазвичай не обов’язково, бо це кеш і його можна відновити. Але якщо втрата кешу призводить до неприйнятного падіння продуктивності і час на заміну має значення — дзеркалювання може бути бізнес-рішенням. Операційно: розглядайте це як «резервування продуктивності», а не даних.
6) Чи існує персистентний L2ARC?
На деяких версіях OpenZFS і платформах — так, персистентні можливості існують. Але ви повинні перевірити поведінку на вашому стосі. Не припускайте «воно персистить», поки не протестували перезавантаження і не підтвердили прогрітий кеш.
7) У чому різниця між L2ARC і special vdev?
L2ARC — шар кешу для читання. Special vdev — частина пулу і може зберігати метадані (і за бажанням малі блоки) постійно на швидшому носії. Special vdev може радикально допомогти при навантаженнях, що залежать від метаданих, але він не є одноразовим: якщо ви втрачаєте його без редундансу, можете втратити пул.
8) Чи можна використовувати L2ARC на системі з обмеженою RAM?
Можна, але, ймовірно, не варто, якщо тільки L2ARC невеликий і ретельно перевірений. Найшвидший шлях до жалю — «додати великий L2ARC» на хості, що вже близький до межі пам’яті.
9) Чи варто вимкнути L2ARC для бекапів?
Часто — так. Бекапи зазвичай роблять великі послідовні читання з невеликим повторним використанням. Встановлення secondarycache=none для бекап-наборів — поширений спосіб запобігти забрудненню кешу.
10) Які метрики найважливіші при оцінці L2ARC?
Хвостова латентність додатку (p95/p99), дельти попадань/промахів ARC/L2ARC під час навантаження, латентність/IOPS пулу, завантаженість/латентність пристрою кешу, і індикатори тиску пам’яті (своп, поведінка reclaim).
Висновок
L2ARC — потужний інструмент з дуже конкретним завданням: рятувати навантаження з переважанням читання, чиї робочі набори не вміщаються в RAM, не сплачуючи повної ціни повільного первинного сховища. Коли він підходить під навантаження, він може згладити хвостову латентність і зменшити диск-треш таким чином, що користувачі помітять відразу.
Але L2ARC не «безкоштовна швидкість SSD». Це кеш, що коштує RAM, CPU і операційної уваги. Ставтеся до нього як до продакшен-інфраструктури: спочатку виміряйте, додавайте свідомо, захищайте від забруднення сканами і будьте готові видалити як контрольований експеримент. Якщо робити так, L2ARC поводитиметься як союзник. Якщо ні — поводитиметься як будь-яка інша «швидка оптимізація»: корисний до того моменту, як перетвориться на інцидент.