Die Leistungsfähigkeit eines ZFS-Storage-Systems hängt maßgeblich von seinem Caching ab. Der Adaptive Replacement Cache (ARC) im RAM ist das zentrale Performance-Element von ZFS. Ergänzend kann der Level 2 ARC (L2ARC) auf einer SSD als zweite Cache-Stufe dienen. Wer diese beiden Mechanismen versteht und richtig konfiguriert, holt das Maximum aus seinem ZFS-Pool heraus.
Wie der ARC funktioniert
Der ARC ist ein intelligenter Read-Cache im Arbeitsspeicher. Im Gegensatz zu einfachen LRU-Caches (Least Recently Used) nutzt der ARC den Adaptive Replacement Cache-Algorithmus, der zwei Zugriffsmuster gleichzeitig optimiert:
- MRU (Most Recently Used): Kürzlich gelesene Daten (temporale Lokalität)
- MFU (Most Frequently Used): Häufig gelesene Daten (frequenzbasierte Lokalität)
Der ARC passt das Verhältnis zwischen MRU und MFU dynamisch an das tatsächliche Zugriffsmuster an. Ein Datenbankserver mit vielen Wiederholungszugriffen profitiert vom MFU-Anteil, während ein Fileserver mit sequentiellen Zugriffen den MRU-Anteil bevorzugt.
ARC-Struktur im Detail
┌─────────────────────────────────────────────┐
│ ARC (RAM) │
├──────────────────────┬──────────────────────┤
│ MRU-Liste │ MFU-Liste │
│ (kürzlich gelesen) │ (häufig gelesen) │
├──────────────────────┼──────────────────────┤
│ Ghost-MRU-Liste │ Ghost-MFU-Liste │
│ (evicted Metadaten) │ (evicted Metadaten) │
└──────────────────────┴──────────────────────┘Die Ghost-Listen speichern Metadaten über kürzlich entfernte Einträge. Wird ein Eintrag aus der Ghost-MRU-Liste erneut angefragt, vergrößert der ARC die MRU-Liste auf Kosten der MFU-Liste — und umgekehrt. So lernt der Cache kontinuierlich das optimale Verhältnis.
ARC-Tuning
arc_max: Maximale ARC-Größe
Der wichtigste Tuning-Parameter ist arc_max — die Obergrenze des ARC im RAM. Standardmäßig nutzt ZFS bis zu 50 Prozent des gesamten RAMs für den ARC (bei Systemen mit mehr als 4 GB).
# Aktuelle ARC-Größe und Limits anzeigen
arc_summary | grep -A5 "ARC size"
# Oder direkt aus /proc
cat /proc/spl/kstat/zfs/arcstats | grep -E "^(size|c_max|c_min)"Faustregel für arc_max:
| Einsatzbereich | arc_max Empfehlung |
|---|---|
| Dedizierter NAS/Fileserver | 75–80 % des RAMs |
| NAS + wenige VMs/Container | 50–60 % des RAMs |
| Hypervisor mit ZFS-Storage | 30–40 % des RAMs |
| Gemischte Workloads | 50 % des RAMs (Standard) |
arc_max konfigurieren
Auf TrueNAS SCALE (Web-GUI):
System > Advanced > Sysctl:
Name: vfs.zfs.arc_max
Value: 17179869184 (16 GB in Bytes)Auf Linux (manuell):
# Temporär setzen
echo 17179869184 > /sys/module/zfs/parameters/zfs_arc_max
# Permanent in /etc/modprobe.d/zfs.conf
echo "options zfs zfs_arc_max=17179869184" >> /etc/modprobe.d/zfs.conf
# Nach dem nächsten Reboot aktiv, oder:
update-initramfs -uarc_min: Minimale ARC-Größe
arc_min definiert die Untergrenze, unter die der ARC nicht schrumpfen soll. Dies verhindert, dass speicherhungrige Anwendungen den ARC vollständig verdrängen.
# arc_min auf 4 GB setzen
echo "options zfs zfs_arc_min=4294967296" >> /etc/modprobe.d/zfs.confEine sinnvolle arc_min-Größe liegt bei 25–50 Prozent von arc_max. Zu hohe Werte können dazu führen, dass Anwendungen nicht genug RAM erhalten.
Metadaten-Cache priorisieren
ZFS speichert im ARC sowohl Daten als auch Metadaten (Directory-Einträge, Inode-Informationen). Für Fileserver mit Millionen kleiner Dateien kann es sinnvoll sein, Metadaten im Cache zu priorisieren:
# Metadaten-Anteil prüfen
arc_summary | grep -A10 "ARC hash"
# Metadaten-Limit erhöhen (Standard: 25% des ARC)
echo "options zfs zfs_arc_meta_limit_percent=35" >> /etc/modprobe.d/zfs.confL2ARC: Second-Level Cache auf SSD
Der L2ARC erweitert den ARC um eine zweite Cache-Stufe auf einer SSD oder NVMe. Daten, die aus dem ARC verdrängt werden, können in den L2ARC geschrieben werden und stehen dort für erneute Lesezugriffe zur Verfügung.
Wann ist L2ARC sinnvoll?
L2ARC ist nicht immer die richtige Lösung. Die Entscheidung hängt von mehreren Faktoren ab:
L2ARC lohnt sich bei:
- Working Set größer als verfügbarer RAM
- Viele zufällige Lesezugriffe (Random Read)
- Langsame Hauptspeicher-Medien (HDDs)
- Kosten für zusätzlichen RAM sind prohibitiv
L2ARC lohnt sich NICHT bei:
- Working Set passt in den ARC (genug RAM vorhanden)
- Überwiegend sequentielle Zugriffe (Streaming, Backup)
- Überwiegend Schreiboperationen (L2ARC ist nur ein Read-Cache)
- Weniger als 32 GB RAM im System
Warum 32 GB RAM als Minimum?
Der L2ARC benötigt RAM für seine Indexstruktur. Pro L2ARC-Eintrag werden etwa 200 Bytes im ARC für die Metadaten verbraucht. Bei einer 1-TB-L2ARC-SSD mit durchschnittlicher Blockgröße von 128 KB ergibt sich:
1 TB / 128 KB = ~8 Millionen Einträge
8.000.000 × 200 Bytes = ~1,6 GB RAM für L2ARC-IndexDieser RAM fehlt dem ARC selbst. Bei Systemen mit wenig RAM kann der L2ARC-Index den ARC so stark schrumpfen, dass die Gesamtperformance sinkt.
L2ARC einrichten
# SSD als L2ARC-Device hinzufügen
zpool add tank cache /dev/nvme1n1
# Ergebnis prüfen
zpool status tankBeispiel-Ausgabe:
pool: tank
state: ONLINE
config:
NAME STATE
tank ONLINE
raidz1-0 ONLINE
sda ONLINE
sdb ONLINE
sdc ONLINE
cache
nvme1n1 ONLINEL2ARC Sizing
Die Größe des L2ARC-Devices sollte sich am Working Set orientieren:
| Szenario | L2ARC-Größe |
|---|---|
| Fileserver (100 TB Pool) | 200–500 GB |
| Virtualisierung (50 TB Pool) | 100–200 GB |
| Datenbank (10 TB Pool) | 50–100 GB |
Größer ist nicht immer besser. Ein zu großer L2ARC verbraucht unnötig RAM für den Index und bietet diminishing returns.
L2ARC-Tuning-Parameter
# Maximale Schreibgeschwindigkeit in den L2ARC (Bytes/s)
# Standard: 8 MB/s (zu niedrig für NVMe)
echo "options zfs l2arc_write_max=104857600" >> /etc/modprobe.d/zfs.conf
# Boost beim ersten Befüllen (Bytes/s)
echo "options zfs l2arc_write_boost=209715200" >> /etc/modprobe.d/zfs.conf
# Headroom (Multiplikator für Schreibgeschwindigkeit)
echo "options zfs l2arc_headroom=8" >> /etc/modprobe.d/zfs.conf
# L2ARC über Reboots persistent machen (seit OpenZFS 2.0)
echo "options zfs l2arc_rebuild_enabled=1" >> /etc/modprobe.d/zfs.confDie Option l2arc_rebuild_enabled=1 ist besonders wichtig: Ohne sie verliert der L2ARC seinen Inhalt bei jedem Reboot und muss von Grund auf neu befüllt werden.
Monitoring mit arc_summary
Grundlegende ARC-Statistiken
# Vollständige ARC-Zusammenfassung
arc_summary
# Ausgabe (Auszug):
# ARC size (current): 14.2 GiB
# Target size (adaptive): 16.0 GiB
# Min size (hard limit): 4.0 GiB
# Max size (high water): 16.0 GiB
#
# ARC efficiency: 94.31%
# Cache hit ratio: 94.31%
# Demand data hit ratio: 96.12%
# Prefetch data hit ratio: 78.45%Wichtige Kennzahlen
| Kennzahl | Bedeutung | Zielwert |
|---|---|---|
| Cache Hit Ratio | Anteil der Lesezugriffe aus dem Cache | > 90 % |
| ARC Size vs. Max | Nutzung des verfügbaren Cache | 80–100 % |
| L2ARC Hit Ratio | Treffer im L2ARC | > 50 % |
| Eviction Rate | Rate der Cache-Verdrängungen | Niedrig |
Kontinuierliches Monitoring
# ARC-Statistiken im Zeitverlauf beobachten
arcstat 5
# Gibt alle 5 Sekunden eine Zeile mit den wichtigsten Metriken aus
# Ausgabe:
# time read miss miss% dmis dm% pmis pm% mmis mm% size c
# 09:15:01 1.2K 52 4.3% 32 3.1% 20 12% 0 0% 14.2G 16.0G
# 09:15:06 3.4K 123 3.6% 89 2.8% 34 15% 0 0% 14.2G 16.0GL2ARC-Statistiken
# L2ARC-spezifische Statistiken
arc_summary | grep -A20 "L2ARC"
# Oder direkt:
cat /proc/spl/kstat/zfs/arcstats | grep l2_
# Wichtige Werte:
# l2_hits: Treffer im L2ARC
# l2_misses: Fehlgriffe im L2ARC
# l2_size: Aktuelle L2ARC-Füllmenge
# l2_hdr_size: RAM-Verbrauch des L2ARC-IndexPraktisches Beispiel: Tuning eines TrueNAS-Systems
Szenario: TrueNAS SCALE mit 64 GB RAM, 100 TB HDD-Pool, gemischte Workloads (SMB-Fileserver + 5 VMs).
# Empfohlene Konfiguration:
# ARC: 40 GB (62.5% des RAMs, Rest für VMs)
vfs.zfs.arc_max = 42949672960
# ARC-Minimum: 16 GB
vfs.zfs.arc_min = 17179869184
# Metadaten-Limit: 35% des ARC
vfs.zfs.arc_meta_limit_percent = 35
# L2ARC: 500 GB NVMe
# l2arc_write_max: 100 MB/s
# l2arc_rebuild_enabled: 1Die 24 GB RAM außerhalb des ARC stehen für das Betriebssystem, VMs und Container zur Verfügung.
SLOG vs. L2ARC: Nicht verwechseln
Ein häufiger Irrtum: Der SLOG (Separate Log Device) ist kein Cache. Er beschleunigt synchrone Schreibvorgänge (ZIL), während der L2ARC Lesezugriffe beschleunigt.
| Device | Funktion | Workload |
|---|---|---|
| L2ARC | Read-Cache (erweitert ARC) | Random Reads |
| SLOG | Synchron-Write-Log (ZIL) | Synchrone Writes (NFS, iSCSI, Datenbanken) |
Beide können auf derselben NVMe-SSD liegen — aber auf getrennten Partitionen:
# NVMe partitionieren: 32 GB SLOG + Rest L2ARC
sgdisk -n 1:0:+32G -n 2:0:0 /dev/nvme1n1
# SLOG hinzufügen
zpool add tank log /dev/nvme1n1p1
# L2ARC hinzufügen
zpool add tank cache /dev/nvme1n1p2Fazit
Der ZFS ARC ist der leistungsstärkste Cache in der Storage-Welt — und gleichzeitig der am häufigsten falsch konfigurierte. Die wichtigste Maßnahme ist ausreichend RAM: Jeder Gigabyte RAM im ARC bringt mehr als ein Gigabyte SSD im L2ARC. Erst wenn der RAM nicht weiter aufgestockt werden kann, lohnt sich der L2ARC als zweite Cache-Stufe. Mit den richtigen Tuning-Parametern und regelmäßigem Monitoring via arc_summary und arcstat lässt sich die ZFS-Performance gezielt optimieren.
Mehr zu diesen Themen:
Weitere Artikel
Backup-Strategie für KMU: Proxmox PBS + TrueNAS als zuverlässiges Backup-Konzept
Backup-Strategie für KMU mit Proxmox PBS und TrueNAS: 3-2-1-Regel umsetzen, PBS als primäres Backup-Target, TrueNAS-Replikation als Offsite-Kopie, Retention Policies und automatisierte Restore-Tests.
TrueNAS mit MCP: KI-gestützte NAS-Verwaltung per natürlicher Sprache
TrueNAS mit MCP (Model Context Protocol) verbinden: KI-Assistenten für NAS-Verwaltung, Status-Abfragen, Snapshot-Erstellung per Chat, Sicherheitsaspekte und Zukunftsausblick.
ZFS SLOG und Special VDEV: Sync Writes beschleunigen und Metadaten optimieren
ZFS SLOG (Separate Intent Log) und Special VDEV erklärt: Sync Writes beschleunigen, SLOG-Sizing, Special VDEV für Metadaten, Hardware-Auswahl mit Optane und Risiken bei Ausfall.