Ich habe einige einfache Leistungstests durchgeführt und es scheint, dass das Lesen von meinem RAID1 langsamer ist als das Schreiben:

root@dss0:~# for i in 1 2 3; do dd if=/dev/zero of=/dev/sda bs=1048576 count=131072; done
137438953472 bytes (137 GB) copied, 192.349 s, 715 MB/s
137438953472 bytes (137 GB) copied, 192.851 s, 713 MB/s
137438953472 bytes (137 GB) copied, 193.026 s, 712 MB/s
root@dss0:~# for i in 1 2 3; do dd if=/dev/sda of=/dev/null bs=1048576 count=131072; done
137438953472 bytes (137 GB) copied, 257.201 s, 534 MB/s
137438953472 bytes (137 GB) copied, 255.522 s, 538 MB/s
137438953472 bytes (137 GB) copied, 259.945 s, 529 MB/s

Ich verstehe, dass dd kein Leistungstest-Tool ist, aber dieses Ergebnis ist immer noch eine Überraschung.

Das System wurde vom Hersteller gebaut und verfügt über eine Supermicro-Hauptplatine mit 16 GB RAM. Der RAID-Controller ist ein MegaRAID 9271-8i mit 1 GByte Cache. Auf einer SAS-933EL1-Rückwandplatine befinden sich 8 2-TByte-SAS-Festplatten. Ich bin mir der Verkabelung nicht sicher. Ein Anschluss des Controllers führt zur SAS-Rückwandplatine, der andere zu zwei SATA-Festplatten, auf denen sich das Betriebssystem befindet.

Das RAID1 wurde mit folgendem Befehl eingerichtet:

root@dss0:~# /opt/MegaRAID/MegaCli/MegaCli64 -CfgLdAdd -r1 [8:0,8:1,8:2,8:3,8:4,8:5,8:6,8:7] WB NORA Direct -a0
Adapter 0: Created VD 0
Adapter 0: Configured the Adapter!!
Exit Code: 0x00

root@dss0:~# /opt/MegaRAID/MegaCli/MegaCli64 -LDInfo -LALL -aALL
Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name                :
RAID Level          : Primary-1, Secondary-0, RAID Level Qualifier-0
Size                : 7.275 TB
Sector Size         : 512
Is VD emulated      : No
Mirror Data         : 7.275 TB
State               : Optimal
Strip Size          : 256 KB
Number Of Drives    : 8
Span Depth          : 1
Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy   : Disk's Default
Encryption Type     : None
PI type: No PI
Is VD Cached: No
Exit Code: 0x00

Ich würde erwarten, dass der Lesezugriff mindestens so schnell ist wie der Schreibzugriff, vielleicht sogar noch schneller. Die Schreibgeschwindigkeit von 715 MByte / s scheint nahe der 6-GBit-Grenze eines einzelnen SAS / SATA-Anschlusses zu liegen. Ist dies möglicherweise ein Konfigurations- oder Verkabelungsproblem mit der SAS-Rückwandplatine? Kann die SAS-Backplane-Konfiguration mit einem MegaRAID-Befehl abgefragt werden? Bitte beraten.

Aktualisieren

Wie von poige und Peter dargelegt, wird die langsamer als erwartete Leseleistung wahrscheinlich durch das Caching des Linux-E / A-Subsystems verursacht.

Bei Verwendung des Direktflags im Befehl dd erhalte ich

root@dss0:~# dd if=/dev/sda of=/dev/null bs=1048576 count=131072 iflag=direct
137438953472 bytes (137 GB) copied, 199.862 s, 688 MB/s

Das ist viel besser, aber immer noch 10% langsamer als die Schreibgeschwindigkeit. Die Verwendung von oflag = direct hatte keinen Einfluss auf die Schreibgeschwindigkeit.

poige ist genau richtig in Bezug auf den Schreibcache, aber hier sind weitere Details.

dd mit Nullen und die Verwendung des Schreibcaches ist nicht der richtige Weg zum Benchmarking (es sei denn, Sie möchten den Schreibcache natürlich testen, der wahrscheinlich nur für ein Dateisystem nützlich ist, um festzustellen, wie oft Metadaten synchronisiert, neue Dateien erstellt usw. werden. ) (und wahrscheinlich ist dd immer die falsche Art von Benchmark, aber es funktioniert für einen sehr einfachen Test)

Ich schlage vor, Sie verwenden dd mit mindestens einer der folgenden Optionen:

conv=fdatasync -> this will make it flush to disk before finishing and calculating speed
oflag=direct   -> this will make it skip the OS cache but not the disk cache
conv=sync      -> more like skipping the disk cache too, but not really ... just flushing it every block or something like that.

Und benutze auch keine Null. Einige intelligente Hardware / Software / Firmware verwenden möglicherweise einige Verknüpfungen, wenn die Daten so vorhersehbar sind wie Nullen. Dies gilt insbesondere dann, wenn es eine Komprimierung gibt, die Sie vermutlich nicht verwenden. Verwenden Sie stattdessen eine zufällige Datei im Speicher (z. B. / dev / shm). urandom ist langsam, daher müssen Sie es vorübergehend irgendwo schreiben, um es erneut zu lesen. Erstellen Sie eine 50-MB-Zufallsdatei:

dd if=/dev/urandom of=/dev/shm/randfile bs=1M count=50

Lies die Datei viele Male, um sie zu schreiben (hier benutze ich cat, um sie 6 Mal zu lesen):

dd if=<(cat /dev/shm/randfile{,,,,,}) of= ... conv=fdatasync

rm /dev/shm/randfile

Beachten Sie auch, dass raid1-Lesevorgänge bei parallelen Vorgängen am schnellsten sind, sodass die Festplatten unabhängig voneinander verwendet werden können. Es ist wahrscheinlich nicht klug genug, die Datenträger so zu koordinieren, dass verschiedene Teile desselben Vorgangs mit unterschiedlichen Datenträgern gelesen werden.

Der Schlüssel zur Beantwortung Ihrer Frage liegt im Voraus . Es war einmal, ich hatte auch dieses Problem .

IOW, für eine optimale sequentielle Leseleistung sollten alle Festplatten permanent in den Eingang eingebunden sein.

Wenn Sie ddw / o directio(siehe man dd) verwenden, wird der Schreibvorgang nicht sofort ausgeführt, sondern durchläuft den Betriebssystem-Cache, sodass mehr Chancen bestehen, alle Festplatten nacheinander einzubeziehen und die maximal mögliche Leistung zu erzielen.