Налаштування ZFS ARC: обмеження, межі та що слід вимірювати

За замовчуванням ZFS непомітно забирає приблизно половину оперативної пам’яті вашої системи для свого кешу читання, а на невідповідному сервері це може призвести до активності файлу підкачки, завершення процесів через нестачу пам’яті (OOM) або до конкуренції між базою даних та файловою системою за пам’ять. Налаштування ARC у ZFS полягає у визначенні, скільки саме оперативної пам’яті ARC фактично може утримувати, та чого доведеться пожертвувати, щоб встановити цей ліміт. У цій статті розглядається, як ARC використовує пам’ять, що слід виміряти, перш ніж щось змінювати, кілька параметрів, які варто змінити, а також розумні початкові налаштування для файлових серверів, гіпервізорів, баз даних та цільових систем резервного копіювання. Щодо знімків ZFS дивіться наш посібник зі знімків ZFS.

Виміряйте ARC, перш ніж щось налаштовувати

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

Три інструменти покривають більшу частину того, що вам потрібно:

• arcstat 1 надає динамічний перегляд лічильників влучень та промахів, співвідношення запитів та попереднього завантаження, а також поточного розміру ARC. Використовуйте його під час навантажувальних тестів та вікон резервного копіювання.
• arc_summary виводить окремий зніток: розмір ARC та цільове значення, розподіл між MFU та MRU, співвідношення метаданих та активні параметри налаштування. Запустіть arc_summary -s arc лише для розділу ARC.
• Сирі лічильники знаходяться /proc/spl/kstat/zfs/arcstats у Linux та під kstat.zfs.misc та vfs.zfs деревах sysctl у FreeBSD. Збирайте ці дані з систем моніторингу, а не шляхом розбору відформатованого виводу.

Лічильники, які варто записати перед будь-якими змінами:

Тут люди зазвичай припускаються двох помилок. Слідкуйте за доступною пам’яттю, а не за вільною; Linux без проблем повідомляє про низький рівень вільної оперативної пам’яті як про стабільний стан, і саме по собі це не є проблемою. Важливим сигналом є доступна пам'ять, близька до нуля, у поєднанні з тривалою активністю підкачки (у вступі до управління пам'яттю в Linux пояснено, чому). А коефіцієнт влучень слід розглядати як тенденцію, а не як ціль. Коефіцієнт влучень 99 % на системі, яка використовує підкачку, є провалом налаштування, а не успіхом.

Чотири важливі параметри налаштування ARC

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

Почніть із найменшої зміни, яка вирішує проблему, яку ви бачите. Щодо zfs_arc_max, правильне верхнє обмеження залежить від робочого навантаження (про це йдеться в наступному розділі). Для zfs_arc_min, мінімальне значення від 25% до 50% zfs_arc_max є розумною відправною точкою, якщо вона взагалі потрібна. Щодо метаданих, то останні стандартні налаштування OpenZFS вже виділяють метаданим 75% ARC за допомогою zfs_arc_meta_limit_percent, що є достатнім для більшості навантажень; змінюйте це лише тоді, коли пропуски метаданих чітко помітні в arcstat.

Застосування змін у Linux та FreeBSD

У Linux перевірте зміну під час роботи системи, записавши її у файл параметрів sysfs. Перезавантаження не потрібне:

echo 17179869184 > /sys/module/zfs/parameters/zfs_arc_max

Це одразу встановлює zfs_arc_max до 16 ГіБ. Щоб зміна збереглася після перезавантаження, додайте її до /etc/modprobe.d/zfs.conf:

options zfs zfs_arc_max=17179869184

У FreeBSD для змін під час виконання використовується sysctl:

sysctl vfs.zfs.arc_max=17179869184

Збережіть те саме значення у /boot/loader.conf:

vfs.zfs.arc_max="17179869184"

Змінюйте по одному параметру за раз, невеликими кроками — приблизно на 10 % від загального обсягу оперативної пам’яті. Стежте за вікном з повідомленнями про проблеми. Залишайте зміну лише в тому випадку, якщо обсяг підкачки залишається нульовим, а затримка є стабільною. Зафіксуйте зміну лише після успішного проходження тесту під час роботи системи.

Налаштування ARC відповідно до навантаження

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

Хост віртуальної машини повинен ділитися пам'яттю зі своїми гостями, тому обмеження від 30% до 40% є безпечним значенням за замовчуванням, а 50% вже занадто високе для більшості конфігурацій. Бази даних, такі як PostgreSQL та MySQL, самостійно керують своїми буферними кешами, тому спочатку слід зарезервувати пам'ять для двигуна, а ARC залишити те, що залишилося. Цілі резервного копіювання отримують переваги primarycache=metadata , оскільки дані, що зчитуються, рідко потрібні знову, і ви не хочете, щоб нічне резервне копіювання пробігало весь пул і очищало решту кешу по ходу. Для будь-якого робочого навантаження активність свопу, коли ARC зафіксовано на zfs_arc_max означає, що обмеження занадто високе; це правило не змінюється.

Діагностика проблем і розуміння, коли слід зупинитися

Недостатній розмір ARC проявляється у вигляді високих показників IOPS на читання, низького коефіцієнта влучень запитів та повільного перегляду каталогів, хоча система все ще має вільну оперативну пам’ять. Надмірний розмір ARC виявляється не так очевидно. Коефіцієнт влучень виглядає нормально, але система починає використовувати підкачку, середні показники навантаження зростають, процеси блокуються у D стані, поки ядро звільняє сторінки ARC за запитом, а в найгіршому випадку OOM-кілер починає обирати жертв. Кеш виглядає справним, а сервер працює жахливо.

Навантаження на метадані проявляється, коли demand_metadata_bytes значно перевищує demand_data_bytes в arc_summary. Це означає, що метадані змагаються з даними за місце, і варто підвищити граничний відсоток метаданих.

Зіставте те, що ви бачите, із першим параметром, який слід перевірити:

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

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

Якщо вам потрібен сервер із достатнім запасом оперативної пам’яті для належного функціонування ZFS без конкуренції за пам’ять із вашими віртуальними машинами чи базами даних (спочатку варто прочитати, скільки оперативної пам’яті вам насправді потрібно), зверніть увагу на виділені сервери FDC.