Dateisystem und Cache haben großen Einfluss. Ein Mount-Option oder ein Schreibcache kann Messergebnisse stark verändern. Auch das Betriebssystem-Cache und bestimmte Dateisystem-Funktionen wie journaling oder fsync bestimmen, wie realistisch ein Test ist. Synthetische Benchmarks liefern häufig hohe Zahlen. Sie spiegeln oft nicht die reale Last wider. Realistische Workloads enthalten viele kleine 4K-Operationen, Metadatenaufrufe und fsyncs.
In diesem Artikel lernst du, wie du sinnvolle Tests aufbaust. Du bekommst konkrete Messgrößen wie IOPS, Latenzverteilungen und Durchsatz. Du lernst Tools und Testparameter kennen. Du erfährst, wie du synthetische von realen Workloads unterscheidest und wie du Cache, Dateisystem und Queue-Depth richtig berücksichtigst. Am Ende kannst du Messergebnisse bewerten und gezielt optimieren.
Vergleich von Testmethoden und Tools
Bevor du Messungen startest, kläre die wichtigsten Kennzahlen. IOPS sind die Anzahl der Ein- und Ausgangsoperationen pro Sekunde. Latenz ist die Zeit für eine einzelne Operation. Durchsatz misst MB/s bei sequentiellen Transfers. Blockgröße bestimmt, wie viele Bytes pro I/O bewegt werden. Queue Depth beschreibt, wie viele I/O-Anfragen gleichzeitig in der Warteschlange liegen. Metadaten-Overhead umfasst z. B. Verzeichniseinträge, Attributzugriffe und fsync.
Wichtig: synthetische Benchmarks liefern reproduzierbare Zahlen. Realistische Workloads sehen aber oft anders aus. Viele kleine 4K-Operationen, fsync-Aufrufe und Metadatenzugriffe sind typische Belastungen. In der Tabelle findest du Werkzeuge und Szenarien. Zu jedem Tool siehst du Zweck, typische Kommandozeile, Stärken, Schwächen und was du messen kannst. Nutze die Beispiele als Vorlage. Passe Blockgröße, Laufzeit, Anzahl Jobs und Queue-Depth an deine Zielumgebung an.
| Tool / Szenario | Zweck | Typische Kommandozeile / Parameter | Stärken | Schwächen | Typische Messgrößen |
|---|---|---|---|---|---|
|
fio |
Feinkörnige IOPS- und Latenztests. Simuliert viele Workloads. | fio –name=job –rw=randrw –bs=4k –iodepth=16 –numjobs=4 –size=1G –runtime=60 –direct=1 | Sehr flexibel. Messung von IOPS, Latenzverteilung, BW. Queue-Depth steuerbar. | Einarbeitung nötig. Viele Parameter können Ergebnisse verfälschen. | IOPS, P99/P99.9 Latenz, MB/s, Latency histogram |
|
iozone |
Sequentielle und zufällige Lese-/Schreibtests. Historisch verbreitet. | iozone -i 0 -i 1 -r 4k -s 1G -t 4 -F file1 file2 file3 file4 | Gute Übersicht über verschiedene Operationen. Einfacher Batch-Betrieb. | Weniger flexibel als fio bei Queue-Depth. Ausgabe teilweise komplex. | Durchsatz für read/write/rewrite, Zufallszugriffe, CPU-Overhead |
|
bonnie++ |
Gesamtperformance bei Dateioperationen und Metadatentests. | bonnie++ -r 1024 -s 2G -n 10000 -u $(id -u) | Gute Metadaten-Tests. Einfacher Report für viele Dateisystemszenarien. | Altes Tool. Nicht so feinkörnig wie fio. Interpretation erfordert Erfahrung. | Create/Read/Rewrite, File metadata ops/sec, Latency |
|
rsync / cp + fsync |
Realer Kopier- und Synchronisations-Workload mit vielen kleinen Dateien. | rsync -a –info=progress2 src/ dst/ cp -r src dst; sync; time ls >/dev/null |
Simuliert echtes Verhalten. Testet Metadaten und Open/close/fsync. | Schlecht reproduzierbar. OS-Cache beeinflusst stark. Geringe Messgranularität. | Kopierdauer, Operationen/s (abschätzen), Gesamtdurchsatz |
|
dd |
Schnelle Durchsatz-Messung für sequentielle Writes/Reads. | dd if=/dev/zero of=testfile bs=4k count=250000 oflag=direct | Einfach. Gut für rohe MB/s-Messung und write-buffering-Checks. | Misst kaum IOPS oder Metadaten. Nicht geeignet für viele kleine Dateien. | MB/s, einfache Latenzindikatoren |
|
filebench |
Komplexe, realistische Workloads (z. B. webserver, mailserver). | filebench -f workload.f | Workloads für Applikationen. Simuliert Datei- und Metadatenlast realistisch. | Erstellt werden muss ein Workload-File. Einarbeitung notwendig. | IOPS, Durchsatz, Latenz, Operationen nach Typ |
Zusammenfassung. Wähle fio für detailreiche IOPS- und Latenzanalyse. Nutze iozone oder bonnie++ für breite Dateisystem-Vergleiche. Verwende rsync/cp für echte Kopierfälle mit Metadaten. dd ist nur für Rohdurchsatz geeignet. filebench hilft bei applikationsnahen Szenarien. Kombiniere synthetische und reale Tests. So erhältst du ein umfassendes Bild.
Praktische Schritt-für-Schritt-Anleitung für einen realistischen IOPS-Test
- Vorbereitung und Backup
Sichere alle wichtigen Daten. Tests können Dateien überschreiben oder das Dateisystem stark beanspruchen. Verwende nach Möglichkeit eine Ersatz-Speicherkarte oder ein Testlaufwerk. Notiere Gerätemodelle und Firmware-Versionen. - Partitionierung und Mount-Optionen
Formatiere die Karte gezielt für den Test. Ein Beispiel: ext4 mit noatime reduziert unnötige Metadatenzugriffe. Beispielbefehle:
mkfs.ext4 /dev/sdX1
mount -o noatime,nodiratime /dev/sdX1 /mnt/test
Teste auch ein Mount ohne Journaling, wenn du die Auswirkungen von Journaling messen willst. Achte darauf, dass bestimmte Optionen das Verhalten verändern. Dokumentiere die gewählten Optionen. - Testdateien und Workload erzeugen
Lege eine große Anzahl kleiner Dateien an, um Metadatenlast zu erzeugen. Ein schneller Weg:
mkdir -p /mnt/test/smallfiles
for i in $(seq 1 50000); do truncate -s 4k /mnt/test/smallfiles/file_$i; done
Alternativ nutze echte Inhalte mithead -coder ein kleines Python-Script. Prüfe die Verzeichnisstruktur, weil viele Dateien in einem Verzeichnis andere Ergebnisse liefern als viele Verzeichnisse mit je wenigen Dateien. - System-Cache kontrollieren
Führe vor einem Messlauf ein warm-up aus, wenn du Cache-Effekte testen willst. Um den Page-Cache zu leeren, verwende als root:
sync; echo 3 > /proc/sys/vm/drop_caches
Für Block-Device-Flush:
blockdev --flushbufs /dev/sdX
Bei NVMe-Geräten nutzenvme flush /dev/nvme0n1. Nutze in fio--direct=1, um OS-Cache zu umgehen. - fio-Konfiguration für viele kleine Dateien
Ein praxisnahes Beispiel für zufällige 4k-Operationen mit mehreren Jobs:
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=1G --time_based --runtime=60 --direct=1 --filename=/mnt/test/testfile --group_reporting --output-format=json --output=run1.json
Wenn du echtes Datei-Create/Unlink testen willst, verwende fio mit--rw=randwrite --bs=4k --directory=/mnt/test/smallfilesoder setze ein kleines Script ein, das nach jedem Write ein fsync aufruft. - Metadatenintensive Tests
Für fsync-empfindliche Workloads kannst du rsync verwenden:
rsync -a --info=progress2 --fsync src/ /mnt/test/dst/
Oder schreibe ein kurzes Programm, das Datei-Create, write und fsync kombiniert. So siehst du reale Anwendungsfälle, die viele fsyncs auslösen. - Wiederholungen und Reihenfolge
Führe jeden Test mindestens 3 bis 5 Mal durch. Starte zuerst einen Warm-up-Lauf. Variiere Reihenfolge und notiere Umgebungsbedingungen. Berechne Median und Perzentile, nicht nur den besten Lauf. - Messgrößen sammeln
Erfasse IOPS, mediane Latenz, P95 und P99 Latenzen, throughput in MB/s und die Standardabweichung. Nutze fio-JSON-Ausgabe für automatisierte Auswertung. Ergänze Systemmetriken mitiostat -x 1,vmstat 1oderiostat -xm 1. - Ergebnisse interpretieren
Vergleiche IOPS bei verschiedenen Queue-Depths. Wenn IOPS mit Queue-Depth steigen, nutzt das Gerät interne Parallelität. Hohe P99-Latenzen bei moderaten IOPS deuten auf Garbage Collection oder Schreibpeaks hin. Große Schwankungen zwischen Läufen zeigen mangelnde Stabilität oder aktive Hintergrundprozesse. - Sicherheit, Wear-Leveling und Lebensdauer
Intensive Tests belasten Flash-Speicher. Führe Langzeittests nur auf Testgeräten durch. Achte auf Schreibvolumen. Dokumentiere Anzahl und Größe der Writes. Beachte Herstellerangaben zur Lebensdauer. - Tipps und Warnungen
Teste zuerst auf Rohgerät, dann auf Dateisystem. Rohtests zeigen reine Gerätelimits. Dateisystemtests zeigen Metadaten-Overhead. Verändere nur einen Parameter pro Testreihe. Halte Firmware- und Kernel-Varianten konstant. Notiere Uhrzeit und Temperatur, da thermisches Throttling die Ergebnisse beeinflussen.
Häufige Fragen
Was genau misst IOPS?
IOPS steht für Input/Output Operations Per Second. Es zählt, wie viele einzelne Lese- oder Schreiboperationen ein Gerät pro Sekunde abwickelt. IOPS sagen nichts über die Größe der Operationen aus. Ergänze immer Latenz-Perzentile, um das Nutzererlebnis zu bewerten.
Welche Block- oder Dateigrößen sind sinnvoll für Tests?
Für viele kleine Dateien sind 4K und 8K typische Blockgrößen. Sie spiegeln typische Metadaten- und Random-IO-Lasten in Betriebssystemen wider. Ergänze Tests mit größeren Größen wie 64K, um Übergänge zu sequentiellem Durchsatz zu sehen. Passe die Größe an die reale Anwendung an.
Wie beeinflusst das Dateisystem die Messergebnisse?
Dateisysteme verändern Ergebnis durch Journaling, Allocation-Strategien und Metadatenzugriffe. Optionen wie noatime oder das Deaktivieren des Journals ändern die Last stark. Teste sowohl Rohgerät als auch gemountetes Dateisystem. So trennst du Gerätegrenzen von Dateisystem-Overhead.
Wie kann ich Caching sicher eliminieren?
Nutze --direct=1 in fio, um den Page-Cache zu umgehen. Leere den Cache mit sync; echo 3 > /proc/sys/vm/drop_caches vor einem Lauf. Bei Block-Devices führe blockdev --flushbufs /dev/sdX oder Herstellerbefehle wie nvme flush aus. Dokumentiere immer, ob ein Test warm oder cold Cache war.
Wie interpretiere ich plötzliche Latenzspitzen?
Latenzspitzen weisen oft auf Hintergrundaufgaben wie Garbage Collection oder Internal Wear Management hin. Prüfe Gerätetemperatur, Firmware-Logs und laufende Systemprozesse. Analyse mit P95, P99 und Latency-Histogrammen hilft, wiederkehrende Muster zu erkennen. Bei Bedarf variiere Queue-Depth und Laufzeit, um Ursache einzugrenzen.
Technische Grundlagen: Warum viele kleine Dateien anders wirken
Was ist IOPS?
IOPS steht für Input/Output Operations Per Second. Es misst, wie viele einzelne Lese- oder Schreiboperationen ein Speichergerät pro Sekunde abwickelt. IOPS sagt nichts über die Größe der Operationen aus. Eine hohe IOPS-Zahl bei kleinen Blöcken bedeutet viele kleine Zugriffe. Das Nutzererlebnis hängt aber oft mehr von Latenzverteilungen als von einem einzelnen Durchschnittswert ab.
Wartezeiten vs. Durchsatz
Latenz ist die Zeit für eine einzelne Operation. Durchsatz ist die Menge an Daten pro Sekunde in MB/s. Große sequentielle Writes oder Reads erreichen hohen Durchsatz. Viele kleine, zufällige 4K-Operationen sind IOPS-gebunden. Das heißt, die Anzahl der Operationen pro Sekunde limitiert die Performance. Ein Gerät kann hohen Durchsatz liefern. Es kann trotzdem wenige IOPS für kleine Random-IOs schaffen. Praktische Folge: Sequentielle Tests mit dd zeigen oft bessere Zahlen als realistische 4K-Workloads.
Rolle des Dateisystems und Caches
Das Dateisystem bringt Metadatenoperationen mit sich. Erstellen, Löschen und Umbenennen kleiner Dateien erzeugt Directory-Updates und Journaleinträge. Diese Operationen sind oft synchron und führen zu fsync-Aufrufen. Der Page-Cache im Betriebssystem kann Latenzen kaschieren. Direct-I/O umgeht den Cache. Mount-Optionen wie noatime reduzieren zusätzliche Writes. Für Tests musst du entscheiden, ob du Rohgerätverhalten oder reales Dateisystemverhalten messen willst.
Flash-spezifische Aspekte wie Wear-Leveling und GC
Flash speichert Daten in Seiten und löscht in größeren Blöcken. Löschen ist langsam. Um freie Seiten bereitzustellen, führt das Gerät intern Garbage Collection aus. Wear-Leveling verteilt Schreibvorgänge über die Zellen. Beide Prozesse erzeugen Hintergrundaktivität. Das kann zu plötzlichen Latenzspitzen führen. Schreibvervielfachung oder Write Amplification reduziert die effektive Lebensdauer. TRIM oder Discard helfen beim Reuse von Speicherzellen. Viele kleine Writes erhöhen die Belastung stärker als große sequentielle Writes.
Praktische Folgen für Tests auf Speicherkarten und SSDs
Teste sowohl Cold-Cache als auch Warm-Cache-Szenarien. Nutze kleinere Blockgrößen wie 4K für realistische kleine Datei-Workloads. Variiere die Queue-Depth um zu sehen, ob das Gerät interne Parallelität nutzt. Messe Perzentile wie P95 und P99. Beobachte Temperatur und SMART- oder NVMe-Health-Daten. Langzeittests und Wiederholungen zeigen Stabilität und Effekte von Garbage Collection. So erhältst du ein belastbares Bild der echten Performance.
Do’s & Don’ts beim Testen von IOPS mit vielen kleinen Dateien
Diese Tabelle gibt dir klare, praktische Regeln für aussagekräftige Tests. Sie hilft, typische Fehler zu vermeiden. Folge den Do’s und meide die Don’ts, um realistische und vergleichbare Ergebnisse zu erhalten.
| Do | Don’t |
|---|---|
|
Nutze realistische Dateigrößen und Mehrfachläufe Beispiel: 4K-Dateien, 3–5 Läufe, Median auswerten. So bekommst du robuste Werte. |
Nur Peak-sequentiellen Durchsatz messen Beispiel: eine einzelne dd-Messung. Das zeigt nicht das Verhalten bei vielen kleinen Dateien. |
|
Teste mit und ohne OS-Cache Beispiel: fio mit --direct=1 und ohne. Du siehst Cold- und Warm-Cache-Szenarien. |
Den Cachezustand ignorieren Beispiel: Ergebnisse ohne Angabe, ob Cache geleert war. Das macht Vergleiche ungültig. |
|
Dokumentiere Mount-Optionen, Firmware und Umgebung Beispiel: noatime, Kernel-Version, Temperatur. So kannst du Ursachen nachverfolgen. |
Ungleiche Systeme direkt vergleichen Beispiel: unterschiedliche Mount-Optionen oder veraltete Firmware nicht notieren. Das verfälscht Aussagen. |
|
Variiere Queue-Depth und Anzahl Jobs Beispiel: iodepth=1,16,32, numjobs=1,4. So testest du interne Parallelität. |
Nur mit Standard- oder qd=1 testen Beispiel: nur ein einziger Lauf mit Default-Einstellungen. Das verpasst Performance-Potenzial oder Engpässe. |
|
Kombiniere synthetische und reale Workloads Beispiel: fio für IOPS und rsync/filebench für Real-World. So erkennst du Unterschiede zwischen Mess- und Praxiswerten. |
Auf ein Benchmark-Tool allein vertrauen Beispiel: nur dd oder nur ein synthetischer Test. Das liefert kein vollständiges Bild. |
|
Beachte Wear und Geräteschutz Beispiel: intensive Tests nur auf Testgeräten, Schreibvolumen monitoren. So schonst du Lebensdauer und vermeidest Datenverlust. |
Endurance-Tests auf Produktionskarten laufen lassen Beispiel: unbeaufsichtigte Dauerläufe ohne Monitoring. Das kann Flash beschädigen oder Daten zerstören. |
Häufige Fehler beim IOPS-Test mit vielen kleinen Dateien und wie du sie vermeidest
Vernachlässigung von Cache-Effekten
Viele Tester sehen hohe Werte, weil das Betriebssystem Daten aus dem Page-Cache bedient. Das ergibt ein falsches Bild für echte Cold-IOPS. Vermeide das, indem du Tests sowohl mit als auch ohne Cache fährst. Nutze in fio --direct=1 oder leere den Cache vor einem Lauf mit sync; echo 3 > /proc/sys/vm/drop_caches. Dokumentiere immer, ob ein Test warm oder cold Cache war. Prüfe mit free -h und vmstat 1, ob der Cache Einfluss nimmt.
Falsche Block- oder Dateigrößen
Tests mit großen Blockgrößen zeigen guten Durchsatz, aber keine realistischen IOPS für kleine Dateien. Verwende Blockgrößen wie 4K oder 8K für typische kleine Datei-Workloads. Ergänze 16K und 64K, um Übergänge sichtbar zu machen. In fio setzt du --bs=4k bzw. --bs=64k. Teste außerdem mit echten kleinen Dateien statt nur einem großen Testfile. So siehst du Metadaten-Overhead.
Kein wiederholtes Messen und keine Statistik
Ein einzelner Lauf ist kein belastbarer Wert. Wiederhole jeden Test mindestens 3 bis 5 Mal. Berechne Median und Perzentile wie P95 und P99. Nutze fio-JSON-Ausgabe --output-format=json --output=out.json zur automatisierten Auswertung. Notiere Umgebungseinflüsse wie Temperatur oder Hintergrundprozesse. So erkennst du Ausreißer und Stabilitätsprobleme.
Tests auf vollem vs. leerem Laufwerk nicht unterscheiden
Leere Laufwerke liefern oft bessere Werte. Full- oder fast volle Geräte verändern Garbage Collection und Wear-Leveling. Nutze fstrim mit fstrim -v /mnt/test vor Cold-Tests. Simuliere volle Zustände, indem du das Laufwerk zu einem relevanten Füllgrad bringst. Dokumentiere Kapazitätszustand und verfügbare freie Blöcke.
Missachtung von Metadaten-Overhead
Create/Delete/Stat-Operationen dominieren bei vielen kleinen Dateien. Ein reiner Block-I/O-Test unterschätzt diese Kosten. Führe gezielte Metadaten-Tests durch mit Tools wie bonnie++ oder filebench. Oder lege viele kleine Dateien an und messe Create/Unlink-Raten. Achte auf fsync-Aufrufe. Wenn deine Anwendung viele fsyncs macht, simuliere das explizit.
Prüfungen und Gegenmaßnahmen zusammengefasst: dokumentiere Cache-Zustand, Blockgrößen, Wiederholungen, Füllgrad und Dateisystemoptionen. Nutze Monitoring-Tools wie iostat -x 1, vmstat 1 und SMART-/NVMe-Health-Abfragen. So vermeidest du Fehlinterpretationen und bekommst belastbare, vergleichbare Messergebnisse.