Antworten:
Normalerweise vergleiche ich hdparmmeine Festplatten mit Benchmarks. Sie können sowohl die direkten Lesevorgänge als auch die zwischengespeicherten Lesevorgänge vergleichen. Sie müssen die Befehle mehrmals ausführen, um einen Durchschnittswert zu ermitteln.
Hier ist eine direkte Lektüre.
$ sudo hdparm -t /dev/sda2
/dev/sda2:
Timing buffered disk reads: 302 MB in 3.00 seconds = 100.58 MB/sec
Und hier ist eine zwischengespeicherte Lektüre.
$ sudo hdparm -T /dev/sda2
/dev/sda2:
Timing cached reads: 4636 MB in 2.00 seconds = 2318.89 MB/sec
-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.
Ich habe auch ddfür diese Art von Tests verwendet. Eine Änderung, die ich am obigen Befehl vornehmen würde, ist das Hinzufügen dieses Bits am Ende Ihres Befehls ; rm ddfile.
$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"; rm ddfile
Dadurch wird das Symbol entfernt, ddfilenachdem der Befehl ausgeführt wurde. HINWEIS: Es ddfile handelt sich um eine vorübergehende Datei, die Sie nicht aufbewahren müssen. Es handelt sich um die Datei, ddin die ( of=ddfile) geschrieben wird, wenn die Festplatte geladen wird.
Wenn Sie strengere Tests Ihrer Festplatten benötigen, können Sie Bonnie ++ verwenden .
hdparmauch schnelle Benchmarks. Der einzige Nachteil ist, dass nur die Lesebandbreite gemessen wird und die Leistung vieler Arten von Blockgeräten (z. B. RAID, iSCSI) sehr asymmetrisch sein kann. Auch der Vergleich von Vorher- und Nachher-Leistung auf derselben Box ddfunktioniert gut.
hdparm+ ddoder nur bonnie++oder alle 3 verwenden.
(Dies ist eine sehr beliebte Frage. Variationen davon finden Sie unter https://stackoverflow.com/q/1198691 , https://serverfault.com/q/219739/203726 und https://askubuntu.com/q / 87035/740413 )
Gibt es bessere Methoden [als dd], um [Festplatten zu bewerten]?
Ja, aber die Ausführung dauert länger und erfordert Kenntnisse über die Interpretation der Ergebnisse. Es gibt keine einzelne Zahl, die Ihnen alles auf einmal sagt, da die folgenden Faktoren die Art des Tests beeinflussen, den Sie ausführen sollten:
Und so weiter.
Hier ist eine kurze Liste der Tools, die oben am einfachsten und unten am schwierigsten / gründlicher / besser auszuführen sind:
Greg - hol Jens 'FIO-Code. Es macht die Dinge richtig, einschließlich des Schreibens von tatsächlichen pseudozufälligen Inhalten, was zeigt, ob die Festplatte eine gewisse "Deduplizierung" durchführt (auch bekannt als "Optimierung für Benchmarks"):
[ https://github.com/axboe/fio/ ]
Alles andere ist verdächtig - vergessen Sie Bonnie oder andere traditionelle Werkzeuge.
Quelle: Kommentar von Linus Torvalds zu Google Plus an Greg Kroah-Hartman .
Wenn Sie nicht die Mühe haben, all dies zu lesen, würde ich Ihnen nur das IOPS-Tool empfehlen . Es wird Ihnen die reale Geschwindigkeit in Abhängigkeit von der Blockgröße anzeigen.
Andernfalls würde ich mir bei einem IO-Benchmark die folgenden Dinge ansehen:
CPU-Auslastung
Welche Blockgröße werden Sie verwenden : Wenn Sie 1 GB von / auf Festplatte lesen / schreiben möchten, ist dies schnell, wenn Sie eine E / A-Operation ausführen. Wenn Ihre Anwendung jedoch 512-Byte-Blöcke auf der gesamten Festplatte in nicht aufeinander folgenden Teilen schreiben muss (die als zufällige E / A bezeichnet werden, obwohl sie nicht zufällig sind), sieht dies anders aus. Jetzt führen Datenbanken aufgrund ihrer Art zufällige E / A-Vorgänge für das Datenvolumen und sequenzielle E / A-Vorgänge für das Protokollvolumen durch . Zunächst müssen Sie sich klar machen, was Sie messen möchten. Wenn Sie große Videodateien kopieren möchten, unterscheidet sich dies von der Installation von Linux.
Diese Blockgröße wirkt sich auf die Anzahl der von Ihnen ausgeführten E / A-Vorgänge aus. Wenn Sie z. B. 8 sequentielle Lese- (oder Schreib-) Vorgänge ausführen, werden diese vom E / A-Scheduler des Betriebssystems zusammengeführt. Ist dies nicht der Fall, führt der Cache des Controllers die Zusammenführung durch. Es gibt praktisch keinen Unterschied, wenn Sie 8 aufeinanderfolgende Blöcke mit 512 Bytes oder einen Block mit 4096 Bytes lesen. Eine Ausnahme: Wenn Sie die direkte Synchronisierung von E / A-Vorgängen durchführen und auf die 512 Bytes warten, bevor Sie die nächsten 512 Bytes anfordern. In diesem Fall entspricht das Erhöhen der Blockgröße dem Hinzufügen eines Caches.
Beachten Sie auch, dass es synchrone und asynchrone E / A gibt: Mit synchrone E / A stellen Sie die nächste E / A-Anforderung nicht aus, bevor die aktuelle zurückkehrt. Mit async IO können Sie zB 10 Datenblöcke anfordern und dann warten, bis sie ankommen. Getrennte Datenbankthreads verwenden normalerweise Synchronisierungs-E / A für die Protokollierung und Asynchronisierungs-E / A für die Daten. Das IOPS-Tool sorgt dafür, dass alle relevanten Blockgrößen ab 512 Byte gemessen werden.
Lesen oder schreiben Sie : Normalerweise ist das Lesen schneller als das Schreiben. Beachten Sie jedoch, dass das Zwischenspeichern beim Lesen und Schreiben ganz anders funktioniert:
Beim Schreiben werden die Daten an den Controller übergeben, und wenn sie zwischengespeichert werden, werden sie bestätigt, bevor sich die Daten auf der Festplatte befinden, sofern der Cache nicht voll ist. Mit dem Tool iozone können Sie wunderschöne Grafiken von Plateaus von Cache-Effekten (CPU-Cache-Effekt und Puffer-Cache-Effekt) zeichnen. Der Cache wird umso weniger effizient, je mehr geschrieben wurde.
Bei Lesevorgängen werden die Lesedaten nach dem ersten Lesevorgang im Cache gespeichert. Die ersten Lesevorgänge dauern am längsten und das Caching wird während der Betriebszeit immer effektiver. Bemerkenswerte 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 Lesevorgänge. Dies ermöglicht es, "überall zu 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 mehrere Threads.
Wie wichtig ist die Latenz für Sie ? Bei der Betrachtung von Datenbanken wird die E / A-Latenz enorm wichtig. Jeder SQL-Befehl zum Einfügen / Aktualisieren / Löschen wird beim Festschreiben in das Datenbankjournal ("Protokoll" in der Datenbanksprache) geschrieben, bevor er bestätigt wird. Dies bedeutet, dass die gesamte Datenbank möglicherweise auf den Abschluss dieser E / A-Operation wartet. Ich zeige hier, wie man die durchschnittliche Wartezeit (wait) 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 Byte gelesen / geschrieben werden, und in diese Richtung optimieren. Dies kann bedeuten, dass Sie sich abhängig von Ihren Messergebnissen für / gegen einen PCIe-Flash-Speicher entscheiden müssen. Das iostat-Tool kann Ihnen wiederum eine grobe Einschätzung der CPU-Auslastung durch Ihre E / A-Vorgänge geben.
Wenn Sie PostgreSQL installiert haben, können Sie deren hervorragenden pg_test_fsync- Benchmark verwenden. Testen Sie im Grunde Ihre Schreibsynchronisationsleistung.
Auf Ubuntu finden Sie es hier: /usr/lib/postgresql/9.5/bin/pg_test_fsync
Das Tolle daran ist, dass dieses Tool Ihnen zeigt, warum Enterprise-SSDs den Aufpreis wert sind.
postgresql-contribPaket verfügbar .
Sie können fio- das Multithreaded IO-Generierungstool verwenden . Es wird von mehreren Distributionen gepackt, zB Fedora 25, Debian und OpenCSW.
Das fio-Tool ist sehr flexibel und kann problemlos zum Benchmarking verschiedener E / A-Szenarien verwendet werden - auch für gleichzeitige. Das Paket enthält einige Beispielkonfigurationsdateien (vgl. ZB /usr/share/doc/fio/examples). Es misst die Dinge richtig, dh es druckt auch die Standardabweichung und die quantitative Statistik für einige Zahlen. Dinge, die einige andere beliebte Benchmarking-Tools nicht interessieren.
Ein einfaches Beispiel (eine Folge von einfachen Szenarien: sequentielles / zufälliges X Lesen / Schreiben):
$ cat fio.cfg
[global]
size=1g
filename=/dev/sdz
[randwrite]
rw=randwrite
[randread]
wait_for=randwrite
rw=randread
size=256m
[seqread]
wait_for=randread
rw=read
[seqwrite]
wait_for=seqread
rw=write
Der Anruf:
# fio -o fio-seagate-usb-xyz.log fio.cfg
$ cat fio-seagate-usb-xyz.log
[..]
randwrite: (groupid=0, jobs=1): err= 0: pid=11858: Sun Apr 2 21:23:30 2017
write: io=1024.0MB, bw=16499KB/s, iops=4124, runt= 63552msec
clat (usec): min=1, max=148280, avg=240.21, stdev=2216.91
lat (usec): min=1, max=148280, avg=240.49, stdev=2216.91
clat percentiles (usec):
| 1.00th=[ 2], 5.00th=[ 2], 10.00th=[ 2], 20.00th=[ 7],
| 30.00th=[ 10], 40.00th=[ 11], 50.00th=[ 11], 60.00th=[ 12],
| 70.00th=[ 14], 80.00th=[ 16], 90.00th=[ 19], 95.00th=[ 25],
| 99.00th=[ 9408], 99.50th=[10432], 99.90th=[21888], 99.95th=[38144],
| 99.99th=[92672]
bw (KB /s): min= 7143, max=371874, per=45.77%, avg=15104.53, stdev=32105.17
lat (usec) : 2=0.20%, 4=15.36%, 10=6.58%, 20=69.35%, 50=6.07%
lat (usec) : 100=0.49%, 250=0.07%, 500=0.01%, 750=0.01%
lat (msec) : 4=0.01%, 10=1.20%, 20=0.54%, 50=0.08%, 100=0.03%
lat (msec) : 250=0.01%
cpu : usr=1.04%, sys=4.79%, ctx=4977, majf=0, minf=11
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued : total=r=0/w=262144/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=1
randread: (groupid=0, jobs=1): err= 0: pid=11876: Sun Apr 2 21:23:30 2017
read : io=262144KB, bw=797863B/s, iops=194, runt=336443msec
[..]
bw (KB /s): min= 312, max= 4513, per=15.19%, avg=591.51, stdev=222.35
[..]
Beachten Sie, dass der [global]Abschnitt globale Standardeinstellungen hat, die von anderen Abschnitten überschrieben werden können. Jeder Abschnitt beschreibt einen Job, der Abschnittsname ist der Jobname und kann frei gewählt werden. Standardmäßig werden verschiedene Jobs parallel gestartet, sodass im obigen Beispiel die Jobausführung mit dem wait_forSchlüssel explizit serialisiert wird
. Außerdem verwendet fio eine Blockgröße von 4 KB, die ebenfalls geändert werden kann. In diesem Beispiel wird das Raw-Gerät direkt für Lese- und Schreibaufträge verwendet. Stellen Sie daher sicher, dass Sie das richtige Gerät verwenden. Das Tool unterstützt auch die Verwendung einer Datei / eines Verzeichnisses in vorhandenen Dateisystemen.
Das hdparmDienstprogramm bietet einen sehr einfachen Lese-Benchmark, zB:
# hdparm -t -T /dev/sdz
Es ist kein Ersatz für ein modernes Benchmarking-Tool wie fio, es sollte nur für eine erste Plausibilitätsprüfung verwendet werden. Um beispielsweise zu überprüfen, ob das externe USB-3-Laufwerk fälschlicherweise als USB-2-Gerät erkannt wird (dann werden ~ 100 MiB / s im Vergleich zu ~ 30 MiB / s angezeigt).
Wie hier bereits erwähnt , können Sie gnome-disks(wenn Sie Gnome verwenden) verwenden.
Klicken Sie auf das Laufwerk, das Sie testen möchten, und klicken Sie auf "Zusätzliche Partitionsoptionen" (die Räder). Dann Benchmark Partition. Sie erhalten eine durchschnittliche Lese- / Schreibgeschwindigkeit in MB / s und eine durchschnittliche Zugriffszeit in Millisekunden. Das fand ich sehr angenehm.
Es ist ein wenig grob, aber das funktioniert zur Not:
find <path> -type f -print0 | cpio -0o >/dev/null
Mit dieser Technik können Sie einige interessante Dinge tun, einschließlich des Zwischenspeicherns aller /libund /usr/binDateien. Sie können dies auch als Teil eines Benchmarking verwenden:
find / -xdev -type f -print0 |
sort -R --from0-file=- |
timeout "5m" cpio -0o >/dev/null
Alle Dateinamen im Stammverzeichnis werden gefunden, nach dem Zufallsprinzip sortiert und für bis zu 1 Minute in den Cache kopiert. Die Ausgabe von cpio gibt an, wie viele Blöcke kopiert wurden. Wiederholen Sie diesen Vorgang dreimal, um einen Durchschnitt von Blöcken pro Minute zu erhalten. (Beachten Sie, dass der Such- / Sortiervorgang möglicherweise lange dauert - viel länger als die Kopie. Es ist besser, den Such- / Sortiervorgang zwischenzuspeichern und splitein Beispiel für Dateien abzurufen.)