Proxmox-Host: ZFS-ARC und L2ARC sauber tunen

ZFS ist auf Proxmox-Hosts der Standard für lokale Storage-Pools — robust, mit Snapshots, Replikation und Self-Healing. Was viele Administratoren unterschätzen: Der Adaptive Replacement Cache (ARC) ist kein “nice to have”, sondern der entscheidende Performance-Faktor. Standardmäßig beansprucht der ARC unter Proxmox VE 8.x bis zu 50 Prozent des Hauptspeichers. Auf einem Host mit 256 GB RAM sind das 128 GB — ein Wert, der sich mit VM-Workloads, Backups und L2ARC schnell beißt.

In diesem Beitrag zeigen wir, wie Sie zfs_arc_max korrekt setzen, wann ein L2ARC tatsächlich Sinn ergibt und welche Fallstricke wir in Kundenprojekten regelmäßig sehen. Die Tipps gelten für Proxmox VE 8.3 und 9.0 mit OpenZFS 2.2.x.

ARC verstehen: Was wirklich im RAM liegt

Der ARC ist ein In-Memory-Cache für Datenblöcke (data) und Metadaten (metadata). Anders als der klassische Linux-Page-Cache nutzt er einen Two-List-Algorithmus aus MRU und MFU und liefert auf typischen SMB-Workloads Hit-Raten zwischen 95 und 99 Prozent — vorausgesetzt, er hat genug Platz.

Den aktuellen Zustand prüfen Sie mit arc_summary aus dem Paket zfsutils-linux:

arc_summary | head -40
arcstat 1 10

Interessant sind vor allem die Felder ARC size, Target size (adaptive), Hit ratio und Most Frequently Used (MFU). Liegt die Hit-Ratio unter 90 Prozent, ist der ARC zu klein — oder Ihre Workload macht keinen Cache-Sinn (z. B. lineare Backups, große Mediastreams).

zfs_arc_max sauber setzen

Den ARC-Maximalwert konfigurieren Sie persistent über /etc/modprobe.d/zfs.conf. Die Werte sind in Byte anzugeben:

# /etc/modprobe.d/zfs.conf
# 32 GB ARC max, 8 GB ARC min
options zfs zfs_arc_max=34359738368
options zfs zfs_arc_min=8589934592

Damit der Wert beim Boot greift, müssen Sie die Initramfs neu erzeugen:

update-initramfs -u -k all
reboot

Eine Live-Anpassung ist möglich, aber nur, solange der neue Wert kleiner als der aktuelle ist — der ARC schrumpft nie gegen den Willen des Kernels nach oben:

echo 34359738368 > /sys/module/zfs/parameters/zfs_arc_max

Faustregeln für die ARC-Größe

RAM gesamt	VM-Workload	Empfohlener zfs_arc_max	Reserve VMs/Host
64 GB	leicht	16 GB	~46 GB
128 GB	gemischt	32 GB	~92 GB
256 GB	DB-/Mail-VMs	64 GB	~188 GB
512 GB	Heavy-IO	96-128 GB	~380 GB

Wichtig: Diese Werte sind Startpunkte. Prüfen Sie nach zwei Wochen Produktion mit arc_summary, ob die Hit-Ratio passt. Bei VMs mit eigenem Caching (z. B. PostgreSQL, MariaDB mit großem innodb_buffer_pool) reicht ein kleinerer Host-ARC.

L2ARC: Wann eine Cache-SSD wirklich hilft

L2ARC ist eine SSD als zweite Cache-Stufe vor den HDDs. Klingt verlockend, ist aber in der Praxis seltener sinnvoll als gedacht. L2ARC hilft, wenn:

• der Working-Set deutlich größer ist als der RAM,
• die Workload read-heavy ist (mindestens 70 Prozent Reads),
• viele zufällige Lesezugriffe auf einen “warmen” Datensatz erfolgen,
• der RAM bereits am Limit ist und nicht erweiterbar.

L2ARC hilft nicht bei:

• write-heavy Workloads (L2ARC ist Read-Only-Cache),
• sequentiellen Streams (Backups, Video),
• Pools, die bereits aus SSDs/NVMe bestehen.

Ein L2ARC kostet zusätzlich RAM für Header-Tabellen: rund 70-90 Byte pro Datenblock. Bei 1 TB L2ARC und 128k-Blöcken sind das etwa 700 MB — bei 16k-Blöcken über 5 GB. Dieser Speicher fehlt dem ARC.

L2ARC-Device hinzufügen:

zpool add rpool cache /dev/disk/by-id/nvme-Samsung_PM9A3_960GB
zpool status rpool

Persistent L2ARC aktivieren

Seit OpenZFS 2.0 überlebt der L2ARC einen Reboot. Auf Proxmox VE 8.x/9.x ist das Feature dabei, aber nicht immer aktiv:

echo 1 > /sys/module/zfs/parameters/l2arc_rebuild_enabled

Persistent in /etc/modprobe.d/zfs.conf:

options zfs l2arc_rebuild_enabled=1
options zfs l2arc_write_max=67108864      # 64 MB/s warm-up
options zfs l2arc_write_boost=134217728   # 128 MB/s während Boot
options zfs l2arc_noprefetch=0            # auch Prefetch cachen

Den L2ARC-Status sehen Sie unter arc_summary -s l2arc. Eine Hit-Ratio unter 20 Prozent bedeutet meist: L2ARC bringt nichts, die SSD-Slots besser für ein Special VDEV oder Mirror nutzen.

Häufige Fallstricke

Prefetch: Der ZFS-Prefetcher kann auf Datenbank-Workloads Cache-Pollution verursachen. Prüfen mit arcstat. Deaktivieren bei reinem OLTP-Workload:

echo 1 > /sys/module/zfs/parameters/zfs_prefetch_disable

Für gemischte Workloads bleibt der Default (0) richtig.

VM-Ballooning vs. ARC: Wenn Sie KVM-Ballooning aktiv haben, kann der Kernel den ARC bei Speicherdruck zwar shrinken — aber träge. Die VM bekommt RAM, der ARC liefert plötzlich nur 70 Prozent Hit-Ratio, die Pool-Latenz steigt. Empfehlung: Auf Proxmox-Hosts mit ZFS Ballooning deaktivieren und RAM statisch zuweisen.

Swap auf ZFS: Ein klassischer Performance-Killer. Wenn der Host swappt und der Swap auf einem ZVOL liegt, kommt der ARC nicht hinterher. Swap separat auf eine kleine Partition oder gleich vm.swappiness=10 setzen.

Backups: Proxmox Backup Server liest sequentiell und füllt den ARC mit Daten, die nicht wiederkommen. Bei Bedarf primarycache=metadata auf Datasets setzen, die nur für Backup-Targets dienen.

Monitoring: Was Sie regelmäßig prüfen sollten

Wir empfehlen, ARC-Metriken in Ihr Monitoring (Zabbix, Checkmk, Prometheus mit node_exporter und zfs_collector) aufzunehmen. Die wichtigsten Werte:

• arc_hit_ratio — Ziel: > 95 Prozent
• arc_size / arc_target — sollten dicht beieinander liegen
• l2_hit_ratio — > 30 Prozent rechtfertigt den L2ARC
• pool_alloc und frag per zpool list — Pool-Fragmentierung > 50 Prozent ist ein Warnsignal

Wir bauen für unsere Kunden im Rahmen der Proxmox-Beratung standardisierte Checkmk-Templates, die diese Metriken alarmieren — inklusive Schwellwerte für ARC-Shrink-Events. Für reine Backup-Targets lohnt sich oft eine eigene Tuning-Strategie mit reduziertem ARC und L2ARC.

Fazit

ZFS-ARC ist auf Proxmox-Hosts der unterschätzte Hebel für Performance. Mit einer sauber dimensionierten zfs_arc_max, deaktiviertem Ballooning und realistischer Erwartungshaltung an L2ARC holen Sie aus bestehender Hardware spürbar mehr heraus. Ein L2ARC ist kein Allheilmittel — er kostet RAM und hilft nur bei spezifischen Workloads. Im Zweifel: erst mehr RAM, dann Special VDEV, dann L2ARC.

DATAZONE unterstützt SMB-Kunden im Raum Neuburg, Ingolstadt und Augsburg bei der Auslegung von Proxmox-Clustern, ZFS-Pools und passender Hardware. Wenn Sie eine zweite Meinung zu Ihrer aktuellen Konfiguration brauchen oder eine Neuanschaffung planen, sprechen Sie uns gerne an — Kontakt aufnehmen.