NVMe-Leistung prüfen: kontrollierte fio-Tests mit Dateien

Wenn ein neuer Server Datenbanken oder Dateidienste übernehmen soll, reicht die Geschwindigkeit beim Kopieren einer großen Datei nicht aus, um die Speicherleistung abzunehmen. Die Datei kann aus dem Cache gelesen werden, Schreibvorgänge sind möglicherweise noch nicht dauerhaft gespeichert, und Hintergrundaufgaben können das Ergebnis beeinflussen. Aussagekräftiger ist es, Testdatei, Blockgröße und Parallelität festzulegen, Durchsatz und Latenz getrennt zu betrachten und die Rohdaten für reproduzierbare Wiederholungsmessungen aufzubewahren.

Die Dedicated Server von CloudUDP sind standardmäßig mit zwei direkt angebundenen NVMe-Laufwerken mit jeweils 1TB ausgestattet, ohne Hardware-RAID. Die folgende Anleitung verwendet Debian 13 und fio, ein konfigurierbares Werkzeug für I/O-Lasttests, um ein bestimmtes Dateisystem zu prüfen. Es wird nicht direkt auf rohe Blockgeräte geschrieben; die Ergebnisse sind auch keine Zusage zur Leistung im produktiven Betrieb.

1. Testumfang und tatsächlichen Speicherort prüfen

Ein dateibasierter Test erfasst den Pfad vom Dateisystem zum Speicher und misst nicht isoliert die Leistungsgrenze des Laufwerks. Verschlüsselung, Volume-Verwaltung, Spiegelung und Mount-Optionen können das Ergebnis beeinflussen. Dass beide Laufwerke direkt angebunden sind, bedeutet außerdem nicht, dass ein bestimmtes Verzeichnis beide nutzt.

Installieren Sie zunächst das Werkzeug und prüfen Sie das Zielverzeichnis. Im folgenden Beispiel dient /srv als noch zu überprüfender Testpfad. Liegt dieses Verzeichnis nicht auf dem gewünschten Dateisystem, verwenden Sie stattdessen dessen tatsächliches Mount-Verzeichnis.

sudo apt-get install fio
findmnt -T /srv -o TARGET,SOURCE,FSTYPE,OPTIONS
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
df -h /srv
df -i /srv
fio --version

Prüfen Sie den verfügbaren Speicherplatz, den Mount-Status und die Verzeichnisberechtigungen. Verlassen Sie sich nicht allein auf die Nennkapazität der Laufwerke: Dateisystem-Metadaten und vorhandene Daten belegen ebenfalls Platz. Auch nach dem vollständigen Schreiben der Testdatei muss genügend Reserve für das Wachstum der produktiven Daten bleiben.

Übergeben Sie einem Schreibtest keine Gerätepfade wie /dev/nvme…. Eine separate Datei verringert das Risiko versehentlichen Überschreibens, verhindert aber keine Ressourcenkonkurrenz. Führen Sie die Tests vorzugsweise vor der Inbetriebnahme aus. Brechen Sie sofort ab, wenn ungewöhnliche Latenzen im produktiven Betrieb auftreten, der freie Speicherplatz die festgelegte Reservegrenze erreicht oder I/O-Fehler auftreten.

2. Separates Verzeichnis anlegen und vollständige Testdatei vorbereiten

Führen Sie alle Befehle in derselben Bash-Sitzung aus. Mit Administratorrechten wird ein temporäres Verzeichnis angelegt, das ausschließlich dem aktuell verwendeten Benutzerkonto gehört. Testdatei und Ergebnisse werden dort abgelegt, damit vorhandene produktive Dateien unberührt bleiben.

TESTDIR=$(sudo mktemp -d /srv/fio-acceptance.XXXXXX)
sudo chown "$(id -u):$(id -g)" "$TESTDIR"
chmod 700 "$TESTDIR"
export TESTDIR
printf '%s\n' "$TESTDIR"
findmnt -T "$TESTDIR"

Das Beispiel verwendet eine Datei von 1GiB als Ausgangspunkt zur Überprüfung des Ablaufs. Sie steht weder für die gesamte Speicherkapazität noch für das langfristige Verhalten im eingeschwungenen Zustand. fio interpretiert size=1G in binären Einheiten; dieser Wert darf daher nicht ohne Umrechnung mit der Nennkapazität des Geräts verrechnet werden. Wenn ausreichend Platz vorhanden ist, schreiben Sie die Datei zunächst vollständig sequenziell:

fio --name=prepare \
  --filename="$TESTDIR/test.bin" \
  --size=1G --rw=write --bs=1M \
  --ioengine=libaio --direct=1 \
  --iodepth=1 --numjobs=1 --end_fsync=1 \
  --group_reporting --output-format=json \
  --output="$TESTDIR/prepare.json"

Prüfen Sie unbedingt den Exit-Status und die Fehlerfelder in der JSON-Ausgabe. Falls direktes I/O nicht unterstützt wird, kontrollieren Sie zunächst das Dateisystem und die Mount-Konfiguration. Stellen Sie nicht stillschweigend auf gepuffertes I/O um, um anschließend die Ergebnisse weiter zu vergleichen. Treten bei der Vorbereitung Fehler auf, fehlt den nachfolgenden Lesetests eine verlässliche Grundlage.

direct=1 umgeht normalerweise den Seitencache für Dateidaten, aber nicht sämtliche Geräte-Caches. end_fsync=1 fordert am Ende des Jobs eine Synchronisierung an. Das bedeutet nicht, dass jeder Schreibvorgang einen Datenbank-Commit simuliert.

3. Mit festen Parametern zufälliges Lesen und Schreiben getrennt testen

Führen Sie zuerst einen Test mit einem einzelnen Job für zufällige Lesezugriffe aus, danach einen für zufällige Schreibzugriffe. So verdeckt eine gemischte Last keine Probleme. Kopieren Sie während der Tests keine Daten und führen Sie keine weiteren Speichertests parallel aus.

fio --name=randread \
  --filename="$TESTDIR/test.bin" \
  --size=1G --rw=randread --bs=4k \
  --ioengine=libaio --direct=1 \
  --iodepth=8 --numjobs=1 \
  --time_based --runtime=30 --ramp_time=5 \
  --group_reporting --output-format=json \
  --output="$TESTDIR/randread-q8.json"

fio --name=randwrite \
  --filename="$TESTDIR/test.bin" \
  --size=1G --rw=randwrite --bs=4k \
  --ioengine=libaio --direct=1 \
  --iodepth=8 --numjobs=1 \
  --time_based --runtime=30 --ramp_time=5 \
  --end_fsync=1 --group_reporting \
  --output-format=json \
  --output="$TESTDIR/randwrite-q8.json"

Laufzeit und Aufwärmphase sind hier lediglich Testparameter. Kurze Tests können durch Geräte-Caches, Temperatur und interne Hintergrundbereinigung beeinflusst werden. Daraus lässt sich keine anhaltende Schreibleistung ableiten.

Vergleichstest mit niedriger Warteschlangentiefe ergänzen

Ändern Sie beim Lesetest iodepth auf 1 und den Namen der Ausgabedatei auf randread-q1.json. Alle übrigen Parameter bleiben unverändert. Die Warteschlangentiefe gibt an, wie viele noch nicht abgeschlossene I/O-Anfragen gleichzeitig zulässig sind. Sie entspricht weder der Anzahl der CPU-Kerne noch der Anzahl gleichzeitiger Verbindungen einer Anwendung.

Steigt bei höherer Warteschlangentiefe der Durchsatz, während sich die Latenzen am oberen Ende der Verteilung deutlich verschlechtern, zeigt dies lediglich einen Zielkonflikt zwischen Durchsatz und Wartezeit unter dieser Last. Übertragen Sie diese Einstellung nicht unmittelbar auf den Verbindungspool einer Datenbank.

4. Durchsatz, IOPS und hohe Latenzperzentile gemeinsam bewerten

IOPS bezeichnet die Anzahl abgeschlossener I/O-Vorgänge pro Sekunde. Bei fester Blockgröße besteht ein direkter Zusammenhang mit dem Durchsatz. Ergebnisse mit unterschiedlichen Blockgrößen lassen sich daher nicht allein anhand der IOPS einordnen. In der JSON-Ausgabe von fio wird bw üblicherweise in KiB/s angegeben. Prüfen Sie beim Auswerten die Version und die Einheiten der Felder.

Achten Sie insbesondere auf iops, die Bandbreitenfelder sowie den Mittelwert und die Perzentile von clat_ns innerhalb von read oder write. Die Abschlusslatenz entspricht nicht vollständig der Antwortzeit einer Anwendung: Warteschlangen und Verarbeitung auf Anwendungsebene liegen außerhalb dieses Messpfads.

P99 bedeutet, dass die Latenz von ungefähr 99 Prozent der Anfragen diesen Wert nicht überschreitet. Es ist nicht die maximale Latenz. Bleibt der Mittelwert ähnlich, während P99 steigt, können einzelne Anfragen längere Wartezeiten aufweisen. Bewerten lässt sich das nur zusammen mit der tatsächlichen Warteschlangentiefe und wiederholten Messungen.

Das Abnahmeprotokoll sollte mindestens Folgendes enthalten:

• fio-Version, vollständige Befehle, Dateigröße und Mount-Informationen des Ziels.
• Art der Lese- und Schreibzugriffe, Blockgröße, Anzahl der Jobs und Warteschlangentiefe der Anfragen.
• Durchsatz, IOPS, mittlere Abschlusslatenz und P99.
• Fehlerfelder, produktive Last während des Tests und beobachtete Auffälligkeiten.

Prüfen Sie außerdem die von fio ausgewiesene Verteilung der tatsächlichen I/O-Tiefe. Eine Einstellung von 8 bedeutet nicht, dass diese Tiefe während des gesamten Tests erreicht wird. Bei unterschiedlichem Verhalten der I/O-Engine oder des Dateisystems sind Ergebnisse auch mit nominell gleichen Parametern nicht unbedingt vergleichbar.

5. Abnahme durch Wiederholungen, Archivierung und Bereinigung abschließen

Wiederholen Sie jede Last mit einem anderen Namen für die Ausgabedatei, ohne vorherige Ergebnisse zu überschreiben. Vergleichen Sie die Schwankungsbreite, statt den höchsten Wert herauszugreifen. Bevor Sie die Testdatei vergrößern oder die Laufzeit verlängern, prüfen Sie erneut den verfügbaren Platz und klären Sie das zusätzliche Schreibvolumen sowie die Ressourcenkonkurrenz.

Sollen die beiden Laufwerke getrennt abgenommen werden, wählen Sie jeweils ein Verzeichnis auf dem zugehörigen Dateisystem und testen Sie beide nacheinander mit denselben Parametern. Liegen die Verzeichnisse tatsächlich auf demselben Volume, ist ein Verzeichniswechsel keine unabhängige Abnahme des zweiten Laufwerks.

Treten bei den Lese- oder Schreibtests Fehler auf, sichern Sie zunächst die Rohdaten und die relevanten Kernel-Protokolle. Untersuchen Sie anschließend das Dateisystem und den Pfad zum Gerät. Schwanken die Ergebnisse stark, ohne dass Fehler auftreten, schließen Sie zunächst andere Aufgaben auf demselben Server und veränderte Testbedingungen als Ursachen aus. Gehen Sie nicht sofort von einem Hardwareproblem aus.

Kopieren Sie nach Abschluss die JSON-Dateien, die Mount-Informationen und die aufgezeichneten Befehle an einen kontrollierten Archivierungsort. Prüfen Sie, ob das Archiv lesbar ist. Kontrollieren Sie danach das Testverzeichnis und löschen Sie ausschließlich die in diesem Durchlauf erzeugten Dateien:

printf '%s\n' "$TESTDIR"
ls -lh -- "$TESTDIR"
rm -- "$TESTDIR/test.bin"

Löschen Sie die übrigen Ergebnisdateien einzeln, sobald ihre Archivierung bestätigt ist. Entfernen Sie das leere Verzeichnis anschließend mit rmdir; verwenden Sie kein rekursives Löschen für Geräte-Mount-Punkte. Die abschließende Aussage sollte lauten: „Unter diesen Parametern und Lastbedingungen wurden diese Ergebnisse erzielt“, nicht: „Dieses Laufwerk erreicht immer eine bestimmte Geschwindigkeit“. Die dateibasierte Basismessung dient dazu, deutliche Abweichungen zu erkennen. Vor der Inbetriebnahme einer Anwendung ist weiterhin eine Abnahme mit deren tatsächlichen Lese- und Schreibmustern erforderlich.

Häufig gestellte Fragen