SSD-Lese-Cache vs. direkter Festplattenzugriff bei NAS-Lesezugriffen durch mehrere Benutzer: Wann verändert die gemeinsame Wiederverwendung den Sieger?

Der SSD-Lese-Cache wird in einem NAS mit mehreren Benutzern wertvoller, wenn verschiedene Clients wiederholt dieselben häufig genutzten Blöcke anfordern, nachdem diese Blöcke nicht mehr in den Arbeitsspeicher passen. Der direkte Festplattenzugriff bleibt die bessere Grundlage, wenn Benutzer überwiegend unterschiedliche Daten lesen, die Arbeitslast sequenziell ist oder der HDD-Pool Anfragen bereits schneller bedient, als das Client-Netzwerk sie verarbeiten kann.

Die neue Entscheidungsvariable ist die gemeinsame Wiederverwendung. Zehn Benutzer machen einen Cache nicht automatisch sinnvoll: Zehn Personen, die zehn voneinander unabhängige Archive lesen, erzeugen kaum eine wiederverwendbare Arbeitsmenge, während drei Editoren, die wiederholt dieselben Projektdateien öffnen, mit einer einzigen zwischengespeicherten Kopie zahlreiche Festplattenzugriffe vermeiden können. Messen Sie die Überschneidung, nicht die Anzahl der Benutzer.

Die gemeinsame Wiederverwendung muss den RAM-Cache überstehen, bevor der SSD-Cache angerechnet wird

Wiederholte Lesezugriffe treffen normalerweise zuerst auf den Arbeitsspeicher und erst danach auf einen SSD-Cache. Bei ZFS ist ARC der primäre Lese-Cache und L2ARC die sekundäre SSD-/NVMe-Ebene. Wenn ein zweiter Benutzer dieselbe Datei öffnet, kann dies „SSD-schnell“ wirken, obwohl die Daten den Arbeitsspeicher nie verlassen haben. Ein Test mit mehreren Benutzern und bereits aufgewärmtem Cache muss daher ermitteln, welche Ebene die Anfrage bedient hat.

Klara Systems erklärt, dass L2ARC Blöcke speichert, die andernfalls aus ARC verdrängt würden, und besonders dann nützlich ist, wenn die aktive Arbeitsmenge größer als der Arbeitsspeicher, aber klein genug ist, um in Arbeitsspeicher plus L2ARC zu passen. Die Analyse von 2026 zur Passung der Arbeitsmenge für L2ARC liefert die richtige erste Hürde: Ein SSD-Cache ist erst dann relevant, wenn Speicherverfehlungen tatsächlich Zugriffe auf das Backend erzeugen.

Wenn ARC oder der Seitencache des Betriebssystems für die gemeinsam genutzten Daten bereits eine hohe Trefferquote liefert, verschiebt ein zusätzlicher SSD-Cache möglicherweise nur Kopien auf eine langsamere Ebene und verbraucht Arbeitsspeicher für Cache-Metadaten. Der direkte Festplattenzugriff ist unter diesen Bedingungen nicht einmal der eigentliche Konkurrent; der Arbeitsspeicher hat bereits gewonnen.

Mehrere Benutzer helfen nur, wenn sich ihre häufig genutzten Daten überschneiden

Der Zugriff durch mehrere Benutzer verändert die Cache-Ökonomie, wenn sich die Anfragen auf gemeinsame Daten konzentrieren: freigegebene Projektordner, Softwarepakete, VM-Vorlagen, Vorschaubilder, Indizes, Referenzmedien oder häufig durchsuchte Teamverzeichnisse. Eine einzige SSD-Kopie kann wiederholte Speicherverfehlungen mehrerer Clients bedienen, mechanische Suchvorgänge reduzieren und die HDD-Warteschlangen während ausgelasteter Zeiträume verkürzen.

Klaras umfassendere Anleitung zur Leistungsoptimierung beschreibt ARC als Ausgleich zwischen Aktualität und Zugriffshäufigkeit und weist darauf hin, dass häufig wiederverwendete Blöcke sich anders verhalten als einmalige Scans. Das zugriffshäufigkeitsbewusste Cache-Verhalten ist hier der entscheidende Mechanismus: Gemeinsame Wiederverwendung erhöht die Wahrscheinlichkeit, dass ein von einem Benutzer in den Cache beförderter Block für einen anderen weiterhin nützlich ist.

Die Anzahl der Benutzer ohne Überschneidung kann das Gegenteil bewirken. Wenn jedes Haushaltsmitglied oder jede Arbeitsstation ein separates Dataset liest, wächst die kombinierte Arbeitsmenge schneller und kann sowohl den RAM- als auch den SSD-Cache überlasten. Mehr Benutzer senken dann die Trefferquote, statt sie zu verbessern. Die Frage lautet nicht „Wie viele Clients sind verbunden?“, sondern „Wie viele gemeinsame, häufig genutzte Daten gibt es?“

Der direkte Festplattenzugriff gewinnt, wenn der sequenzielle Durchsatz oder das Netzwerk die Obergrenze festlegt

Die Wiedergabe großer Mediendateien, die Überprüfung von Backups und einmalige Archiv-Scans verlaufen oft sequenziell und greifen möglicherweise nur einmal auf jeden Block zu. Ein gesunder Festplattenpool mit mehreren Laufwerken kann diesen Datenverkehr effizient streamen, während der Cache kaum zukünftige Wiederverwendung sieht. Wenn 2,5-GbE oder 1-GbE bereits ausgelastet ist, verkürzt die Bereitstellung desselben Lesezugriffs von der SSD möglicherweise nicht die für den Client sichtbare Abschlusszeit.

Der Artikel zur L2ARC-Optimierung weist außerdem darauf hin, dass sequenzielle Prefetch-Daten nicht immer in L2ARC übernommen werden und dass ein Lese-Cache bei schreibintensiven Arbeitslasten oder Datasets, die deutlich größer als die Cache-Hierarchie sind, wirkungslos ist. Deshalb sollte ein Cache-Benchmark nicht nur eine zweite Kopie eines kleinen Ordners verwenden und das Ergebnis anschließend auf Streaming über mehrere Terabyte übertragen.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Cache-Überlastung kann die SSD-Ebene beschäftigt wirken lassen, ohne die Benutzer schneller zu machen

Ein SSD-Lese-Cache muss befüllt, indiziert und verwaltet werden. Wenn sich die kombinierte Arbeitsmenge ständig ändert, können nützliche Blöcke verdrängt werden, bevor ein anderer Benutzer sie wiederverwendet. Das Cache-Laufwerk kann eine hohe Aktivität anzeigen, während der HDD-Pool weiterhin viele Speicherverfehlungen verarbeitet. Deshalb ist die SSD-Auslastung allein kein Beleg für einen Nutzen.

Ein Community-Thread bei TrueNAS aus dem Jahr 2025 beschreibt eine gemischte NAS- und Proxmox-Arbeitslast, bei der die ARC-Trefferquoten normalerweise hoch waren, während sie bei Ereignissen wie dem Neustart vieler VMs stark abfielen und L2ARC einen erheblichen Anteil der Speicherverfehlungen auffing. Dieser Cache-Fall mit gemischter Arbeitslast ist als reales Betriebsmuster nützlich, nicht als universeller Zielwert für die Trefferquote.

Der Cache verliert an Wert, wenn er sich kontinuierlich leert und neu befüllt, knappen Arbeitsspeicher für Metadaten verbraucht oder fast so viel kostet wie die Ablage des bekannten häufig genutzten Datasets auf einem dedizierten SSD-Volume. Ein Cache ist eine adaptive Platzierung; eine dedizierte SSD-Ebene ist eine explizite Platzierung. Verwenden Sie Letztere, wenn vorhersehbare Latenz wichtiger ist als die automatische Übernahme in den Cache.

Testen Sie gemeinsam genutzte Arbeitsmengen statt eines einzelnen Clients, der einen Ordner wiederholt liest

Erstellen Sie drei Datasets: eine gemeinsame häufig genutzte Datenmenge für alle Clients, eine private Datenmenge pro Client und eine sequenzielle Archivdatenmenge. Führen Sie denselben Zugriffsplan zunächst ohne SSD-Cache und anschließend mit SSD-Cache aus. Zeichnen Sie ARC-/Seitencache-Treffer, SSD-Cache-Treffer, HDD-IOPS und -Latenz, Netzwerkauslastung sowie die Antwortzeit des Clients beim 95. Perzentil auf. Der Cache sollte die Arbeit der Backend-Festplatten für die gemeinsame Datenmenge reduzieren und nicht lediglich einen schnelleren zweiten Durchlauf erzeugen.

Leeren Sie Produktions-Caches nicht destruktiv, nur um einen Benchmark zu erstellen. Verwenden Sie ein Test-Dataset, das größer als der verfügbare Arbeitsspeicher ist, kontrollierte Neustarts, sofern angemessen, oder ausreichend lange Durchläufe, damit die gemeinsame Datenmenge die normale Hierarchie durchläuft. Vergleichen Sie sowohl das stabile Verhalten nach dem Aufwärmen als auch das Verhalten bei kaltem Cache, denn ein Cache, dessen Aufwärmen länger dauert als die Arbeitslast selbst, hat in der Praxis nur geringen Nutzen.

Der bestehende ZimaSpace-Artikel zum allgemeinen Entscheidungsprozess für wiederholte Lesezugriffe mit Cache beschreibt die Grenze der Arbeitsmenge bei einem einzelnen Benutzer. Dieser Test stellt eine zusätzliche Frage: Ob verschiedene Benutzer die Cache-Blöcke der jeweils anderen tatsächlich häufig genug wiederverwenden, um das Ergebnis zu verändern.

Verwenden Sie drei Ergebnisse, statt Cache gegen keinen Cache auszuspielen

Wählen Sie einen SSD-Lese-Cache, wenn die gemeinsam genutzte Arbeitsmenge den RAM übersteigt, sich zwischen Benutzern wiederholt, gut genug in die Cache-Ebene passt, um stabile Treffer zu erzeugen, und die HDD-Latenz bei aktiviertem Cache sinkt. Behalten Sie den direkten Festplattenzugriff bei, wenn die Lesezugriffe überwiegend sequenziell oder privat sind, der Pool die Latenzziele bereits erfüllt oder das Netzwerk weiterhin die sichtbare Obergrenze bildet.

Wählen Sie ein dediziertes SSD-Dataset oder -Volume, wenn die häufig genutzten Dateien sofort schnell sein müssen, häufig beschrieben werden oder zu wichtig sind, um von der Übernahme- und Verdrängungspolitik abhängig zu sein. Diese dritte Option ist besonders relevant für aktive VM-Laufwerke, Datenbanken, Containerzustände oder Projektdateien mit einer bekannten Grenze der häufig genutzten Daten.

Der Sieger sollte nur dann wechseln, wenn sich eine gemessene Bedingung ändert: gemeinsame Wiederverwendung, Speicherverfehlungen, Backend-Festplattenlatenz, Stabilität der Cache-Trefferquote oder verfügbare Netzwerkbandbreite. Wenn sich keine dieser Bedingungen ändert, ist ein SSD-Cache lediglich ein weiteres zu verwaltendes Gerät. Eine Umgebung mit mehreren Benutzern schafft nur dann eine Cache-Möglichkeit, wenn sie wiederholbare gemeinsame Lesezugriffe erzeugt.