Ile RAM potrzebuje ZFS dla puli 100 TB?

Skąd pochodzi reguła „1 GB na TB”?

Nie z OpenZFS. Jego FAQ zaleca 8 GB lub więcej dla najlepszej wydajności i dodaje, że ludzie uruchamiają go z 2 GB lub mniej. Jego poradnik sprzętowy nie podaje w ogóle rozmiarowania pamięci.

Dwie prawdziwe reguły są mieszane w jedną. Pierwsza to cel dla cache: Proxmox zaleca co najmniej 2 GiB plus 1 GiB na TiB pamięci masowej dla ARC, cache odczytu ZFS. Druga dotyczy deduplikacji i jest znacznie większa. FreeBSD Handbook podaje 5 do 6 GB RAM na TB zdeduplikowanych danych.

Reguła 1 GB na TB to życzenie dotyczące cache, a nie wymóg: ZFS działa na znacznie mniejszej ilości i cache'uje to, co mu dasz.

Sam Proxmox ustawia mniejszy domyślny limit. Od Proxmox VE 8.1 instalator ogranicza ARC do 10% pamięci, maksymalnie 16 GiB.

Do czego ZFS używa pamięci?

Głównie do ARC, czyli cache ostatnio i często czytanych bloków oraz metadanych. Więcej cache oznacza mniej wolnych wycieczek do dysków twardych.

ARC sam dobiera rozmiar. Na Linuksie OpenZFS 2.3 i późniejsze pozwalają mu rosnąć do większej z wartości: cała pamięć minus 1 GiB oraz 5/8 pamięci. OpenZFS 2.2 zatrzymywał się na połowie pamięci na Linuksie. Dolny limit to większa z wartości: 32 MiB oraz 1/32 pamięci, a ZFS stara się zostawić 1/64 pamięci wolną.

Dwa inne zastosowania mają limity. Scrube i resilvery sortują swoje odczyty w pamięci, domyślnie do 1/20 RAM. Jak długo trwa resilver, opisano na stronie o czasie przebudowy RAID. Deduplikacja trzyma swoją tablicę w pamięci i stąd biorą się te duże liczby.

Wersje mają znaczenie na wynajmowanych systemach. 2 listopada 2026 Debian 13 dostarczał zfsutils-linux 2.3.9, a Ubuntu 24.04 dostarczał 2.2.2.

Ile pamięci naprawdę zużywa pula zapasowa 100 TB?

Mniej cache niż serwer plików, bo kopie zapasowe są zapisywane raz i rzadko czytane. Cache najbardziej pomaga przy metadanych: wylistowaniu snapshotów, przycinaniu starych kopii zapasowych i sprawdzaniu indeksów.

Reguła Proxmox to rozsądny pułap do planowania. Zastosowana do typowych układów daje następujące cele ARC:

• 2 × 12 TB w mirrorze, 12 TB użytecznej: około 13 GiB.
• 4 × 10 TB w RAIDZ2, 20 TB użytecznej: około 20 GiB.
• 10 × 10 TB w RAIDZ2, 80 TB użytecznej: około 75 GiB.
• 10 × 16 TB w RAIDZ2, 128 TB użytecznej: około 118 GiB.

Porównaj z holdami: Hold 24 32 GB DDR4 ECC, Hold 40 64 GB DDR4, Hold 100 128 GB DDR4 ECC, Hold 160 128 GB DDR4 ECC. Poniżej celu ZFS nadal działa; po prostu częściej czyta metadane z dysku.

Z 23 sprzedawców serwerów pamięci masowej Basalthold sprawdzonych 2 November 2026, 8 oferowało serwer 100 TB lub większy, a 1 wynajmowało go kupującym za kryptowalutę bez dowodu tożsamości. Cała oferta jest na stronie serwera pamięci masowej 100 TB.

Czy powinienem włączyć deduplikację ZFS dla kopii zapasowych?

Nie na 100 TB. Przy 5 do 6 GB na TB zdeduplikowanych danych 80 TB wymagałoby 400 do 480 GB pamięci. To więcej, niż ma jakikolwiek hold.

Pozwól zamiast tego deduplikować narzędziu do kopii zapasowych. restic, Borg i Proxmox Backup Server dzielą dane na chunki i przechowują każdy chunk raz, we własnym indeksie. Różnice opisano na restic or Borg. Zostaw włączoną kompresję ZFS; kosztuje niewiele pamięci.

Pamięć ECC ma większe znaczenie niż rozmiar. OpenZFS uznaje ją za wysoce zalecaną, bo żaden system plików nie ochroni przed odwróceniem bitów w RAM. Dlaczego ZFS woli też zwykłe dyski, opisano na ZFS or hardware RAID.

Jak sprawdzić lub ograniczyć ARC?

Najpierw odczytaj bieżący rozmiar, potem ustaw limit tylko wtedy, gdy inne usługi potrzebują pamięci. Poradnik Proxmox używa tego samego parametru 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