Warum schrumpft der ZFS-ARC, wenn lokale KI fest zugewiesenen Host-Speicher verwendet?
Der ZFS-ARC schrumpft bei der Verwendung fest im Host-Speicher verankerter Speicherbereiche, weil nicht rückforderbare AI-Transferpuffer den Druck auf den vom Kernel rückforderbaren Speicher erhöhen, einschließlich des Dateisystem-Caches.
GPU-Laufzeitumgebungen verankern Host-Seiten im Speicher, damit Geräte Daten übertragen können, ohne dass diese Seiten während des Vorgangs verschoben oder ausgelagert werden. Das verbessert die Vorhersagbarkeit von DMA, doch fest verankerte Speicherzuweisungen eignen sich bei knappem verfügbarem RAM schlecht als Rückforderungsziele. Linux startet Rückforderung und Shrinker, und ZFS reagiert, indem es zwischengespeicherte Blöcke entfernt oder das ARC-Ziel senkt, sodass mehr Speicher für nicht freigebbare Zuweisungen verfügbar bleibt.
Fest verankerte Seiten verändern, welchen Speicher der Kernel zurückfordern kann
Gewöhnliche anonyme Seiten können ausgelagert werden, und saubere Seiten aus dem Dateicache können verworfen werden. Langfristig fest verankerte Seiten bleiben resident, weil ein Gerät oder Treiber von ihrer physischen Zuordnung abhängt. Dadurch wird der flexible Pool kleiner, der für neue Zuweisungen zur Verfügung steht.
Die Linux-Dokumentation zur langfristigen Seitenverankerung unterscheidet die langfristige Seitenverankerung von gewöhnlichen Referenzen und erklärt, warum DMA-Nutzer Seiten entsprechend markieren müssen. Dieser Mechanismus macht fest verankerten Speicher qualitativ anders als eine Prozesszuweisung, die der Kernel problemlos verschieben oder zurückfordern kann.
AI-Frameworks verwenden fest verankerte Staging-Puffer für schnellere Kopien vom Host zum Gerät, Dataloader-Warteschlangen und das Auslagern. Mehrere Worker oder übergroße Prefetch-Warteschlangen können deutlich mehr Host-Speicher verankert halten, als ein einzelner sichtbarer Batch vermuten lässt. Dieser Unterschied bleibt bei späteren Tests im Haushalt sichtbar.
Der ARC ist absichtlich ein großer rückforderbarer Verbraucher
Der Adaptive Replacement Cache hält kürzlich und häufig verwendete ZFS-Blöcke vor, um Lesezugriffe auf den Speicher zu vermeiden. Unter Linux nimmt er an der Verarbeitung von Speicherdruck teil und kann seine residente Größe verringern, wenn das System Seiten an anderer Stelle benötigt. Das Zwischenergebnis muss überprüfbar bleiben, bevor die Automatisierung fortgesetzt wird.
Die Dokumentation zu ARC-Größe und Rückforderung von OpenZFS beschreibt die Steuerung der ARC-Größe und Rückforderungs-Tuningparameter. Ein konfiguriertes Maximum ist eine Obergrenze und keine Zusicherung, dass zwischengespeicherte Daten unter Druck resident bleiben. Diese Grenze sollte unter realistischen Betriebsbedingungen separat gemessen werden.
Wenn fest verankerte Puffer wachsen, kann das Entfernen von ARC-Einträgen die richtige Reaktion und kein Speicherleck sein. Die Folge zeigt sich später in niedrigeren Cache-Trefferraten, mehr Lesezugriffen auf den Datenträger und langsameren Dateizugriffen nach Ende des AI-Jobs, bis sich der Cache wieder aufgewärmt hat.
Unified Memory und Container-Metriken können die Konkurrenz verbergen
Bei einer integrierten GPU greifen Modell-Tensoren und Dateisystem-Cache auf denselben physischen RAM zu, auch wenn Dashboards die Nutzung unterschiedlich kennzeichnen. Bei einer diskreten GPU bleibt das Host-Staging vom VRAM getrennt, konkurriert auf dem Server aber weiterhin mit dem ARC.
Die OpenZFS-Implementierung des ARC-Shrinkers registriert das ARC-Rückforderungsverhalten bei der Speicherverwaltung des Kernels. Hinweise auf Quellcodeebene helfen dabei, absichtliches Verkleinern des Caches davon zu unterscheiden, dass eine Anwendung ZFS direkt zum Verwerfen von Blöcken auffordert. Die praktische Folge zeigt sich, wenn mehrere Quellen um einen begrenzten Kontext konkurrieren.
Die Fehlergrenze besteht darin, bei sinkendem ARC automatisch von fest verankertem Speicher auszugehen. Ein großer Dateiscan, explizite ARC-Limits, Metadatendruck, Cgroup-Rückforderung, wachsender virtueller Maschinenspeicher oder normales adaptives Verhalten können dasselbe Diagramm erzeugen. Bestätigen Sie die Anzahl der verankerten Seiten und den Zeitpunkt der Zuweisungen.
Verankerte Bytes mit ARC-Rückforderung und Cache-Fehlzugriffen korrelieren
Führen Sie einen festgelegten AI-Workload aus und zeichnen Sie dabei den verankerten oder nicht auslagerbaren Speicher, MemAvailable, Rückforderungsstillstände, ARC-Größe und -Ziel, ARC-Trefferrate, ZFS-Lesezugriffe, die Größe des Pools für verankerte Puffer, die Worker-Anzahl, Batch-Größe, VRAM und Anfragelatenz auf. Fügen Sie eine Speicher-Baseline ohne AI hinzu.
Verwenden Sie den gemeinsam genutzten Host-Speicher, um CPU-, Speicher- und Speichersymptome voneinander zu trennen. Wiederholen Sie den Test mit auslagerbaren Übertragungen, einer geringeren Prefetch-Tiefe, weniger Workern und einem begrenzten Pool für verankerte Puffer. Ändern Sie pro Durchlauf nur eine Steuergröße. Diese Abhängigkeit sollte in der finalen Oberfläche ausdrücklich sichtbar bleiben.
Ordnen Sie das Verankern als kausal ein, wenn die ARC-Verkleinerung mit dem Wachstum des verankerten Speichers zusammenfällt und bei einem kleineren Pool nachlässt. Begrenzen Sie den Pool, wenn Speicher-Cache-Fehlzugriffe andere Dienste beeinträchtigen, behalten Sie aber ausreichend Verankerung bei, damit der Beschleuniger nicht ausgebremst wird. Das richtige Gleichgewicht hängt von der gleichzeitigen NAS-Last ab.
Empfohlene Produkte
Tech- & KI-Zentrum
Mehr zum Lesen
Warum erreichen SMB-Dateiänderungen einen inkrementellen Indexer in Schüben?
Erfahren Sie, wie SMB-Schreib-Caching, Leases, CHANGE_NOTIFY, Pufferüberläufe, Wiederverbindungen und die Stapelverarbeitung des Indexers stetige Bearbeitungen in stoßartige Aufnahmeereignisse verwandeln.
Warum erkennt die OCR nach der erneuten Komprimierung einer PDF-Datei blassen Text nicht?
Erfahren Sie, wie die PDF-Neukomprimierung schwache Pixel verändert, warum Viewer den Qualitätsverlust verbergen können und wie Sie Auflösung, Kontrast, Codec und OCR-Vorverarbeitung testen.
Warum schwankt die Latenz lokaler KI mit der Lüfterkurve eines Heimservers?
Erfahren Sie, wie Wärme, Lüftersteuerung, Taktbegrenzungen, Sensorverzögerungen und das Timing der Arbeitslast periodische lokale KI-Latenzen verursachen - und wie Sie den Zusammenhang nachweisen.
