„Die SSD macht 100.000 IOPS." Das steht im Datenblatt. Was nicht im Datenblatt steht: Die 100.000 IOPS gelten bei 4K Random Read, Queue Depth 32, auf einem leeren Drive. Deine Datenbank läuft mit 70% Schreiblast, Queue Depth 4, auf einem zu 80% gefüllten Drive. Herzlichen Glückwunsch, aus 100.000 sind 15.000 geworden.
Storage-Performance ist ein Thema, bei dem Datenblätter mehr lügen als Bundestagswahlplakate. Dieser Artikel erklärt, was IOPS, Throughput und Latenz wirklich bedeuten — und wie du mit dem bitcalc IOPS-Rechner realistische Werte für deine Umgebung berechnest.
Die drei Kennzahlen — und wie sie zusammenhängen
Throughput (Durchsatz): Wie viele MB/s bewegt werden. Relevant für Video, Backups, große Dateitransfers.
Latenz (Latency): Wie lange ein einzelner I/O dauert (in ms oder µs). Relevant für alles, wo Wartezeit wehtut.
Die drei hängen zusammen: Throughput = IOPS × Blockgröße. 10.000 IOPS mit 4K-Blöcken = 40 MB/s. 10.000 IOPS mit 64K-Blöcken = 640 MB/s. Gleiche IOPS, völlig anderer Durchsatz — nur weil die Blockgröße anders ist.
Und: IOPS_max ≈ 1 / Latenz. Wenn eine Festplatte 10 ms für einen I/O braucht, schafft sie theoretisch 100 IOPS. In der Praxis weniger, weil Queue-Depth-Effekte und Controller-Overhead dazukommen.
Queue Depth: Der unsichtbare Faktor
Queue Depth (QD) ist die Anzahl gleichzeitiger I/O-Anfragen, die das Storage-System parallel bearbeitet. Ein typischer Desktop-Workload hat QD 1-2. Eine stark ausgelastete Datenbank QD 8-32. Ein benchmarkendes Marketing-Team: QD 128.
Warum das wichtig ist: SSDs liefern ihre Spitzen-IOPS erst bei hoher Queue Depth. Eine NVMe-SSD, die bei QD1 15.000 IOPS schafft, erreicht bei QD32 vielleicht 500.000 — aber deine Datenbank läuft nie auf QD32, weil die Applikation die I/Os gar nicht so schnell feuert.
Praxisregel: Für Datenbank-Performance interessiert dich QD1-4. Für Fileserver oder Backup interessiert dich QD8-32. Alles über QD64 ist Benchmark-Porno und sagt nichts über deine reale Arbeitslast aus.
4K vs. 64K: Warum die Blockgröße alles ändert
Datenbanken arbeiten typischerweise mit 8K-Blöcken (PostgreSQL, MySQL/InnoDB). Virtualisierung mit 4K-64K. Video-Schnitt mit 1M-Blöcken oder größer.
Ein Praxisbeispiel mit dem IOPS-Rechner: Du hast ein RAID 10 aus sechs SATA-SSDs mit je 90.000 4K-Random-Read-IOPS. Das Array liefert ~540.000 Lese-IOPS. Bei 4K-Blöcken sind das etwa 2,1 GB/s. Bei 64K-Blöcken wären es theoretisch 34 GB/s — aber da limitiert der SAS-Controller schon vorher auf 12 GB/s.
Die Blockgröße bestimmt, ob du IOPS-bound oder throughput-bound bist. Kleine Blöcke = IOPS-bound (Datenbank). Große Blöcke = throughput-bound (Backup).
Das Storage-Medium-Dreieck: HDD vs. SATA SSD vs. NVMe
| Medium | IOPS (4K QD1) | Latenz | Throughput | Preis/TB |
|---|---|---|---|---|
| 7.200 rpm HDD | ~80 | ~12 ms | ~200 MB/s | 15 € |
| SATA SSD | ~8.000 | ~120 µs | ~550 MB/s | 50 € |
| NVMe SSD | ~15.000 | ~70 µs | ~3.500 MB/s | 70 € |
Der Sprung von HDD zu SSD ist der größte Performance-Gewinn, den du im Storage für Geld kaufen kannst. 100× IOPS, 100× geringere Latenz. Der Sprung von SATA zu NVMe ist kleiner, aber für latenzkritische Workloads (Datenbanken, Caching) trotzdem spürbar. Für Fileserver: SATA-SSD reicht.
Der RAID Write Penalty — IOPS-Killer Nr. 1
RAID 5 und 6 haben einen Pferdefuß, den Datenblätter gerne verschweigen: den Write Penalty. Jeder logische Schreibzugriff erfordert mehrere physische I/Os:
- RAID 0: 1× (kein Penalty, aber auch keine Redundanz)
- RAID 1/10: 2× (Schreiben auf beide Spiegel)
- RAID 5: 4× (Read-Modify-Write: alte Daten + alte Parität lesen, neue Parität berechnen, neue Daten + neue Parität schreiben)
- RAID 6: 6× (gleicher Zyklus, aber mit zwei Paritätsblöcken)
Der IOPS-Rechner zeigt dir den Write Penalty live: 900 Lese-IOPS im RAID 5 werden zu 225 Schreib-IOPS. Im RAID 10 sind es 450 Schreib-IOPS. Deshalb ist RAID 10 für schreibintensive Workloads der Standard — doppelte Schreib-IOPS bei gleicher nutzbarer Kapazität. Das RAID-Theme haben wir im RAID-Artikel ausführlich behandelt.
Praxistipps für die Performance-Planung
- Finde deine reale Queue Depth.
iostat -x 1auf Linux,Get-StorageReliabilityCounterauf Windows. Die Avg. Queue Depth deines Produktivsystems ist die Zahl, mit der du rechnen musst — nicht QD32 aus dem Datenblatt. - Rechne in IOPS, nicht in MB/s, wenn deine Workload kleine Blöcke hat. 500 MB/s klingt nach viel, aber bei 4K-Blöcken und 70% Schreiblast im RAID 5 sind das ~30.000 IOPS — und die liefert eine einzelne Enterprise-SSD nicht.
- Plane Puffer ein. Wenn deine Workload 5.000 IOPS braucht, dimensioniere das Storage für mindestens 8.000. Spitzenlasten, Wartungsarbeiten und der Fakt, dass SSDs langsamer werden je voller sie sind, fressen den Rest.