Normalerweise verwende ich hdparm um meine HDDs zu benchmarken. Sie können sowohl die direkten Lesevorgänge als auch die zwischengespeicherten Lesevorgänge bewerten. Sie sollten die Befehle einige Male ausführen, um einen Durchschnittswert zu ermitteln.
Beispiele
Hier ist eine direkte Lesung.
$ sudo hdparm -t /dev/sda2
/dev/sda2:
Timing buffered disk reads: 302 MB in 3.00 seconds = 100.58 MB/sec
Und hier ist ein zwischengespeicherter Lesevorgang.
$ sudo hdparm -T /dev/sda2
/dev/sda2:
Timing cached reads: 4636 MB in 2.00 seconds = 2318.89 MB/sec
Einzelheiten
-t Perform timings of device reads for benchmark and comparison
purposes. For meaningful results, this operation should be repeated
2-3 times on an otherwise inactive system (no other active processes)
with at least a couple of megabytes of free memory. This displays
the speed of reading through the buffer cache to the disk without
any prior caching of data. This measurement is an indication of how
fast the drive can sustain sequential data reads under Linux, without
any filesystem overhead. To ensure accurate measurements, the
buffer cache is flushed during the processing of -t using the
BLKFLSBUF ioctl.
-T Perform timings of cache reads for benchmark and comparison purposes.
For meaningful results, this operation should be repeated 2-3
times on an otherwise inactive system (no other active processes)
with at least a couple of megabytes of free memory. This displays
the speed of reading directly from the Linux buffer cache without
disk access. This measurement is essentially an indication of the
throughput of the processor, cache, and memory of the system under
test.
Mit dd
Auch ich habe dd verwendet auch für diese Art von Tests. Eine Änderung, die ich am obigen Befehl vornehmen würde, besteht darin, dieses Bit am Ende Ihres Befehls hinzuzufügen, ; rm ddfile .
$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"; rm ddfile
Dadurch wird ddfile entfernt nachdem der Befehl ausgeführt wurde. HINWEIS: ddfile ist eine vorübergehende Datei, die Sie nicht aufbewahren müssen, es ist die Datei, die dd schreibt in (of=ddfile ), wenn Ihre Festplatte belastet wird.
Hinausgehen
Wenn Sie strengere Tests Ihrer Festplatten benötigen, können Sie Bonnie++ verwenden.
Referenzen
- Wie verwende ich 'dd' zum Benchmarking Ihrer Festplatte oder CPU?
- Benchmark Disk IO mit DD und Bonnie++
(Dies ist eine sehr beliebte Frage – Sie können Variationen davon auf https://stackoverflow.com/q/1198691 , https://serverfault.com/q/219739/203726 und https://askubuntu.com/q sehen /87035/740413 )
Gibt es bessere Methoden [als dd], um [Festplatten zu vergleichen]?
Ja, aber die Ausführung dauert länger und erfordert Kenntnisse darüber, wie die Ergebnisse zu interpretieren sind. Es gibt keine einzelne Zahl, die Ihnen alles auf einmal sagt, denn die folgenden Faktoren beeinflussen die Art des Tests, den Sie durchführen sollten:
- Interessieren Sie sich für die Leistung von E/A, die zufällig, sequentiell oder eine Mischung aus beidem ist?
- Lesen Sie von oder auf die Festplatte (oder eine Mischung aus beidem)?
- Sorgen Sie sich um Latenz, Durchsatz oder beides?
- Versuchen Sie zu verstehen, wie verschiedene Teile derselben Festplatte funktionieren (im Allgemeinen schneller, näher an der Mitte von sich drehenden Festplatten)?
- Interessieren Sie sich dafür, wie ein bestimmtes Dateisystem funktioniert, wenn Sie Ihre Festplatte verwenden, oder möchten Sie Ergebnisse, die näher an der Rohleistung der Festplatte liegen, indem Sie E/A direkt an ein Blockgerät senden?
- Interessieren Sie sich für die Leistung einer bestimmten E/A-Größe?
- Senden Sie die E/A synchron oder asynchron?
- Wie viele E/A-Vorgänge übermitteln Sie (übermitteln Sie zu wenig auf die falsche Art und Weise, und alle E/A-Vorgänge könnten zwischengespeichert werden, sodass Sie am Ende eher die Geschwindigkeit Ihres Arbeitsspeichers als die Geschwindigkeit der Festplatte testen)?
- Wie komprimierbar ist der Inhalt der Daten, die Sie schreiben (z. B. sind Nur-Null-Daten stark komprimierbar und einige Dateisysteme/Festplatten haben sogar einen speziellen Fast-Path für Nur-Null-Daten, was zu Zahlen führt, die mit anderen Inhalten nicht erreichbar sind)?
Und so weiter.
Hier ist eine kurze Liste von Tools, die am einfachsten oben und schwierig/gründlicher/besser weiter unten zu finden sind:
- dd (sequentielles Lesen oder Schreiben, zeigt nur den Durchsatz, kann so konfiguriert werden, dass es ein Dateisystem oder Blockgerät verwendet, kann so konfiguriert werden, dass es den Block-Cache umgeht/wartet, bis I/O wirklich abgeschlossen ist)
- hdparm (nur sequentielles Lesen, zeigt nur den Durchsatz, verwendet nie ein Dateisystem, kann so konfiguriert werden, dass der Block-Cache umgangen wird, Cache-Test liest nur die beginnenden 2 MB neu)
- Benchmark des GNOME-Festplatten-Dienstprogramms (leicht auszuführen, verwendet nie ein Dateisystem, grafisch, erfordert aber eine vollständige GNOME-Installation, gibt Latenz- und Durchsatzzahlen für verschiedene I/O-Typen an, aber die Schreibarbeitslast führt tatsächlich Lesen/Schreiben/fsync pro Sample aus Größe).
- fio (kann fast alles tun und liefert detaillierte Ergebnisse, erfordert jedoch eine Konfiguration und ein Verständnis dafür, wie diese Ergebnisse zu interpretieren sind). Hier ist, was Linus dazu sagt:
Greg - Holen Sie sich den FIO-Code von Jens. Es macht die Dinge richtig, einschließlich des Schreibens tatsächlicher pseudozufälliger Inhalte, die zeigen, ob die Festplatte eine gewisse "Deduplizierung" durchführt (auch bekannt als "für Benchmarks optimieren):
[ https://github.com/axboe/fio/ ]
Alles andere ist verdächtig – vergessen Sie Bonnie oder andere traditionelle Werkzeuge.
Quelle: Kommentar, den Linus Torvalds auf Google Plus für Greg Kroah-Hartman hinterlassen hat.
mit dem IOPS-Tool
Wenn Sie sich nicht die Mühe machen, das alles zu lesen, würde ich nur das IOPS-Tool empfehlen. Es zeigt Ihnen die reale Geschwindigkeit in Abhängigkeit von der Blockgröße an.
Ansonsten würde ich mir bei einem IO-Benchmark folgende Dinge ansehen:
- Blockgröße/Cache/IOPS/direkt vs. gepuffert/async vs. sync
- lesen/schreiben
- Fäden
- Latenz
-
CPU-Auslastung
-
Welche Blockgröße werden Sie verwenden :Wenn Sie 1 GB von/auf die Festplatte lesen/schreiben möchten, geht dies schnell, wenn Sie eine E/A-Operation ausführen. Wenn Ihre Anwendung jedoch 512-Byte-Blöcke in nicht sequentiellen Stücken über die gesamte Festplatte schreiben muss (Random I/O genannt, obwohl es nicht zufällig ist), sieht dies anders aus. Jetzt führen Datenbanken aufgrund ihrer Natur zufällige E/A für das Datenvolumen und sequentielle E/A für das Protokollvolumen aus. Zuerst müssen Sie sich also darüber im Klaren sein, was Sie messen wollen. Wenn Sie große Videodateien kopieren möchten, ist das anders, als wenn Sie Linux installieren möchten.
Diese Blockgröße wirkt sich auf die Anzahl der E/A-Operationen aus, die Sie ausführen. Wenn Sie z. 8 sequentielle Lese- (oder Schreib-, nur nicht gemischte) Operationen, die der E/A-Scheduler des Betriebssystems zusammenführt. Wenn dies nicht der Fall ist, führt der Cache des Controllers die Zusammenführung durch. Es macht praktisch keinen Unterschied, ob Sie 8 aufeinanderfolgende Blöcke von 512 Bytes oder einen 4096-Bytes-Chunk lesen. Eine Ausnahme - wenn Sie es schaffen, direktes Sync-IO durchzuführen und auf die 512 Bytes zu warten, bevor Sie die nächsten 512 Bytes anfordern. In diesem Fall ist das Erhöhen der Blockgröße wie das Hinzufügen von Cache.
Außerdem sollten Sie sich bewusst sein, dass es Sync- und Async-IO gibt:Mit Sync-IO werden Sie die nächste IO-Anforderung nicht ausgeben, bevor die aktuelle zurückkehrt. Mit async IO können Sie z.B. 10 Datenblöcke und dann warten, bis sie ankommen. Unterschiedliche Datenbank-Threads verwenden normalerweise synchrone E/A für Protokolle und asynchrone E/A für Daten. Das IOPS-Tool kümmert sich darum, indem alle relevanten Blockgrößen ab 512 Bytes gemessen werden.
-
Wirst du lesen oder schreiben :Normalerweise ist Lesen schneller als Schreiben. Beachten Sie jedoch, dass das Caching für Lese- und Schreibvorgänge ganz anders funktioniert:
-
Bei Schreibvorgängen werden die Daten an den Controller übergeben, und wenn er zwischenspeichert, wird er dies bestätigen, bevor die Daten auf der Festplatte sind, es sei denn, der Cache ist voll. Mit dem Tool iozone können Sie schöne Diagramme von Plateaus von Cache-Effekten (CPU-Cache-Effekt und Puffer-Cache-Effekt) zeichnen. Die Caches werden weniger effizient, je mehr geschrieben wurde.
-
Bei Lesevorgängen werden gelesene Daten nach dem ersten Lesevorgang im Cache gehalten. Die ersten Lesevorgänge dauern am längsten und das Caching wird während der Betriebszeit immer effektiver. Nennenswerte Caches sind der CPU-Cache, der Dateisystem-Cache des Betriebssystems, der Cache des IO-Controllers und der Cache des Speichers. Das IOPS-Tool misst nur liest. Dadurch kann es "überall lesen" und Sie möchten nicht, dass es schreibt, anstatt zu lesen.
-
-
Wie viele Threads werden Sie verwenden :Wenn Sie einen Thread verwenden (mit dd für Festplatten-Benchmarks), erhalten Sie wahrscheinlich eine viel schlechtere Leistung als mit mehreren Threads. Das IOPS-Tool berücksichtigt dies und liest in mehreren Threads.
-
Wie wichtig ist Latenz für Sie :Betrachtet man Datenbanken, wird die IO-Latenz enorm wichtig. Jeder SQL-Befehl zum Einfügen/Aktualisieren/Löschen wird beim Festschreiben in das Datenbankjournal ("log" im Datenbankjargon) geschrieben, bevor er bestätigt wird. Das bedeutet, dass möglicherweise die gesamte Datenbank auf den Abschluss dieser IO-Operation wartet. Ich zeige hier, wie man die durchschnittliche Wartezeit (await) mit dem Iostat-Tool misst .
-
Wie wichtig ist die CPU-Auslastung für Sie? :Ihre CPU kann leicht zum Engpass für die Leistung Ihrer Anwendung werden. In diesem Fall müssen Sie wissen, wie viel CPU-Zyklen pro gelesenem/geschriebenem Byte verbraucht werden, und in diese Richtung optimieren. Das kann bedeuten, sich je nach Messergebnis für/gegen PCIe-Flashspeicher zu entscheiden. Wieder das Iostat-Tool kann Ihnen eine grobe Schätzung der CPU-Auslastung durch Ihre IO-Operationen geben.