# I/O Benchmarking Mastery: Fakten statt Gefühle

TL;DR / Management Summary Ein Senior Admin verlässt sich bei Storage-Problemen nicht auf subjektive Eindrücke. Er nutzt fio (Flexible I/O Tester), um die Hardware an ihre Grenzen zu bringen. Wir lernen, wie wir realistische Last-Szenarien (Random Read/Write) simulieren, den Unterschied zwischen IOPS (Transaktionen) und Durchsatz (MB/s) bewerten und wie wir die Latenz im 99. Perzentil messen. Das Ziel: Die Performance des Storage-Backends objektiv zu validieren, bevor die Applikation live geht.

# 1. Einführung & Architektur

Metriken der Performance.

1. Durchsatz (Throughput): Wie viele Megabytes pro Sekunde (MB/s) können übertragen werden? (Wichtig für Backups/Streaming).
2. IOPS (Input/Output Operations per Second): Wie viele kleine Operationen pro Sekunde sind möglich? (Wichtig für Datenbanken).
3. Latenz (Latency): Wie lange dauert ein einzelner Zugriff? (Wichtig für die Reaktivität).

# Der Benchmark-Flow (Mermaid)

graph TD
    A[Benchmark Design: Random vs Sequential] --> B[Tool: fio]
    B --> C[Warm-up Phase]
    B --> D[Execution Phase]
    D --> E{Result Analysis}
    E --> F[Average Latency]
    E --> G[99th Percentile: Tail Latency]
    E --> H[Bandwidth: MiB/s]
    F/G/H --> I[Optimization: Tuning BIOS / Kernel / FS]

# 2. fio: Der Goldstandard

Professionelle Simulation.

Vergessen Sie dd für Benchmarks (es misst meist nur den Cache). Nutzen Sie fio.

# Beispiel: Random Read (Datenbank-Szenario)

sudo fio --name=randread --ioengine=libaio --direct=1 --bs=4k \
         --iodepth=64 --size=1G --readwrite=randread --runtime=60 \
         --filename=/dev/sdX --group_reporting

• --direct=1: Umgeht den Page Cache (Artikel 385).
• --bs=4k: Blockgröße (4K ist Standard für DB-Blöcke).
• --iodepth=64: Parallelität (Async I/O).

# 3. Latenzmessung mit ioping

Der Ping für die Disk.

Für einen schnellen Check der Antwortzeit:

sudo ioping -c 10 /mnt/data
# Zeigt Latenz in Mikrosekunden (us).

# 4. Day-2 Operations: Tail Latency

Die Ausreißer finden.

Ein System fühlt sich langsam an, wenn einzelne I/O-Vorgänge sehr lange dauern, auch wenn der Durchschnitt okay ist.

• Schauen Sie in den fio Ergebnissen auf die Percentile Latencies (99.00th, 99.99th).
• Wenn das 99. Perzentil bei > 100ms liegt, haben Sie sporadische Hänger, die User merken werden.

# 5. Troubleshooting & “War Stories”

Wenn die Zahlen lügen.

# Story 1: “Der Cache-Trugschluss”

Symptom: Ein Admin testet seine neue HDD mit dd if=/dev/zero of=testfile bs=1G count=1 und meldet begeistert 10GB/s Schreibgeschwindigkeit. Ursache: Er hat nur die Schreibgeschwindigkeit in den RAM (Page Cache) gemessen. Die Daten sind noch gar nicht auf der Platte. Lösung: Nutzen Sie immer fio mit --direct=1 oder erzwingen Sie einen Flush am Ende mit fdatasync=1.

# Story 2: “Das volle NVMe-Write-Loch”

Symptom: Eine fabrikneue NVMe liefert im Benchmark 5GB/s, aber nach 10 Minuten sinkt die Rate auf 600MB/s. Ursache: Der SLC-Cache der SSD ist voll. Der Controller muss nun direkt in die langsamen TLC/QLC-Zellen schreiben. Lösung: Führen Sie Benchmarks über längere Zeiträume (z.B. 1 Stunde) aus, um die echte Dauerleistung der Hardware zu ermitteln.

# 6. Fazit & Empfehlung

• Pflicht: Führen Sie Benchmarks auf dem rohen Block-Device aus, bevor Sie ein Dateisystem erstellen, um Hardware-Fehler auszuschließen.
• Wahl: Nutzen Sie 4K Blöcke für IOPS-Tests und 1MB Blöcke für Durchsatz-Tests.
• Wartung: Dokumentieren Sie die Benchmark-Ergebnisse bei der Inbetriebnahme eines Servers. Sie dienen als Referenz bei späteren Performance-Problemen.

# Anhang: Cheatsheet