ZFS-ARC-Optimierung: Obergrenzen, Grenzwerte und was gemessen werden sollte

ZFS beansprucht standardmäßig stillschweigend etwa die Hälfte Ihres System-RAMs für seinen Lese-Cache, und auf einem ungeeigneten Server führt dies zu Swap-Aktivität, OOM-Kills oder einer Datenbank, die mit dem Dateisystem um Speicher konkurriert. Bei der ZFS-ARC-Optimierung geht es darum, zu entscheiden, wie viel von diesem RAM der ARC tatsächlich behalten darf und worauf Sie verzichten, um das Limit festzulegen. Dieser Beitrag behandelt, wie der ARC Speicher nutzt, was Sie messen sollten, bevor Sie Änderungen vornehmen, die wenigen Einstellparameter, deren Änderung sich lohnt, sowie sinnvolle Ausgangspunkte für Dateiserver, Hypervisoren, Datenbanken und Backup-Ziele. Informationen zu den Snapshots von ZFS finden Sie in unserem Leitfaden zu ZFS-Snapshots.

Messen Sie ARC, bevor Sie irgendetwas optimieren

Ändern Sie keinen einzigen einstellbaren Parameter, bevor Sie Basiswerte aus einer normalen Spitzenauslastungsphase haben. Momentaufnahmen aus ruhigen Zeiten führen Sie in die falsche Richtung. Bei nächtlichen Backups, wöchentlichen Berichten und Batch-Jobs wird das ARC-Verhalten in der Regel besonders interessant – erfassen Sie daher Daten über mehrere Tage hinweg.

Drei Tools decken den Großteil Ihrer Anforderungen ab:

• arcstat 1 bietet eine live scrollende Ansicht der Hit- und Miss-Zähler, der Demand- gegenüber der Prefetch-Aktivität sowie der aktuellen ARC-Größe. Verwenden Sie es während Lasttests und Backup-Fenstern.
• arc_summary gibt einen einzelnen Snapshot aus: ARC-Größe und -Ziel, die Aufteilung zwischen MFU und MRU, Metadaten-Verhältnisse sowie aktive Einstellparameter. Führen Sie arc_summary -s arc nur für den ARC-Abschnitt aus.
• Die Rohzähler befinden sich /proc/spl/kstat/zfs/arcstats unter Linux und unter dem kstat.zfs.misc und vfs.zfs sysctl-Strukturen unter FreeBSD. Extrahieren Sie diese aus der Überwachung, anstatt formatierte Ausgaben zu analysieren.

Die Zähler, die vor jeder Änderung erfasst werden sollten:

Zwei Dinge werden hier häufig falsch verstanden. Beobachten Sie den verfügbaren Speicher, nicht den freien Speicher; Linux meldet geringen freien RAM-Speicher problemlos als Normalzustand, und das allein ist kein Problem. Das entscheidende Signal ist verfügbarer Speicher nahe Null in Kombination mit anhaltender Swap-Aktivität (die Einführung in die Linux-Speicherverwaltung erklärt, warum). Und betrachten Sie die Trefferquote als Trend, nicht als Ziel. Eine Trefferquote von 99 % auf einem Rechner, der auf den Swap ausweicht, ist ein Fehler bei der Optimierung, kein Erfolg.

Die vier entscheidenden ARC-Einstellparameter

Die meisten Optimierungen im Produktivbetrieb lassen sich auf vier Einstellungen zurückführen. Passen Sie die Einstellung an den Druck an, den Sie in der Baseline tatsächlich gemessen haben. Swap-Aktivitätspunkte weisen auf zfs_arc_max. Die Rückgewinnung von Churn, der einen „heißen“ Cache immer wieder leert, deutet auf zfs_arc_min. Langsame Verzeichnisdurchläufe deuten auf das Metadatenlimit hin.

Beginnen Sie mit der kleinsten Änderung, die das erkennbare Problem behebt. Für zfs_arc_maxhängt der richtige Höchstwert von der Arbeitslast ab (wird im nächsten Abschnitt behandelt). Für zfs_arc_minist ein Mindestwert von 25 % bis 50 % von zfs_arc_max ist ein vernünftiger Ausgangspunkt, falls Sie überhaupt einen benötigen. Für Metadaten stellen die aktuellen OpenZFS-Standardeinstellungen bereits 75 % des ARC zur Verfügung zfs_arc_meta_limit_percent, was für die meisten Workloads großzügig bemessen ist; greifen Sie hier nur ein, wenn Metadaten-Fehlgriffe deutlich sichtbar sind in arcstat.

Anwenden von Änderungen unter Linux und FreeBSD

Unter Linux können Sie eine Änderung zur Laufzeit testen, indem Sie in die sysfs-Parameterdatei schreiben. Ein Neustart ist nicht erforderlich:

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

Dadurch wird zfs_arc_max sofort auf 16 GiB. Damit die Änderung auch nach einem Neustart erhalten bleibt, fügen Sie sie in /etc/modprobe.d/zfs.conf:

options zfs zfs_arc_max=17179869184

Unter FreeBSD verwenden Laufzeitänderungen sysctl:

sysctl vfs.zfs.arc_max=17179869184

Behalten Sie denselben Wert in /boot/loader.conf:

vfs.zfs.arc_max="17179869184"

Ändern Sie jeweils nur eine Einstellung, in kleinen Schritten von etwa 10 % des gesamten Arbeitsspeichers. Beobachten Sie das Problemfenster. Behalten Sie die Änderung nur bei, wenn der Swap-Speicher bei Null bleibt und die Latenz stabil ist. Machen Sie die Änderung erst dauerhaft, nachdem der Laufzeittest erfolgreich war.

Anpassung der ARC an die Arbeitslast

Die Gesamt-RAM-Kapazität ist der falsche Ansatzpunkt. Die Dimensionierung des ARC sollte sich nach dem Workload-Mix auf dem Server richten.

Ein VM-Host muss den Speicher mit seinen Gästen teilen, daher ist eine Obergrenze von 30 % bis 40 % ein sicherer Standardwert, und 50 % sind bei den meisten Konfigurationen bereits zu hoch. Datenbanken wie PostgreSQL und MySQL verwalten ihre eigenen Puffer-Caches, daher reservieren Sie zunächst Speicher für die Engine und überlassen ARC den Rest. Backup-Ziele profitieren davon primarycache=metadata , da die gelesenen Daten selten erneut benötigt werden und man nicht möchte, dass ein nächtliches Backup den gesamten Pool durchläuft und dabei den Rest des Caches leert. Bei jeder Workload bedeutet Swap-Aktivität, während ARC auf zfs_arc_max bedeutet, dass die Obergrenze zu hoch ist; diese Regel gilt immer.

Probleme diagnostizieren und wissen, wann man aufhören muss

Ein zu klein dimensionierter ARC äußert sich in hohen Lese-IOPS, niedrigen Trefferquoten bei Abfragen und langsamer Verzeichnisnavigation, während das System noch über freien RAM verfügt. Ein überdimensionierter ARC ist weniger offensichtlich. Die Trefferquote sieht gut aus, aber der Rechner beginnt mit dem Swapping, die Lastdurchschnitte steigen, Prozesse bleiben im D Zustand, während der Kernel ARC-Seiten bei Bedarf freigibt, und im schlimmsten Fall beginnt der OOM-Killer, Opfer auszuwählen. Der Cache sieht intakt aus, doch der Server läuft miserabel.

Metadaten-Druck macht sich bemerkbar, wenn demand_metadata_bytes deutlich höher liegt als demand_data_bytes in arc_summary. Das bedeutet, dass Metadaten mit Daten um Speicherplatz konkurrieren und es sich lohnt, den prozentualen Grenzwert für Metadaten anzuheben.

Ordnen Sie das, was Sie sehen, der ersten zu überprüfenden Einstellung zu:

L2ARC ist nicht kostenlos. Der Index für L2ARC-Einträge befindet sich im primären ARC, und wenn dieser Overhead etwa ein Drittel der gesamten ARC-Kapazität übersteigt, schadet der sekundäre Cache mehr, als er nützt. Greifen Sie nur dann auf L2ARC zurück, wenn der Arbeitsspeicher größer als der RAM ist, aber dennoch auf ein schnelles NVMe-Laufwerk passt, und nur dann, wenn die Trefferquote des primären ARC bereits gut ist.

Der richtige Zeitpunkt, die Optimierung zu beenden, ist erreicht, wenn die Latenz konstant bleibt, der Swap während desselben Auslastungsfensters, das das ursprüngliche Problem verursacht hat, bei Null bleibt und weitere Änderungen keine Verbesserungen mehr bringen. Eine hohe Trefferquote bedeutet nichts, wenn der Server auslagert. Ab diesem Punkt sollten Sie keine Einstellungen mehr anpassen und diese erst dann erneut überprüfen, wenn das gleiche Problem unter derselben Auslastung erneut auftritt.

Wenn Sie einen Server mit ausreichendem RAM-Spielraum benötigen, um ZFS ordnungsgemäß auszuführen, ohne mit Ihren VMs oder Datenbanken um Speicher zu konkurrieren (es lohnt sich, zunächst zu lesen, wie viel RAM Sie tatsächlich benötigen), werfen Sie einen Blick auf die dedizierten FDC-Server.