LSI Performance mit WD Raptor

gfrank

New Member
Hallo,

ich komme gerade an einem Punkt nicht weiter. Es handelt sich um 2 Systeme:

A)
Supermicro X9DR3-F mit 2x Xeon E5-2620 und 128GB RAM
LSI 9271-8i mit 19x WD Raptor (WD1000DHTZ), RAID6, 256k und 3x SSD im RAID5, 256k Stripe
Debian Wheezy

B)
Supermicro X9SRE-3F mit 1x Xeon E5-1620 und 64GB RAM
3ware 9750-8i mit 8x WD Raptor (WD1000DHTZ), RAID6, 256k Stripe
2x SSD onboard angeschlossen im RAID1
Debian Wheezy

Filesystem ist XFS. Read-Cache der Controller ist aus, always Write-Back ist immer aktiviert. Nachfolgend ein paar einfache dd-Tests

Code:
Raptor auf A)
time dd if=/dev/zero of=datei bs=1M count=30000 oflag=direct
30000+0 Datensätze ein
30000+0 Datensätze aus
31457280000 Bytes (31 GB) kopiert, 18,419 s, 1,7 GB/s

time dd if=/dev/zero of=datei bs=4k count=100000 oflag=direct
100000+0 Datensätze ein
100000+0 Datensätze aus
409600000 Bytes (410 MB) kopiert, 7,40164 s, 55,3 MB/s

Raptor auf B)
time dd if=/dev/zero of=datei bs=1M count=30000 oflag=direct
30000+0 Datensätze ein
30000+0 Datensätze aus
31457280000 Bytes (31 GB) kopiert, 38,0841 s, 826 MB/s

time dd if=/dev/zero of=datei bs=4k count=100000 oflag=direct
100000+0 Datensätze ein
100000+0 Datensätze aus
409600000 Bytes (410 MB) kopiert, 3,83493 s, 107 MB/s

SSD auf A)
time dd if=/dev/zero of=datei bs=4k count=100000 oflag=direct
100000+0 Datensätze ein
100000+0 Datensätze aus
409600000 Bytes (410 MB) kopiert, 6,5352 s, 62,7 MB/s

SSD auf B)
time dd if=/dev/zero of=datei bs=4k count=100000 oflag=direct
100000+0 Datensätze ein
100000+0 Datensätze aus
409600000 Bytes (410 MB) kopiert, 7,95507 s, 51,5 MB/s

Auf den Systemen herrscht viel Random I/O durch MySQL (InnoDB). Mir fiel auf, dass Prozesse auf A) deutlich langsamer liefen als auf B). Und daher die Frage: kann sich irgendjemand erklären, warum das Raptor-Array auf A) bei einer Blocksize von 4k so langsam ist? Bei großen Blocksizes ist alles im Lot und selbst die SSDs bei 4k sind schneller als auf B). Ich habe keine Idee mehr, was es sein kann. Habe aus den 19 Raptor-Platten natürlich auch schon verschiedene andere Arrays gebaut (andere Stripe-Sizes, Anzahl der Platten verringert, selbst eins mit 2 Platten und RAID0) - immer hängt der so bei 50-55MB/s.

UDPATE 12.02.: aktuellste Firmware (MR 5.9) ist auf dem LSI drauf, ohne Verbesserung
 
Last edited by a moderator:
Ich habe das Glück viele sehr verschiedene Hardware im Zugriff zu haben und habe den 4kB-dd-Test mal auf verschiedenen Maschinen gemacht.

Alles wheezy-Maschinen, alle nach dem gleichen Grundprinzip aufgesetzt, RAIDs haben Standard-Stripes, Write-Back ist immer angeschaltet.

time dd if=/dev/zero of=datei bs=4k count=100000 oflag=direct
time dd if=/dev/zero of=datei bs=1M count=10000 oflag=direct

Code:
A) HosterA 2x SSD SW-RAID1, EXT4
409600000 Bytes (410 MB) kopiert, 3,26518 s, 125 MB/s
10485760000 Bytes (10 GB) kopiert, 21,7706 s, 482 MB/s
B) HosterA 2x HDD SW-RAID1, EXT4
409600000 Bytes (410 MB) kopiert, 8,04576 s, 50,9 MB/s
10485760000 Bytes (10 GB) kopiert, 70,1136 s, 150 MB/s
C) HosterA 7x HDD SW-RAID6, EXT4
409600000 Bytes (410 MB) kopiert, 18,2852 s, 22,4 MB/s
10485760000 Bytes (10 GB) kopiert, 114,949 s, 91,2 MB/s
D) HosterB 2x SSD SW-RAID1, EXT4
409600000 Bytes (410 MB) kopiert, 8,53401 s, 48,0 MB/s
10485760000 Bytes (10 GB) kopiert, 137,386 s, 76,3 MB/s
E) HosterC 2x HDD SW-RAID1, EXT4
409600000 Bytes (410 MB) kopiert, 8,86581 s, 46,2 MB/s
10485760000 Bytes (10 GB) kopiert, 77,1026 s, 136 MB/s

F) HosterB 8x HDD 3ware9750-RAID6, XFS
409600000 Bytes (410 MB) kopiert, 3,00131 s, 136 MB/s
10485760000 Bytes (10 GB) kopiert, 9,79647 s, 1,1 GB/s
G) HosterA 2x SSD LSI9260-RAID1, EXT4
409600000 Bytes (410 MB) kopiert, 6,1076 s, 67,1 MB/s
10485760000 Bytes (10 GB) kopiert, 32,1844 s, 326 MB/s
H) HosterA 15x HDD LSI9260-RAID6, EXT4
409600000 Bytes (410 MB) kopiert, 5,92834 s, 69,1 MB/s
10485760000 Bytes (10 GB) kopiert, 25,5148 s, 411 MB/s
I) HosterC 2x SSD LSI9271-RAID1, EXT4
409600000 Bytes (410 MB) kopiert, 6,66638 s, 61,4 MB/s
10485760000 Bytes (10 GB) kopiert, 26,4503 s, 396 MB/s
J) HosterC 19x HDD LSI9271-RAID6, XFS
409600000 Bytes (410 MB) kopiert, 7,26831 s, 56,4 MB/s
10485760000 Bytes (10 GB) kopiert, 6,26498 s, 1,7 GB/s
K) HosterA 6x SSD PERC-RAID6, EXT4
409600000 Bytes (410 MB) kopiert, 6,60291 s, 62,0 MB/s
10485760000 Bytes (10 GB) kopiert, 12,1017 s, 866 MB/s
L) HosterC 8x HDD ADAP6805-RAID6, XFS
409600000 Bytes (410 MB) kopiert, 9,39082 s, 43,6 MB/s
10485760000 Bytes (10 GB) kopiert, 14,2463 s, 736 MB/s
M) HosterC 4x HDD ADAP6405-RAID5, EXT4
409600000 Bytes (410 MB) kopiert, 9,41427 s, 43,5 MB/s
10485760000 Bytes (10 GB) kopiert, 34,4128 s, 305 MB/s

Ein vollkommen verrücktes Bild.
Bei 1MB Blocksize finde ich alle Ergebnisse plausibel, bis auf A) und D) und bei der 4kB Blocksize find ich alle plausibel, bis auf A), D) und G)-M). Kann da jemand helfen? Insbesondere warum A) und G) so voneinander abweichen!?
 
Mit oflag=direct umgeht man den page cache aber nicht den cache des Controllers.

Eigentlich testet ihr so nur den Durchsatz des Schreibcache auf dem Controller, oder?
 
Ja, ich glaube so versteh ich das auch was das oflag anbetrifft. Aber wo ist dann trotzdem mein Denkfehler? Ja, kleine Blockgrößen verursachen sicher genug Overhead, aber warum sind dann (bis auf A+F) bei 4k alle annähernd gleich von der Leistung. Der 3ware9750 ist vom Prinzip her ein leistungsschwächerer Vorgänger des LSI9271, trotzdem fährt der die beste Leistung ein, ebenso seltsamer Weise die SSDs an Maschine A. Aus irgendeinem Grund müssen es die beiden Maschinen ja schaffen, >100MB/s zu schreiben.

Siehe auch den Vergleich von F) und J). F hat den älteren 3ware9750 mit 8x WD1000DHTZ und J den neueren LSI9271 mit 19x WD1000DHTZ (siehe auch Eröffnungspost, das sind die beiden Maschinen). Bei 1MB BS schlägt F die kleinere Maschine deutlich, aber bei 4kB ist sie deutlich schlechter. Beide Systeme sind minimal per Wheezy Netinstaller aufgesetzt nach der gleichen Anleitung. Partitionen sind per "gparted -a optimal" eingerichtet. Ich finde den Fehler einfach nicht.
 
Last edited by a moderator:
Die Vermutung liegt nahe, dass er bei den 4k-Schreibtests an die I/O-Grenzen des Controllers stößt. Anders kann ich es nicht mehr erklären. Wundert mich zwar trotzdem, dass der Durchsatz bei 4k nahezu gleich ist bei allen Maschinen unabhängig von der Ausstattung, aber bis jetzt ist das die plausibelste Erklärung.
 
Back
Top