Wie viel RAM braucht ZFS wirklich? Mythen, Defaults und Praxis

Kurz gesagt: ZFS braucht für sich selbst wenig RAM. Die OpenZFS-FAQ nennt 8 GB und mehr für die beste Leistung, hält aber auch 2 GB oder weniger für machbar, solange du keine Deduplizierung nutzt. Den großen Rest belegt der ARC, der Lesecache von ZFS: Er nimmt sich freien Speicher und gibt ihn ab, wenn Programme ihn brauchen. Eine feste Formel aus der Plattengröße gibt es nicht; die bekannte Regel „1 GB RAM pro TB“ stammt nicht aus der OpenZFS-Doku, die eine ähnliche Zahl nur für Deduplizierung nennt.

Kaum eine ZFS-Frage wird so oft gestellt und so unterschiedlich beantwortet. In Foren liest du von 1 GB pro Terabyte, von Pflicht-ECC und von Servern, die ZFS angeblich „den ganzen Speicher wegfrisst“. Dieser Guide sortiert, was die offizielle Doku tatsächlich sagt, was in einer Testumgebung zu sehen war und wie du für dein eigenes System entscheidest. Er richtet sich an Einsteiger, die einen Homeserver, ein NAS oder einen Proxmox-Host planen, und an alle, die sich über eine volle RAM-Anzeige wundern.

Voraussetzungen #

• Du weißt grob, was ein ZFS-Pool und ein Dataset sind (Was ist ZFS?).
• Für die Prüfbefehle: ein Linux-System mit installiertem OpenZFS und Shell-Zugang mit sudo.

Lernziel: Du kannst einschätzen, wie viel RAM dein ZFS-System braucht, erkennst echte Speicherprobleme und unterscheidest sie vom normalen Verhalten des ARC.

Wofür ZFS RAM verwendet #

Den Speicherbedarf von ZFS kannst du in drei Teile zerlegen:

1. Grundbedarf: Verwaltungsstrukturen des Kernelmoduls, Puffer für Schreibvorgänge und Metadaten der Pools. Dieser Teil ist klein im Vergleich zum Rest.
2. ARC (Adaptive Replacement Cache): der Lesecache im Arbeitsspeicher. Er hält zuletzt und häufig gelesene Blöcke vor, damit ZFS sie nicht erneut von der Platte holen muss. Das ist der Teil, der in Anzeigen wie free groß erscheint.
3. Sonderfunktionen: vor allem Deduplizierung. Ihre Tabelle muss für eine brauchbare Leistung in den Speicher passen und kann sehr groß werden.

Der ARC ist flexibel. Er hat eine Untergrenze und eine Obergrenze und bewegt sich dazwischen. Laut Quellcode-Kommentar von OpenZFS versucht er, auf Speicherdruck des Betriebssystems zu reagieren, und schrumpft, wenn der Speicher knapp wird. Mehr RAM bringt also vor allem mehr Cache. Weniger RAM macht ZFS nicht unsicherer, aber häufiger muss es von den Platten lesen.

Die OpenZFS-Doku nennt RAM deshalb das mit Abstand wirksamste „Tuning-Werkzeug“ von ZFS. Bevor du über Cache-SSDs nachdenkst, prüfst du, ob der ARC zu klein ist (mehr dazu in L2ARC, SLOG und Special VDEVs).

Die Standardwerte des ARC #

Wie groß der ARC höchstens werden darf, legt der Modulparameter zfs_arc_max fest. Steht er auf 0 (Standard), berechnet ZFS die Grenze selbst. Die Formel hat sich mit OpenZFS 2.3 geändert:

Ab etwa 2,7 GiB RAM ist „RAM minus 1 GiB“ der größere Wert. Auf normalen Servern darf der ARC also fast den ganzen Speicher nutzen. Die Untergrenze zfs_arc_min liegt standardmäßig beim größeren Wert aus 32 MiB und einem Zweiunddreißigstel des RAM. Zusätzlich versucht der ARC, einen Rest freizuhalten (zfs_arc_sys_free, standardmäßig ein Vierundsechzigstel des RAM).

Proxmox VE weicht davon ab: Der Installer schreibt seit Version 8.1 ein Limit von 10 % des RAM, höchstens 16 GiB, in die Konfiguration. Das gilt für Neuinstallationen; Systeme, die vor 8.1 installiert wurden, behalten den OpenZFS-Standard. Details stehen in ZFS in Proxmox VE.

Aus den Formeln ergeben sich diese Obergrenzen (gerechnet, nicht gemessen):

Für andere Werte rechnet der ZFS-RAM- und ARC-Planer die Grenzen aus.

So sieht das auf einem echten System aus #

In einer Testumgebung mit Debian 13, OpenZFS 2.4.4 und 4 GiB RAM (davon 3,8 GiB für das System sichtbar) zeigen die Rohwerte des ARC genau diese Formel:

grep -E '^(size|c_min|c_max) ' /proc/spl/kstat/zfs/arcstats

Der Befehl liest drei Zeilen aus der Statistikdatei des ARC: aktuelle Größe, Unter- und Obergrenze in Byte.

c_min                           4    128430592
c_max                           4    3036037120
size                            4    376389280

c_max entspricht exakt dem RAM minus 1 GiB, c_min einem Zweiunddreißigstel. Die aktuelle Größe von etwa 360 MiB zeigt, dass der ARC nur wächst, wenn tatsächlich gelesen wird; auf einem frisch gestarteten System ist er klein.

Übersichtlicher geht es mit zarcsummary (bis OpenZFS 2.3 hieß das Werkzeug arc_summary):

sudo zarcsummary -s arc

Der Befehl zeigt nur den Abschnitt zur Größe des ARC:

ARC status:
        Total memory size:                                       3.8 GiB
        Min target size:                                3.1 %  122.5 MiB
        Max target size:                               73.9 %    2.8 GiB
        Target size (adaptive):                         4.4 %  168.4 MiB
        Current size:                                   4.4 %  127.8 MiB
        Free memory size:                                        3.2 GiB
        Available memory size:                                   3.0 GiB
…

Target size ist das aktuelle Ziel, das ZFS je nach Bedarf und Speicherlage zwischen Min und Max verschiebt; Current size ist die tatsächliche Belegung.

Hoher RAM-Verbrauch ist kein Fehler #

Nach ein paar Tagen Betrieb sieht ein ZFS-Server oft so aus, als sei der Speicher fast voll. Das ist gewollt: Freier RAM bringt keinen Nutzen, als Cache spart er Plattenzugriffe. Ein Leck wäre es erst, wenn der Speicher trotz Bedarf anderer Programme nicht freigegeben würde.

Wichtig für die Einordnung: Werkzeuge wie free zeigen den ARC nicht als buff/cache, sondern als used. In der Testumgebung wurde der ARC testweise per Limit um rund 175 MB verkleinert; used sank dabei um etwa 178 MB, buff/cache blieb unverändert. Wer nur auf free -h schaut, hält den Cache also leicht für belegten Speicher von Programmen.

free -h

free -h zeigt den Speicher in lesbaren Einheiten. Die Ausgabe aus der Testumgebung während laufender Tests:

               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       1.1Gi       165Mi       720Ki       2.8Gi       2.7Gi
Swap:             0B          0B          0B

Wie viel davon der ARC ist, siehst du nur in den ZFS-eigenen Zahlen (size in den arcstats oder Current size in zarcsummary). Ziehst du diesen Wert von used ab, bleibt der Bedarf der Programme übrig. Wie du den ARC im Detail liest, erklärt ZFS ARC verstehen.

Der Mythos „1 GB RAM pro TB“ #

Die Regel taucht in vielen Anleitungen auf: pro Terabyte Speicher ein Gigabyte RAM. In der aktuellen OpenZFS-Doku findest du sie nicht als allgemeine Anforderung. Belegt sind zwei verwandte, aber andere Aussagen:

• Deduplizierung: Die OpenZFS-Doku rät, für deduplizierte Daten mindestens 1,25 GiB RAM pro TiB gespeicherter Daten einzuplanen. Das gilt nur, wenn du Dedup einschaltest, was für ein Heim-NAS fast nie sinnvoll ist (siehe ZFS-Deduplizierung).
• Proxmox VE: Die Proxmox-Doku nennt als Faustregel für die Größe des ARC 2 GiB Grundwert plus 1 GiB pro TiB Speicher, etwa 10 GiB ARC bei 8 TiB. Das ist eine Empfehlung für gute Leistung auf VM-Hosts, kein Mindestbedarf, ohne den ZFS nicht startet.

Für einen Datei-Server ohne Dedup hängt der sinnvolle RAM nicht an der Plattengröße, sondern daran, wie viele Daten regelmäßig gelesen werden. Ein Archiv mit 40 TB Filmen, aus dem abends ein Film läuft, profitiert kaum von einem großen Cache. Ein kleiner Pool, auf dem viele VMs ständig dieselben Blöcke lesen, dagegen sehr.

Was den RAM-Bedarf wirklich bestimmt #

Statt einer Formel helfen diese Fragen:

• Was läuft außer ZFS? Betriebssystem, Container, VMs und Datenbanken brauchen ihren eigenen Speicher. Das ist meist der größte Posten und der, den du zuerst planst.
• Wie viele Daten werden immer wieder gelesen? Diese Menge nennt man Working Set. Passt sie in den ARC, kommen wiederholte Lesezugriffe aus dem RAM.
• Wie viele Dateien und Verzeichnisse? Metadaten (Verzeichnisinhalte, Dateiattribute, Blockzeiger) liegen ebenfalls im ARC. Viele kleine Dateien, etwa bei Backups mit Millionen Einzeldateien, profitieren davon, dass die Metadaten im Cache bleiben.
• Deduplizierung an? Dann kommt die Dedup-Tabelle hinzu, und der Bedarf steigt deutlich.
• L2ARC geplant? Eine Cache-SSD kostet laut OpenZFS-Doku selbst RAM, weil jeder Block darauf einen Verwaltungseintrag im ARC braucht.

Nicht entscheidend sind dagegen die Art der Redundanz (Mirror oder RAIDZ) und die reine Plattengröße.

Szenarien von 4 bis 64 GB #

Die folgenden Einschätzungen beruhen auf der Doku und den Standardwerten oben. Sie sind Orientierung, keine Messwerte; was dein System wirklich braucht, zeigen die Prüfbefehle weiter unten.

4 GB #

Funktioniert für einen kleinen Datei-Server oder ein Backupziel ohne Zusatzdienste. Die FAQ hält auch 2 GB oder weniger für möglich. Der ARC bleibt klein, wiederholte Zugriffe treffen ihn seltener. Für Docker-Stacks oder VMs neben ZFS wird es eng.

8 GB #

Ein solider Einstieg für ein Heim-NAS mit SMB- oder NFS-Freigaben und ein paar leichten Diensten. Die FAQ nennt 8 GB und mehr für die beste Leistung. Mit OpenZFS ab 2.3 darf der ARC hier bis zu 7 GiB nutzen und weicht, wenn Dienste Speicher anfordern.

16 GB #

Bequem für ein NAS mit einigen Containern, etwa Medienserver, Cloud-Dienst und Monitoring. Genug Platz für einen spürbaren Cache und für Programme. Ab hier wird es auch für einen kleinen Proxmox-Host mit wenigen VMs realistisch.

32 GB #

Sinnvoll, wenn mehrere VMs laufen oder viele Nutzer dieselben Daten lesen. Auf einem VM-Host gehört der Großteil dieses Speichers den VMs; der ARC bekommt einen festen Anteil (siehe unten).

64 GB und mehr #

Für Virtualisierungshosts mit vielen VMs, große Datenbanken oder sehr große Working Sets. Für ein reines Datei-NAS im Haushalt bringt so viel RAM meist wenig zusätzlichen Nutzen. Hier kann sich eher lohnen, über Deduplizierung nachzudenken, wenn sie wirklich messbar viel spart; die Prüfung dafür steht im Dedup-Guide.

Szenarien nach Einsatzzweck #

Datei-NAS (SMB/NFS): Standardwerte lassen. Der ARC nutzt den freien Speicher, Samba und NFS brauchen wenig. Ein Limit ist nur nötig, wenn andere Dienste nachweislich zu kurz kommen.

Backupserver: Es wird viel geschrieben und selten gelesen. Ein großer Datencache bringt wenig, die Metadaten (für Snapshots, Listen, zfs send) profitieren aber vom ARC. Hier reicht oft weniger RAM, solange keine Deduplizierung läuft. Die Doku nennt Backupziele, die ähnliche Systeme empfangen, zwar als Fall, in dem Dedup sich lohnen kann; prüfe das vorher mit einer Simulation statt es auf Verdacht einzuschalten.

Homelab-Server mit Docker: Container und ARC teilen sich den Speicher. Meist funktioniert das ohne Eingriff, weil der ARC bei Bedarf schrumpft. Begrenze den ARC erst, wenn du Speicherengpässe beobachtest, siehe ZFS mit Docker und virtuellen Maschinen.

VM-Host (Proxmox oder KVM): Hier plant man anders. VMs reservieren beim Start ihren Speicher und brauchen ihn sofort. Ein ARC, der fast den ganzen RAM belegt, muss dann erst schrumpfen. Deshalb setzt Proxmox ein festes Limit, und auf jedem VM-Host lohnt sich die Rechnung: RAM der VMs plus Betriebssystem plus ARC-Anteil. Wie du das Limit setzt, erklärt ZFS ARC begrenzen.

ECC-RAM: nötig oder nicht? #

ECC-Speicher erkennt und korrigiert einzelne Bitfehler im RAM. Die OpenZFS-Doku sagt dazu zweierlei:

• Kein Verfahren in ZFS oder einem anderen Dateisystem schützt vor Bitfehlern im RAM. Kippt ein Bit, bevor ZFS die Prüfsumme berechnet, bemerkt ZFS den Fehler nicht. Kippt es danach, erkennt ZFS ihn, kann ihn aber unter Umständen nicht korrigieren. Im schlimmsten Fall lässt sich ein Pool nicht mehr importieren; die Doku nennt solche Fälle außerordentlich selten. Deshalb empfiehlt sie ECC ausdrücklich.
• Die FAQ empfiehlt ECC dringend für Unternehmen und schreibt, dass sich der Mehrpreis für Heimanwender nicht unbedingt lohnt.

ZFS braucht ECC also nicht mehr als andere Dateisysteme. Wenn dein Board und deine CPU ECC ohne großen Aufpreis unterstützen, nimm es mit. Fehlt es, spricht das nicht gegen ZFS. Mehr zur Hardwareauswahl steht in Welche Hardware braucht ZFS?.

Was bei Speichermangel passiert #

Wird der Speicher knapp, schrumpft der ARC in Richtung seiner Untergrenze. Darunter gibt er nichts mehr ab. Bleibt der Druck bestehen, greift Linux zu den üblichen Mitteln: Auslagern in die Swap, falls vorhanden, und im Extremfall der OOM-Killer, der Prozesse beendet, um Speicher zu befreien.

Zusätzlich bremst ZFS selbst: Laut Manpage drosselt der ARC Ein- und Ausgaben, wenn der freie Speicher unter 10 % des RAM fällt (zfs_arc_lotsfree_percent). Wie oft das passiert ist, zählt der Wert memory_throttle_count in den arcstats.

Typische Anzeichen, dass der RAM wirklich nicht reicht:

• Programme werden vom OOM-Killer beendet (journalctl -k | grep -i oom).
• Das System lagert dauerhaft aus, obwohl der ARC schon nahe an seiner Untergrenze ist.
• memory_throttle_count steigt.
• Die Trefferquote des ARC ist dauerhaft niedrig, obwohl immer wieder dieselben Daten gelesen werden.

Ein voller ARC allein ist dagegen kein Anzeichen.

Ergebnis prüfen #

Mit diesen lesenden Befehlen siehst du, wie dein System dasteht:

free -h
grep -E '^(size|c|c_min|c_max|memory_throttle_count) ' /proc/spl/kstat/zfs/arcstats
sudo zarcsummary -s arc

free -h zeigt die Gesamtbelegung, die arcstats-Zeilen die Größe und Grenzen des ARC sowie die Zahl der Drosselungen, zarcsummary -s arc fasst das lesbar zusammen. Auf Systemen mit OpenZFS bis 2.3 heißt der dritte Befehl arc_summary. Die Trefferquote zeigt zarcstat (bis 2.3: arcstat); wie du sie liest, steht im ARC-Guide.

Wer nachrechnen will, ob neben seinen Diensten genug Platz bleibt, trägt RAM, Version und den Bedarf der Dienste in den ZFS-RAM- und ARC-Planer ein.

Häufige Fehler #

• „ZFS frisst meinen ganzen RAM“ → Der ARC nutzt freien Speicher als Cache, und free zählt ihn als used → Größe des ARC in den arcstats ablesen und von used abziehen; nur eingreifen, wenn Programme wirklich zu wenig Speicher bekommen. Diagnose-Schritte: ZFS belegt sehr viel RAM.
• RAM nach Plattengröße gekauft → Die 1-GB-pro-TB-Regel ist keine allgemeine Anforderung der OpenZFS-Doku → RAM nach Diensten, VMs und Working Set planen.
• Deduplizierung „zum Platzsparen“ eingeschaltet → Die Dedup-Tabelle braucht laut Doku mindestens 1,25 GiB RAM pro TiB → vorher simulieren, meist reicht Kompression.
• VMs starten nicht oder werden beendet → Auf dem VM-Host belegt der ARC Speicher, den die VMs sofort brauchen → festes ARC-Limit setzen.
• ARC radikal auf wenige hundert MB begrenzt → Der Cache trifft kaum noch, die Platten arbeiten mehr → nur so weit begrenzen, wie es die anderen Dienste erfordern.

Weiterlesen #

• ZFS ARC verstehen und optimieren erklärt, wie der Cache entscheidet, was er behält, und wie du Treffer und Fehlzugriffe liest.
• ZFS ARC begrenzen zeigt, wann ein Limit sinnvoll ist und wie du es live und dauerhaft setzt.
• Welche Hardware braucht ZFS? ordnet CPU, Platten, Controller und ECC ein.
• ZFS-Deduplizierung erklärt, warum Dedup so viel Speicher braucht und wann es sich lohnt.
• Der ZFS-RAM- und ARC-Planer rechnet Defaults, Limits und die modprobe-Zeile für dein System aus.