Wie beeinflussen Warteschlangentiefe und Blockgröße die zufällige Leselatenz bei einem Heim-NAS?

Warteschlangentiefe und Blockgröße verändern die Latenz bei zufälligen Lesevorgängen, weil sie steuern, wie viel Arbeit gleichzeitig eingereicht wird und wie viele Daten jede Operation überträgt. Ein Test mit niedriger Warteschlange und kleinen Blöcken misst, wie schnell eine Anfrage abgeschlossen wird, während ein Test mit hoher Warteschlange misst, wie viel parallele Arbeit der Speicherpfad aufrechterhalten kann.

Dasselbe NAS kann daher moderate 4K QD1 IOPS, viel höhere 4K QD32 IOPS und starke Durchsatzwerte bei großen Blöcken zeigen, ohne dass dies widersprüchlich ist. Jedes Ergebnis beschreibt eine andere Arbeitslast, und die schnellste Benchmark-Zahl ist möglicherweise die am wenigsten repräsentative für eine interaktive Datenbank, Fotobibliothek oder Container-App.

Was steuern Warteschlangentiefe und Blockgröße eigentlich?

Die Warteschlangentiefe ist die Anzahl der ausstehenden I/O-Operationen auf einer gemessenen Ebene. Die Warteschlangentiefe steuert ausstehende I/O-Anfragen, während die Blockgröße die Nutzlast definiert, die jede Anfrage überträgt.

Ein Test mit QD1 sendet eine Operation und wartet auf deren Abschluss, bevor die nächste ausgeführt wird. Ein QD32-Test erlaubt viele Operationen, die parallel warten oder ausgeführt werden, wodurch Laufwerk, Controller, Array und Netzwerk mehr Möglichkeiten haben, Arbeit zu überlappen.

Diese Werte existieren auf mehreren Ebenen. Die Benchmark-Thread-Warteschlange, die Betriebssystem-Blockwarteschlange, HBA, NVMe-Einreichwarteschlange, NAS-Protokoll-Credits und einzelne Festplatten können alle unterschiedliche ausstehende Anzahlen sehen.

Warum zeigt QD1 die Speicher-Servicezeit an?

Bei einer ausstehenden Anfrage kann die nächste Operation nicht hinter paralleler Arbeit verborgen werden, sodass QD1 die Servicezeit einer einzelnen Anfrage offenlegt. Das Ergebnis umfasst die Geräte-Servicezeit sowie Protokoll-, Dateisystem-, Controller-, Netzwerk- und Client-Overhead.

QD1 ist daher nützlich für benutzerorientierte Aufgaben, die eine oder wenige abhängige Lesevorgänge ausführen: Metadaten öffnen, eine Datenbankseite laden, ein Vorschaubild lesen oder einem Zeiger zur nächsten Struktur folgen.

Es ist kein vollständiger Kapazitätstest. Eine moderne SSD oder ein gestreiftes Array kann möglicherweise viel mehr parallele Arbeit leisten, als QD1 bereitstellt, sodass das Ergebnis die maximale aggregierte IOPS unterschätzen kann, während es die Reaktionszeit einer einzelnen Anfrage genau darstellt.

Warum können höhere Warteschlangentiefen sowohl IOPS als auch Latenz erhöhen?

Mehr ausstehende Arbeit kann Speicherkanäle beschäftigt halten und die abgeschlossenen Operationen pro Sekunde erhöhen, aber höhere Warteschlangentiefe kann IOPS und Latenz gleichzeitig erhöhen. Jede Anfrage kann länger auf den Service warten.

Der Benchmark meldet mehr abgeschlossene Vorgänge insgesamt, weil das System Arbeit überlappt, nicht weil jede Anfrage schneller wurde. Sobald das Gerät oder Array seine Servicekapazität erreicht, verlängert zusätzliche Warteschlangentiefe meist nur die Warteschlange.

Deshalb sind hohe IOPS bei großer Warteschlangentiefe und niedrige interaktive Latenz getrennte Ziele. Ein Backup-Server oder Analysejob profitiert von tiefer Parallelität, während eine App-Anfrage die Abschlusszeit eines kritischen Lesevorgangs benötigt.

Wie verändert die Blockgröße IOPS, Durchsatz und Wartezeit?

IOPS zählen Operationen, ohne zu beschreiben, wie viele Bytes jede Operation bewegt. Die Blockgröße verändert das Verhältnis zwischen IOPS und Durchsatz. Tausend 4K-Lesevorgänge bewegen viel weniger Daten als tausend 128K-Lesevorgänge.

Kleine Blöcke betonen den Overhead pro Operation und sind typisch für Datenbankseiten, Metadaten und Anwendungszustände. Größere Blöcke verbessern die Übertragungseffizienz und den Durchsatz, belegen aber Gerät, Netzwerk und Controller mit mehr Bytes pro Anfrage.

Ein größerer Block kann die Anzahl der für eine bestimmte Bandbreite benötigten IOPS reduzieren, während die Servicezeit jeder Operation steigt. Gemischte Anwendungen benötigen beide Dimensionen, da ein NAS neben großen Medien- oder Backup-Übertragungen auch winzige Metadaten-Lesevorgänge bedienen kann.

Warum lassen Cache und Parallelität die Ergebnisse besser aussehen, als sich Apps anfühlen?

Benchmark-Ergebnisse können von RAM, Controller-Cache, Client-Cache oder wiederholtem Zugriff auf einen kleinen Arbeitsbereich dominiert werden. Cache und Parallelität können die Latenz bei kalten Lesevorgängen verbergen.

Parallele Benchmark-Arbeiter können Anfragen auch effektiver über Festplatten, NAND-Kanäle, CPU-Kerne, SMB-Kanäle oder NVMe-Warteschlangen verteilen als ein einzelner Anwendungsthread. Der Test beweist die aggregierte Skalierung, nicht, dass ein einzelner kalter App-Lesevorgang denselben Vorteil erhält.

Verwenden Sie einen Datensatz, der größer als die relevanten Caches ist, wenn Sie Speichermedien testen, und führen Sie separate Warm-Cache-Tests durch, wenn Anwendungs-Caching Teil des realen Designs ist. Das Mischen der beiden erzeugt eine Zahl, deren Engpass unklar ist.

Wie sollte ein Heim-NAS-Random-Read-Test reale Arbeitslasten abbilden?

Ein nützlicher Benchmark variiert die Dimensionen, die reale Anwendungen variieren. Realistische Tests müssen der Arbeitslast-Warteschlangentiefe entsprechen, anstatt nur einen maximalen IOPS-Wert zu berichten.

Testen Sie QD1 und einige moderate Tiefen, schließen Sie 4K- oder 8K-Kleinlesungen und die größeren Blöcke ein, die von Medien- oder Backup-Tools verwendet werden, und erfassen Sie Durchschnitt sowie p95, p99 und maximale Latenz. Halten Sie Client, Protokoll, Verschlüsselung und Datensatz konstant, wenn Sie Speicheränderungen vergleichen.

Führen Sie den Random-Read-Test sowohl allein als auch neben den Hintergrund-Workloads aus, die tatsächlich das NAS teilen. Ein isolierter Benchmark kann den Speicherpfad sauber messen, aber nicht die Latenz zeigen, die Nutzer während App-, Backup-, Indexierungs- oder Paritätskonflikten erleben.

FAQ

Ist eine höhere Warteschlangentiefe immer besser?

Nein. Es kann den aggregierten Durchsatz verbessern, bis der Speicherpfad gesättigt ist, aber Anfragen können länger warten und die interaktive Latenz kann sich verschlechtern.

Warum werden 4K-Random-Read-Zahlen häufig berichtet?

Kleine Blöcke ähneln Datenbankseiten, Metadaten und Anwendungszuständen und zeigen den pro-Operation-Overhead, den große sequentielle Übertragungen verbergen.

Sollte ein NAS-Benchmark QD32 verwenden?

Nur wenn die erwartete Arbeitslast so viel parallelen I/O erzeugen kann. Beziehen Sie QD1 und moderate Tiefen für interaktive Heimserver-Anwendungen ein.

Kann die Netzwerklatenz einen Random-Read-Test dominieren?

Ja. SMB- oder NFS-Rundreisen, Client-Verarbeitung, Verschlüsselung und Switch-Warteschlangen können die Gerätebedienzeit übersteigen, besonders bei niedriger Warteschlangentiefe.

Fazit

Die Warteschlangentiefe bestimmt, wie viele I/O-Vorgänge parallel warten oder ausgeführt werden können, während die Blockgröße bestimmt, wie viele Daten jede Operation bewegt. Eine höhere Warteschlangentiefe kann die Gesamt-IOPS erhöhen, während die Latenz pro Anfrage steigt, und größere Blöcke können den Durchsatz verbessern, während die Anzahl der Operationen reduziert wird. Ein nützlicher Heim-NAS-Benchmark entspricht echter Parallelität, Datengrößen, Cache-Zustand und Anforderungen an die Spitzenlatenz, anstatt nur die größte Schlagzeilenzahl auszuwählen.