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
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
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: