ZFS и оперативная память: сколько на самом деле нужно

MAATRIX

«ZFS требует минимум 1GB оперативной памяти на каждый терабайт хранилища» — это правило встречается в любом форуме про NAS и почти в каждом гайде по установке ZFS, обычно с интонацией жёсткого технического ограничения: не хватит памяти — ZFS откажется работать или начнёт сыпать ошибками. На практике всё куда мягче: ZFS прекрасно запускается и работает на системах, где этой памяти в разы меньше, а правило "1GB на терабайт" — это ориентир для конкретного паттерна нагрузки, а не порог включения файловой системы. Разберём, откуда взялось это число, что оно на самом деле означает и сколько памяти закладывать под ваш конкретный случай.

Откуда взялся миф и что в нём правда

Правило "1GB RAM на 1TB хранилища" родилось не на пустом месте — в его основе лежит реальный и важный механизм ZFS: ARC (Adaptive Replacement Cache), адаптивный кеш чтения, который живёт в оперативной памяти.

В отличие от классических файловых систем, которые полагаются на page cache операционной системы (мы разбирали это в статье про то, куда девается свободная память), ZFS реализует собственный слой кеширования данных и метаданных. ARC агрессивно занимает свободную RAM под кеш блоков, которые читались недавно или читаются часто, и по умолчанию готов забрать под себя большую часть доступной памяти — на выделенном сервере или домашнем NAS это может быть 50-90% от общего объёма RAM, если явно не ограничить zfs_arc_max.

Чем больше ARC — тем больше "горячих" данных помещается в память, тем меньше обращений к физическим дискам, и тем выше скорость случайного чтения. Логика "больше хранилища → больше горячих данных → больше нужно памяти под их кеширование" разумна сама по себе. Проблема в том, что из неё сделали линейную формулу и превратили рекомендацию по производительности в миф об обязательном техническом минимуме.

Отсюда родилась путаница: люди читают "1GB на терабайт" как "ZFS не запустится с меньшим объёмом", хотя изначальный смысл был "с меньшим объёмом кеш будет меньше, и на определённых нагрузках вы это почувствуете".

ZFS технически работает и с гораздо меньшим объёмом RAM

Разделим два разных вопроса, которые миф сливает в один: "сколько RAM нужно, чтобы ZFS запустилась и функционировала" и "сколько RAM нужно, чтобы ZFS кешировала данные хорошо".

Ответ на первый вопрос — заметно меньше, чем говорит правило. ZFS на Linux (OpenZFS) без проблем поднимается на системах с 2-4GB RAM даже при пуле в несколько терабайт: домашние NAS на Raspberry Pi и подобных одноплатниках, минимальные VPS с ZFS-корнем, тестовые стенды — всё это рабочие конфигурации, а не крайний случай "на грани падения". Файловая система монтируется, читает и пишет данные, проверяет контрольные суммы, держит снапшоты — все базовые механизмы ZFS от размера ARC не зависят.

Что меняется при малом ARC — это доля запросов чтения, которая обслуживается из памяти вместо диска (так называемый ARC hit ratio). Меньше кеша — меньше данных в нём помещается одновременно — чаще происходит промах кеша (cache miss) и запрос уходит на физический диск. Для нагрузки, где это не критично, разница практически не ощущается:

• Домашний NAS с редким доступом — файлы читаются от случая к случаю, обращения к одним и тем же данным не идут потоком, и выигрыш от большого кеша просто негде реализовать: данные всё равно почти всегда читаются "холодными".
• Архивное хранилище с последовательной записью — бекапы, медиатека, холодные копии данных. Запись идёт большими последовательными блоками, повторные чтения одного и того же файла редки, и ARC здесь помогает слабо независимо от своего размера.

В обоих случаях недостаток ARC-кеша — это "будет чуть медленнее при повторном чтении", а не "система откажется работать". Отказ системы наступает от других причин: нехватки RAM для самой ОС и работающих сервисов, а не от нарушения мифического порога ZFS.

Почему реальная потребность в RAM зависит от паттерна нагрузки, а не от объёма диска

Ключевая ошибка правила "1GB на терабайт" — оно привязывает требования к памяти к размеру хранилища, хотя на деле они привязаны к паттерну доступа к данным.

Возьмём два пула одинакового размера, 10TB, на одинаковом железе:

10TB архивного хранилища с последовательной записью и 10TB рабочей базы данных с интенсивным случайным чтением — это принципиально разные требования к памяти при одинаковом объёме диска. Первому может с запасом хватить 4-8GB RAM, второму даже 64GB может быть мало, если рабочий набор данных (working set) больше кеша.

Именно поэтому вместо формулы "объём диска × коэффициент" правильный вопрос — "какой у меня рабочий набор данных, который выгодно держать горячим в памяти, и как часто к нему идут повторные обращения". Это тот же принцип, что мы разбирали в статье о том, сколько оперативной памяти закладывать с запасом для VPS вообще: ориентируйтесь на реальную нагрузку, а не на универсальное правило.

Дедупликация — вот где страшные цифры оправданы

Если покопаться, откуда в старых источниках берутся совсем пугающие оценки вроде "5GB RAM на терабайт" — почти всегда речь идёт о ZFS-дедупликации (zfs set dedup=on), а не о ZFS вообще.

Дедупликация работает через таблицу дедупликации (DDT, deduplication table) — структуру данных, которая хранит хеш каждого уникального блока и счётчик ссылок на него. Каждая запись при включённой дедупликации проверяется на совпадение с уже существующими блоками. Проблема в том, что DDT должна помещаться в памяти (в идеале — в самом ARC, либо частично на быстром L2ARC), чтобы проверка каждого блока не превращалась в дополнительное чтение с диска. Если таблица не помещается в RAM, каждая операция записи начинает требовать case-by-case обращений к DDT на диске — и производительность записи проседает катастрофически, иногда на порядки.

Именно этот сценарий и породил в старых форумах и гайдах формулировки вида "закладывайте 5GB RAM на терабайт с дедупликацией" — оценки, которые потом оторвались от контекста дедупликации и стали восприниматься как требование ZFS вообще, без всякой оговорки про dedup=on.

Практический вывод простой: без дедупликации требования к памяти умеренные и определяются паттерном нагрузки, как описано выше. С включённой дедупликацией — совсем другая история, и включать её стоит только осознанно, посчитав размер будущей DDT (грубо говоря, по записи на каждый уникальный блок) и заложив под неё память заранее. Для большинства сценариев аренды сервера компрессия (zfs set compression=lz4) даёт похожую экономию места почти без накладных расходов на память и почти всегда предпочтительнее дедупликации.

Как посчитать, а не гадать: реальный мониторинг вместо универсального правила

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

Базовая команда — arc_summary (пакет zfsutils-linux на Debian/Ubuntu, zfs на большинстве других дистрибутивов уже включает утилиту):

arc_summary | head -40

Ключевые строки, на которые стоит смотреть:

ARC size (current):                                    62.3 %   9.7 GiB
Target size (adaptive):                               100.0 %   15.6 GiB
...
ARC hit ratio:                                          94.2 %
Data demand efficiency:                                 91.8 %

• ARC hit ratio — доля запросов чтения, обслуженных из кеша. Если он стабильно выше 90% под вашей типичной нагрузкой — ARC справляется, увеличивать память ради кеша, скорее всего, не имеет смысла.
• Target size против current size — если ARC не может вырасти до желаемого размера (target size растёт, а current упирается в потолок памяти системы), это сигнал, что кеш реально ограничен нехваткой RAM.

Для более детальной картины по времени полезен zpool iostat -v 5 — он покажет реальную нагрузку на физические диски пула, и если диски почти простаивают несмотря на активную нагрузку приложения, это подтверждает, что ARC хорошо разгружает I/O.

Живой мониторинг за несколько дней под реальной нагрузкой скажет о нужном объёме RAM больше, чем любое универсальное правило из статьи (включая эту).

Аппаратный контекст: RAID-контроллер тут не нужен

Отдельная путаница, которая часто всплывает рядом с вопросом про RAM для ZFS — нужен ли для неё аппаратный RAID-контроллер. Нет, и это важно понимать при планировании сервера: ZFS сама реализует избыточность на уровне пула (RAID-Z, зеркала) и ожидает прямого доступа к дискам, а не RAID-массив, собранный контроллером "под капотом". Аппаратный RAID-контроллер в этой схеме не просто не нужен — он мешает, скрывая от ZFS реальное состояние дисков и мешая ей самостоятельно детектировать и чинить повреждения через контрольные суммы. Мы разбирали, кому вообще реально нужен аппаратный RAID-контроллер, и для серверов с ZFS ответ обычно — режим HBA/passthrough, а не аппаратный RAID.

Экономия на контроллере — это отдельный бюджет, который логично перенаправить туда, где он реально повлияет на производительность: в оперативную память под ARC, если ваша нагрузка от неё выигрывает.

Практические рекомендации по объёму RAM

Сведём всё в конкретные ориентиры (именно ориентиры, не жёсткие формулы — реальную цифру для вашего случая покажет только мониторинг под вашей нагрузкой):

• Тестовый стенд, домашний архив, редко используемый NAS — не бойтесь пробовать ZFS на 4-8GB RAM независимо от объёма пула. Функциональность файловой системы (снапшоты, контрольные суммы, RAID-Z) от этого не страдает, вы просто получаете более скромный кеш чтения.
• Файловое хранилище с умеренной нагрузкой, бекап-сервер, медиатека с редкими повторными обращениями — 8-16GB обычно достаточно с запасом, дальнейшее увеличение памяти вряд ли даст ощутимый прирост, так как повторные чтения одних данных и так редки.
• Продакшн-хранилище с интенсивным случайным чтением (базы данных на ZFS, диски виртуальных машин, активно используемые домашние каталоги множества пользователей) — здесь стоит закладывать разумный запас под ARC и следить за hit ratio через arc_summary; если он стабильно ниже 80-85%, а нагрузка важна для отклика — это повод добавить памяти, а не повод для паники.
• Дедупликация — включайте только осознанно, посчитав ожидаемый размер DDT, и рассматривайте компрессию (lz4) как менее затратную по памяти альтернативу для экономии места.

Ограничить максимальный размер ARC вручную можно параметром модуля ядра, если система делит RAM с другими сервисами:

echo "options zfs zfs_arc_max=8589934592" > /etc/modprobe.d/zfs.conf
# 8589934592 байт = 8 GiB, применится после перезагрузки или update-initramfs + reboot

Это полезно, когда на том же сервере, помимо ZFS-пула, крутятся другие сервисы (например, читайте про баланс между кешем страниц и приложениями) и вы не хотите, чтобы ARC забрал себе всю свободную память по умолчанию.

Частые вопросы