Настройка 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 GiB. Чтобы изменение сохранилось после перезагрузки, добавьте его в /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 уже находится на нормальном уровне.

Подходящий момент для прекращения настройки — это когда задержка стабилизировалась, объем свопа остается нулевым в том же периоде высокой нагрузки, который вызвал исходную проблему, и дальнейшие изменения уже не приносят никаких улучшений. Высокий коэффициент попадания не имеет значения, если сервер использует своп. После достижения этой точки прекратите корректировать настройки и возвращайтесь к ним только в том случае, если та же проблема повторится при той же нагрузке.

Если вам нужен сервер с достаточным запасом ОЗУ для корректной работы ZFS без борьбы за память с виртуальными машинами или базами данных (стоит сначала ознакомиться со статьёй о том, сколько ОЗУ вам действительно нужно), обратите внимание на выделенные серверы FDC.