Скільки RAM потрібно ZFS для пулу на 100 TB?

Звідки взялося правило "1 GB на TB"?

Не з OpenZFS. Його FAQ просить 8 GB або більше для найкращої продуктивності й додає, що люди запускають його і з 2 GB чи менше. Його посібник з обладнання взагалі не дає розрахунку пам'яті.

Два справжні правила змішуються в одне. Перше — ціль для кешу: Proxmox радить щонайменше 2 GiB плюс 1 GiB на TiB сховища для ARC, кешу читання ZFS. Друге — для дедуплікації, і воно значно більше. FreeBSD Handbook дає 5–6 GB RAM на TB дедуплікованих даних.

Правило 1 GB на TB — це побажання щодо кешу, а не вимога: ZFS працює й на значно меншому обсязі та кешує те, що ви йому дасте.

Сам Proxmox ставить менший стандарт. Починаючи з Proxmox VE 8.1, інсталятор обмежує ARC до 10% пам'яті, щонайбільше 16 GiB.

На що ZFS використовує пам'ять?

Переважно на ARC — кеш нещодавно й часто читаних блоків і метаданих. Більше кешу означає менше повільних звернень до жорстких дисків.

ARC сам визначає свій розмір. На Linux OpenZFS 2.3 і пізніші дають йому рости до більшого з двох: усієї пам'яті мінус 1 GiB та 5/8 пам'яті. OpenZFS 2.2 на Linux зупинявся на половині пам'яті. Нижня межа — більше з двох: 32 MiB та 1/32 пам'яті, і ZFS прагне залишити вільною 1/64 пам'яті.

Ще два використання мають ліміти. Скраби та ресільвери сортують свої читання в пам'яті, за замовчуванням до 1/20 RAM. Скільки триває ресільвер, описано на сторінці про час перебудови RAID. Дедуплікація тримає свою таблицю в пам'яті — звідси й великі числа.

На орендованих системах версії важливі. Станом на 2 листопада 2026 Debian 13 постачався з zfsutils-linux 2.3.9, а Ubuntu 24.04 — з 2.2.2.

Скільки пам'яті насправді використовує пул резервних копій на 100 TB?

Менше кешу, ніж файловий сервер, бо резервні копії пишуться один раз і читаються рідко. Кеш найбільше допомагає з метаданими: переліком снапшотів, видаленням старих копій і перевіркою індексів.

Правило Proxmox — розумна верхня межа для планування. Застосоване до поширених конфігурацій, воно дає такі цілі ARC:

• 2 × 12 TB у дзеркалі, 12 TB доступних: близько 13 GiB.
• 4 × 10 TB у RAIDZ2, 20 TB доступних: близько 20 GiB.
• 10 × 10 TB у RAIDZ2, 80 TB доступних: близько 75 GiB.
• 10 × 16 TB у RAIDZ2, 128 TB доступних: близько 118 GiB.

Порівняйте з холдами: Hold 24 32 GB DDR4 ECC, Hold 40 64 GB DDR4, Hold 100 128 GB DDR4 ECC, Hold 160 128 GB DDR4 ECC. Нижче цілі ZFS усе одно працює; він просто частіше читає метадані з диска.

З 23 продавців серверів зі сховищем Basalthold, перевірених 2 November 2026, 8 пропонували сервер на 100 TB або більше, і 1 здавали його в оренду покупцям за крипту без ID. Уся пропозиція на сторінці сервера зі сховищем на 100 TB.

Чи варто вмикати дедуплікацію ZFS для резервних копій?

Не на 100 TB. За 5–6 GB на TB дедуплікованих даних 80 TB вимагали б 400–480 GB пам'яті. Це більше, ніж має будь-який холд.

Нехай дедуплікує сам інструмент резервного копіювання. restic, Borg і Proxmox Backup Server розбивають дані на чанки та зберігають кожен чанк один раз у власному індексі. Відмінності на restic чи Borg. Тримайте ввімкненим стиснення ZFS; воно коштує мало пам'яті.

ECC-пам'ять важливіша за обсяг. OpenZFS називає її настійно рекомендованою, бо жодна файлова система не захистить від перевертання бітів у RAM. Чому ZFS також хоче звичайні диски, описано на ZFS чи апаратний RAID.

Як перевірити або обмежити ARC?

Спершу подивіться на поточний розмір, а ліміт ставте лише тоді, коли пам'ять потрібна іншим сервісам. Посібник Proxmox використовує той самий параметр zfs_arc_max.

# current ARC size and its limits, in bytes
grep -E '^(size|c_min|c_max) ' /proc/spl/kstat/zfs/arcstats
arc_summary | head -40

# cap the ARC at 64 GiB until the next reboot
echo $((64 * 1024 * 1024 * 1024)) > /sys/module/zfs/parameters/zfs_arc_max

# keep the cap after reboots
echo "options zfs zfs_arc_max=68719476736" > /etc/modprobe.d/zfs.conf
# only if the root filesystem itself is on ZFS:
update-initramfs -u -k all