Почему ZFS использует половину оперативной памяти и чем это полезно

Пользователи файловой системы ZFS нередко сталкиваются с мнением, что она забирает ровно половину доступной оперативной памяти. На практике современный адаптивный кэш чтения ZFS (ARC) способен задействовать практически весь свободный объем ОЗУ на сервере. Понимание того, как функционирует адаптивный кэш чтения в ZFS и почему графики заполнения памяти больше не должны вызывать опасений, помогает по-новому взглянуть на системные ресурсы домашнего хранилища данных.

Файловая система ZFS хранит в оперативной памяти специальный кэш чтения, известный как Adaptive Replacement Cache. В нем удерживаются недавно запрошенные файлы и метаданные, а также данные, к которым система обращается чаще всего. Механизм динамически балансирует эти списки в реальном времени. Скорость отклика оперативной памяти измеряется наносекундами, в то время как даже быстрые SSD-накопители работают на уровне микросекунд, а жесткие диски — миллисекунд. Каждое чтение, обработанное через кэш ARC, означает, что физическим дискам вовсе не обязательно выполнять эту операцию.

Как работает адаптивный кэш чтения в ZFS

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

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

Главная особенность механизма заключается в том, что ARC не занимается удержанием памяти ради накопления. Как только ядро оперативной памяти запрашивает ресурсы для других задач, ZFS сжимает кэш и передает освободившиеся мегабайты программе. Именно поэтому дашборд хранилища с заполненной памятью продолжает успешно запускать контейнеры и виртуальные машины. Единственным нюансом остается время, необходимое на сжатие кэша, и возникающая при этом задержка.

Почему раньше действовало ограничение в 50% ОЗУ

Изначально файловая система формировалась в среде Solaris и развивалась в ОС FreeBSD, где кэш мог задействовать почти всю доступную память без искусственных барьеров. Ситуация изменилась при переносе кода на платформу Linux, что потребовало введения защитных мер из-за особенностей распределения памяти в ядре этой операционной системы.

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

Платформа TrueNAS CORE, функционирующая на базе FreeBSD, никогда не имела подобных ограничений. Ситуация изменилась с выходом TrueNAS SCALE, где распределение памяти для кэша было приведено к единым стандартам с версией CORE, а аналогичные изменения вошли в официальный код OpenZFS. В современных версиях платформ стандартный лимит рассчитывается как общий объем ОЗУ за вычетом одного гигабайта или пять восьмых от общего объема.

Особенности отображения памяти в Linux и дашбордах

Одной из причин частых вопросов становится специфика вывода информации операционной системой Linux. Стандартные утилиты командной строки фиксируют почти полное отсутствие свободной памяти, даже когда система работает стабильно. Обычный страничный кэш отображается в графе кэширования, память из которого система отдает по первому требованию. Однако ARC не относится к стандартному страничному кэшу ядра, поэтому Linux фиксирует его как обычную занятую память.

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

В каких случаях большой кэш может создавать неудобства

Несмотря на высокую эффективность, активное использование оперативной памяти под кэш подходит не для всех сценариев применения. Если сервер помимо базового хранения файлов запускает виртуальные машины, могут возникать определенные нюансы.

Запуск виртуальной машины требует одновременного выделения крупного блока памяти. Если кэш заполнен полностью, системе приходится экстренно сокращать его размер, из-за чего гостевая система ожидает высвобождения ресурсов. На серверах, ориентированных исключительно на файлообмен, это не имеет критического значения, но на машинах с постоянным запуском и остановкой виртуальных сред подобные задержки могут приводить к медленному старту.

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

Стоит ли ограничивать размер кэша ZFS

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

Вместе с тем ручное ограничение через параметр конфигурации может потребоваться в нескольких конкретных ситуациях:

• На сервере запускается большое количество виртуальных машин с частым циклом перезапуска.
• Файловая система развернута на гипервизоре, где гостевым ОС требуются ресурсы по первому запросу.
• ZFS используется на настольном компьютере или ноутбуке, где приложения и игры активно конкурируют за оперативную память.

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