ZFS ARC Cache: Speicherverbrauch richtig verstehen

ZFS ARC nutzt RAM aggressiv, um häufig gelesene Blöcke schnell bereitzustellen und dabei den tatsächlichen Speicherverbrauch dynamisch an die Last anzupassen. Ich erkläre, wie ich den scheinbar hohen Verbrauch richtig lese, welche Kennzahlen zählen und wie ich die Cache-Größe sicher steuere, ohne Performance zu verlieren.

Zentrale Punkte

Zur schnellen Orientierung fasse ich die wichtigsten Aussagen zusammen und markiere entscheidende Stichworte für einen klaren Überblick.

• ARC-Größe: Dynamisch, durch zfs_arc_max/min steuerbar
• Reclaimable: Cache-RAM wird bei Bedarf sofort freigegeben
• Trefferrate: Hohe Hit-Ratio zeigt sinnvollen Cache-Einsatz
• L2ARC: Ergänzung auf SSD/NVMe, kein Ersatz für RAM
• Dataset-Regeln: primarycache/secondarycache fein justieren

Ich nutze diese Punkte im Alltag, um Lesewege kurz zu halten und Speicher fair zu teilen. Ein voller ARC deutet auf aktive Nutzung hin und nicht auf einen Defekt oder ein verstecktes Leck. Erst wenn Swapping oder OOM-Ereignisse auftreten, setze ich klare Grenzen. Danach validiere ich die Änderungen mit Messwerten und adjustiere schrittweise den Rahmen. So halte ich Systeme flott, ohne andere Dienste auszubremsen oder riskante Schnellschüsse zu wählen.

Was der ARC im Speicher tatsächlich tut

Der ARC ist ein adaptiver Lese-Cache und kombiniert MRU (jüngst genutzt) mit MFU (häufig genutzt). Diese Mischung passt sich automatisch dem Muster an, das meine Workloads erzeugen, und hält genau die Blöcke bereit, die den stärksten Effekt liefern. Dadurch sinken Latenzen spürbar, weil Zugriffe direkt aus RAM erfolgen und nicht von Platten oder SSDs. Ich profitiere vor allem bei sich wiederholenden Zugriffen, denn die Trefferquote steigt mit jeder passenden Anfrage. Besonders bei VM-Images, Datenbanken und vielen kleinen Dateien entfaltet der Cache seine Stärke.

Gerade wegen dieser Arbeitsweise wirkt der RAM „voll“, obwohl ich weiterhin Reserven habe. Der belegte Cache ist jederzeit freigebbar, sobald Prozesse Speicher anfordern. So nutzt das System Leerlaufkapazität aktiv, statt sie ungenutzt liegen zu lassen, und hält Lastspitzen dennoch unter Kontrolle. Wer einen direkten Vergleich von Dateisystemen interessant findet, schaut sich meinen kompakten Performance-Vergleich an. Dort zeige ich, warum ein kluger Cache bei realen Workloads oft wichtiger wirkt als nackte Theorie.

Warum hoher RAM-Verbrauch gewollt ist

Ich bewerte „vollen“ RAM beim ARC positiv, solange das System nicht unter echter Speicherknappheit leidet. ZFS gibt Cache-Speicher umgehend frei, wenn Applikationen wachsen, und passt die Zielgröße laufend an. In typischen Tools erscheint dieser RAM als „belegt“, obwohl er für neue Prozesse ohne Verzögerung zur Verfügung steht. Ein echter Engpass zeigt sich erst durch Swapping, merkliche Lags oder OOM-Killer-Aktivität. Für das Verständnis hilft ein Blick auf Page-Cache-Unterschiede, weil Betriebssystem-Cache und ARC ineinandergreifen und beide den sichtbaren Verbrauch prägen.

Entscheidend ist daher der Kontext, nicht ein einzelner Screenshot eines Monitoring-Tools mit „0 GB frei“ als Schrecken. Ich prüfe zusätzlich I/O-Wartezeiten, Swap-Entwicklung und die Lastprofile der Hauptdienste. Fallen diese Werte unauffällig aus, lasse ich dem ARC Reichweite, um wiederkehrende Lesevorgänge maximal zu beschleunigen. Zeigen sich Engpässe, ziehe ich die Obergrenzen moderat an, statt den ARC hart zu kappen. So bleibt die Balance zwischen Caching-Gewinn und Anwendungsbedarf erhalten.

Wie ZFS die ARC-Größe festlegt

Ohne Vorgaben setzt ZFS eine sinnvolle Obergrenze basierend auf dem verfügbaren RAM. Ich steuere diese Dynamik mit zwei Parametern: zfs_arc_max als Obergrenze und zfs_arc_min als Untergrenze. Steht zfs_arc_max auf 0 oder bleibt ungesetzt, wählt ZFS automatisch einen passenden Bereich, häufig etwa die Hälfte des Speichers. In Lastspitzen schrumpft der ARC, aber nicht unter zfs_arc_min, damit wichtige Blöcke im RAM bleiben. Setze ich die Limits zu eng, sinkt die Trefferquote und Lese-I/O kehrt häufiger zur Platte zurück.

Praxis bedeutet hier: Viel RAM erlaubt einen großen Cache, der auf Datenbanken und VM-Hostings stark wirkt. Fehlt Speicher für andere Dienste, begrenze ich zfs_arc_max bewusst und halte zfs_arc_min flexibel. Ich teste in Etappen, beobachte die Effekte und stelle auf Basis von echten Trendwerten nach. Dadurch verhindere ich, dass ein einmaliger Peak die Konfiguration dominiert. Schrittweise Anpassung führt zu verlässlichem Verhalten ohne böse Überraschungen.

ARC-Kennzahlen richtig lesen

Zur Einordnung prüfe ich regelmäßig die wichtigsten Metriken und halte die Zusammenhänge in einer übersichtlichen Tabelle fest. Tools wie arcstat oder arc_summary liefern laufend Daten, die ich mit Pool-I/O und Applikationsmetriken verknüpfe. Dabei zählt das Gesamtbild mehr als ein einzelner Ausreißer im Diagramm. Gerade die Relation von Hits zu Misses zeigt, ob der Cache die Arbeitsmenge sinnvoll abdeckt. Hohe Trefferquoten deuten auf stabile Leistung und kurze Lesewege im RAM hin.

Kennzahl	Beschreibung	Worauf ich achte
ARC size	Aktuelle Cache-Größe im RAM	Wächst mit Last, schrumpft bei Bedarf spürbar
ARC c / c_max	Zielgröße und maximale Zielgröße	Annäherung an c_max bei hoher Last, Luft bei Ruhe
Hits / Misses	Treffer bzw. Verfehlungen seit Start	Misses dauerhaft hoch? Arbeitsmenge oder Cache-Politik prüfen
Hit-Ratio	Hits zu Gesamtzugriffen in %	Viele Wiederholungen: 80–90 % realistisch, sonst niedriger

Ich ziehe aus diesen Werten konkrete Schritte: Bleibt die Hit-Ratio gering, obwohl genug RAM frei ist, erhöhe ich vorsichtig zfs_arc_max und beobachte die Trends. Stehen Applikationen unter Druck, senke ich den Rahmen und messe Latenzen und I/O-Last erneut. Bringt ein größerer Cache keine Entlastung, liegt oft ein sehr zufälliges Zugriffsmuster vor, das Caching schlechter bedient. Dann wirken andere Maßnahmen wie bessere Datenlokalität oder Workload-Splitting meist stärker. Reine Cache-Vergrößerung löst nicht jedes Problem.

Wie der ARC Entscheidungen trifft: Ghost-Listen und Anpassung

Neben MRU und MFU nutzt der ARC sogenannte Ghost-Listen (MRU-/MFU-Ghost). Sie enthalten lediglich Metadaten kürzlich verdrängter Blöcke. Tauchen genau diese Blöcke kurz nach der Verdrängung wieder auf, wertet ZFS das als Hinweis, dass der entsprechende Bereich zu klein dimensioniert war, und verschiebt Kapazität zwischen MRU und MFU. So lernt der Cache aktiv aus Fehleinschätzungen. In der Praxis heißt das: Schwankende Muster (z. B. Batch-Fenster am Abend) werden nach wenigen Zyklen besser bedient, ohne dass ich manuell eingreifen muss.

Ich beobachte in diesem Kontext vor allem, ob Misses in Wellen auftreten und danach die Trefferquote sichtbar anzieht. Passiert das, greift die ARC-Logik wie gewünscht. Bleiben Misses trotz Wiederholungen hoch, ist häufig der Arbeitssatz größer als der verfügbare Cache oder die Zugriffsmuster sind zu zufällig.

Wann der ARC tatsächlich stört

In Shared-Hosting-Setups teile ich Speicher mit vielen Diensten, da kann ein dominanter ARC die Luft zum Atmen nehmen und Swapping fördern. Betreiber von Virtualisierungshosts kennen den Spagat: Jede VM freut sich über mehr RAM, während ZFS ebenfalls Cache-Ressourcen nutzen möchte. Auf kleinen Systemen mit wenigen Gigabyte halte ich die Grenzen enger, damit die Reaktionszeit der Dienste nicht unter Druck gerät. Auffällig werden Probleme durch träge Anwendungen, Zunahme von Swap-Nutzung oder Alerts durch den OOM-Killer. In diesen Lagen setze ich klare Obergrenzen und lasse dem System danach ein paar Tage für Vergleiche.

Ich dokumentiere Symptome, Zeiten und betroffene Dienste. Trifft die Engstelle immer wieder zu gleichen Zeitfenstern auf, plane ich Umbauten wie Backup-Fenster, Drosselung von Indizierungen oder die Verlagerung großer Scans. Erst wenn organisatorische Schritte den Peak nicht abfedern, passe ich Technik und Limits an. Diese Reihenfolge bewahrt Spielraum und verhindert vorschnelle Eingriffe in sensiblen Produktionsumgebungen. So bleibt der Blick auf das Zusammenspiel von Cache, I/O und Applikationen klar.

Container, Cgroups und NUMA-Besonderheiten

In Container-Umgebungen gilt: Der ARC ist hostweit und nicht cgroup-begrenzt. Läuft ein Pod/Container an sein Memory-Limit, schützt ihn das nicht davor, dass der Host durch ARC und andere Prozesse in Druck gerät. Ich plane daher auf dem Host einen festen Puffer für Systemdienste und ZFS ein und lege die Container-Limits so, dass der physische RAM nicht bis zur Kante belegt wird. Auf NUMA-Systemen achte ich zudem darauf, dass starker Cross-Node-Zugriff vermieden wird, weil sonst Latenzen steigen. Gleichmäßige Verteilung großer VMs und eine realistische ARC-Grenze pro Host verhindern hier viele Überraschungen.

Best Practices für die Dimensionierung

Auf dedizierten File-Servern gebe ich dem ARC gern 60–80 % des RAM, weil andere Prozesse wenig Speicher fordern. Läuft daneben ein Stack mit Containern oder kleineren Diensten, starte ich mit 50–60 % und beobachte die dynamische Auslastung. Auf Hypervisoren setze ich oft 30–40 %, damit VMs genügend Eigen-RAM haben. zfs_arc_min lasse ich üblicherweise bei 25–50 % von zfs_arc_max, damit der Cache in Lastspitzen noch schrumpfen kann. Änderungen führe ich schrittweise durch und werte mehrere Tage an Messwerten aus.

Ich plane Puffer für Spikes ein, statt die Obergrenze auf Kante zu nähen. Für Schreibfenster, Backups oder Re-Indexing lasse ich bewusst Raum, damit das System nicht in ersatzloses Swapping kippt. Nach jeder Änderung prüfe ich, ob die Hit-Ratio weiter passt und ob Applikationen schneller reagieren. Bleibt die Lese-Performance hoch und verschwinden Engpässe, bestätige ich die Werte und notiere die Begründung. Diese Dokumentation hilft bei künftigen Kapazitätsfragen enorm.

Compressed ARC und Prefetch-Feintuning

Viele Workloads profitieren vom Compressed ARC: ZFS hält Daten im Cache komprimiert vor und dekomprimiert sie erst bei Zugriff. Das spart RAM und erhöht die effektive Cache-Reichweite. Ich behalte dabei die CPU-Last im Blick – bei sehr CPU-gebundenen Systemen überwiegt nicht immer der Gewinn. Für klar komprimierbare Daten (Logs, Text, VM-Images mit wenig Entropie) ist der Effekt meist deutlich. Ergänzend achtet der ZFS-Prefetch (zfetch) auf sequentielle Muster und lädt Folgeblöcke vor. Bei langen Stream-Reads, die ich ohnehin nicht cachen möchte (Backups, Medienpipelines), setze ich wie beschrieben primarycache eher auf Metadaten und lasse zfetch ansonsten auf den Defaults. Hartes Abschalten des Prefetch führt oft zu mehr Misses bei gemischten Lasten und ist für mich die Ausnahme, nicht die Regel.

Persistente Einstellungen sicher umsetzen

Grenzwerte für den ARC setze ich persistent, damit sie Neustarts überdauern, und ändere sie nur in konservativen Schritten. Erhöhungen sind unkritisch, das System nutzt den zusätzlichen Raum nach und nach. Absenkungen können kurzzeitig zu erhöhter Eviction und mehr I/O führen – ich senke daher in 10–20-%-Schritten und beobachte 24–48 Stunden. Nach großen Umbauten oder Kernel-/ZFS-Updates prüfe ich, ob die Werte noch plausibel sind, denn automatische Heuristiken können sich mit neuen Versionen ändern.

L2ARC klug einsetzen

Der L2ARC auf SSD/NVMe erweitert den Cache und bringt besonders bei großen, gut cachebaren Datenmengen einen spürbaren Schub. Ich nutze ihn erst, wenn die Messwerte zeigen, dass der RAM-ARC dauerhaft am Limit läuft und die Flash-Seite noch Luft hat. Wichtig: L2ARC ersetzt keinen RAM, denn Metadaten der gecachten Blöcke müssen im Haupt-ARC bleiben. Ein sehr großer L2ARC erhöht deshalb den RAM-Bedarf und kann bei unpassender Konfiguration sogar drosseln. Schreiben in den L2ARC kostet I/O-Bandbreite und CPU, das übersehe ich nicht.

Gut funktioniert L2ARC, wenn die Arbeitsmenge größer als der RAM ist, aber immer wieder ähnliche Dateien betrifft, etwa VM-Images oder viele kleine Objekte. Vor dem Ausbau prüfe ich mit I/O-Statistiken, ob die Flash-Seite freie Kapazität hat und nicht ohnehin am Limit hängt. Passen diese Rahmenbedingungen, liefert L2ARC oft konstant niedrigere Latenzen. Erst die Kombination aus sauberem Monitoring, gesunder RAM-Reserve und passend dimensioniertem L2ARC bringt die erhoffte Wirkung. Blindes Hinzufügen größerer SSDs löst selten echte Flaschenhälse.

L2ARC-Details: Aufwärmphase und Persistenz

Der L2ARC besitzt eine Aufwärmphase: Direkt nach dem Anlegen oder nach einem Neustart ist er zunächst leer beziehungsweise noch nicht voll nutzbar. Moderne Implementierungen können Metadaten persistent halten, sodass der L2ARC schneller wieder wirkt. Dennoch braucht das Befüllen Zeit und beansprucht I/O-Bandbreite. Ich drossele den Feed nicht unnötig, lasse aber genügend Reserven für Primär-Workloads. Besonders wichtig: Der L2ARC sollte nicht dieselben SSDs wie Log- oder transaktionale Workloads stressen. Eigene, latenzarme Geräte und ein realistisch kalkulierter RAM-Anteil für die L2ARC-Header sind Pflicht.

Dataset-Einstellungen: primarycache und secondarycache

Ich feine den Cache über Dataset-Optionen, damit ARC und L2ARC die richtigen Inhalte halten. primarycache steuert, ob Daten und/oder Metadaten im Haupt-ARC liegen, während secondarycache die Inhalte für den L2ARC festlegt. Bei großen, sequentiellen Streams (zum Beispiel Medienarchive) reicht es oft, Metadaten im ARC zu behalten und den eigentlichen Datenstrom nicht zu puffern. Bei Metadaten-lastigen Workloads cache ich Daten und Metadaten, um Latenzen zu senken. Diese Trennung verhindert Verschwendung und stärkt die relevanten Zugriffe.

Ich teste je Dataset gezielt, statt pauschal für alle Pools die gleiche Regel zu setzen. Ein korrekt eingestelltes primarycache/secondarycache reduziert unnötige I/O und hebt die Trefferrate an. In Summe resultiert daraus oft ein ruhigeres Systemverhalten mit besser planbarer Reaktionszeit. Auch hier gilt: Messen, anpassen, erneut messen. Die kleinen Stellschrauben bringen oft den entscheidenden Feinschliff.

Sonderfall Deduplizierung (DDT) und RAM-Bedarf

Aktiviere ich Deduplizierung, steigt der Speicherbedarf spürbar, weil die Dedup-Tabelle (DDT) im RAM vorgehalten werden muss, um effizient zu bleiben. Pro eindeutigem Block fallen Metadaten an; bei typischen Blockgrößen summiert sich das schnell auf mehrere Gigabyte. Reicht der RAM nicht, verlagert ZFS DDT-Zugriffe auf die Platten, was Latenzen erhöht und den ARC verdrängt. Meine Faustregel: Dedupe nur dort einschalten, wo hohe Redundanz sicher ist (z. B. VDI, identische VM-Images) und ausreichend RAM bereitsteht. Sonst ist Komprimierung oft der deutlich bessere Hebel.

Monitoring und Troubleshooting

Für einen gelassenen Betrieb prüfe ich fortlaufend ARC-Größe, Hit-Ratio, I/O-Profile und die systemweite Speicherlast. Bleibt der ARC ständig am Limit, ohne dass Applikationen leiden, lasse ich ihm Platz. Sehe ich Swapping oder Bewegung Richtung OOM, begrenze ich den Rahmen und analysiere die Hauptverursacher. Hilfreich ist ergänzend ein Blick auf vm.vfs_cache_pressure, um das Verhältnis von dentry/inode-Cache zum restlichen Speicher zu balancieren. Ich betrachte die Werte im Zusammenhang, nie isoliert.

Werkzeuge wie arcstat/arc_summary, zpool iostat sowie top/htop/free/vmstat liefern mir die nötigen Indizien. Ich gleiche Peaks mit Arbeitsfenstern ab und prüfe, ob die Probleme reproduzierbar auftreten. Tritt die Engstelle wiederholt auf, passe ich Zeitfenster, Drosselungen oder Cache-Limits an. Flacht die Kurve ab und bleiben Applikationen schnell, halte ich die Einstellung. So bilde ich Erfahrungen über Wochen und Monate, statt allein auf Momentaufnahmen zu reagieren.

ARC, Dirty Data und ZIL/SLOG auseinanderhalten

Zum Gesamtbild gehört, dass neben dem ARC auch Dirty Data (geänderte, noch nicht auf Platten geschriebene Blöcke) RAM belegt. Dieser Bereich wächst bis zu einer Obergrenze und wird dann asynchron geleert. Unter starker Schreiblast kann Dirty Data kurzfristig groß werden und das System bremsen, bevor ZFS mit Drosselmechanismen reagiert. Zusätzlich puffert das ZIL (ZFS Intent Log) synchrone Writes; ein schneller SLOG hilft, reduziert aber nicht den RAM-Verbrauch des ARC. Ich trenne diese Aspekte klar: Spürbare Schreib-Latenzen trotz guter Hit-Ratio deuten oft auf Dirty-Data- oder Log-Engpässe statt auf einen zu großen ARC hin.

Messmethodik: Zeitfenster und Trendanalyse

Da viele ZFS-Zähler kumulativ seit dem Boot laufen, werte ich sie im Tages- oder Wochenfenster aus. Ich bilde Raten (Hits/s, Misses/s) und vergleiche sie mit I/O-Wartezeiten und CPU-Last. Nach größeren Konfigurationsänderungen „nullen“ ich meine Vergleichswerte oder markiere den Zeitpunkt, damit Effekte sauber zugeordnet werden. Die Hit-Ratio bewerte ich pro Workload-Fenster (Produktionskernzeit, Nachtfenster, Batchläufe) – eine einzige Gesamtzahl verschleiert sonst echte Flaschenhälse.

Praxisbeispiel: Allround-Server mit 64 GB RAM

Ein gemischter Server mit Webanwendungen, Datenbank und Backups nutzt ohne Feintuning schnell 30–40 GB ARC. Die Datenbank braucht jedoch reichlich eigenen RAM, also setze ich zfs_arc_max auf etwa 24–28 GB und zfs_arc_min auf 8–12 GB. Nach einigen Tagen messe ich geringere Swap-Anteile und stabilere Latenzen, während häufig genutzte Daten weiterhin im Cache liegen. Das System wirkt reaktionsfreudig, weil Druckspitzen nicht mehr zeitgleich auf Datenbank und ARC treffen. Diese moderate Kappung erhält Durchsatz und verbessert die Antwortzeit spürbar im Tagesgeschäft.

Im nächsten Schritt optimiere ich Datasets: Für große sequentielle Backups reduziere ich den Anteil der reinen Daten im ARC und lasse Metadaten prio­ritär zu. Die Hit-Ratio passt weiterhin, gleichzeitig sinkt der Druck auf RAM in den nächtlichen Fenstern. Nach Abschluss der Umbauten halte ich die Entwicklung im Monitoring im Blick und reagiere nur bei anhaltenden Trends. Dauerhafte Stabilität schlägt kurzfristige Benchmarks in produktiven Umgebungen. So bleibt der Cache ein Gewinnbringer und kein Anlass für Alarm oder harte Drosselung.

Kurz zusammengefasst

Ich lese hohen Speicherverbrauch des ARC als Zeichen aktiver Nutzung und nicht als Makel. ZFS gibt den Cache bei Bedarf frei, während zfs_arc_max und zfs_arc_min den Korridor klar definieren. Aussagekräftig werden Setups erst durch passende Kennzahlen wie Hit-Ratio, ARC-Größe und I/O-Profile. L2ARC und Dataset-Optionen liefern mir weitere Hebel, wenn RAM knapp wird oder Datenmengen deutlich größer sind. Wer diese Grundlagen beherzigt, betreibt ZFS auf Dauer schnell, sparsam und mit verlässlicher Reaktionszeit.