Prestatieproblemen RAID 5 Array op 3ware 9550SX-LP

[Profidiam]

Ik heb hier een server met daarin een 3ware 9550SX-LP controller met daaraan een 7-tal disks.
2 x WD raptor 36GB - Raid 1
5 x WD caviar 400GB RE - Raid 10

Nu zijn er performantieproblemen met die raid 10 set. Volgens perfmon is de IO wait queue vaak hoger dan 100, dus ik vrees dat die schijven de gebruikers niet kunnen volgen.

Om te kijken hoe goed de array presteert in vergelijking met andere arrays heb ik iometer gebruikt om zo gegevens te krijgen die ik kan vergelijken met de benchdb op tweakers.net. Dit heeft geresulteerd in volgende meting:

concurrency IOPS
8 245
4 228
2 239
1 208

Nu als ik onze oude server bench (dual MP2400, sx6000 controller, 6x120GB) dan krijg ik:

concurrency IOPS
8 347
4 311
2 248
1 165

Je kan geloven dat ik achterover viel. Een sterk verouderde raid controller in raid 5 kan mij meer io/sec geven dan een recente met 4 disks in raid 10. Dit was niet wat ik verwacht had. Denk ik ergens verkeerd, of zit ik met een bottleneck ergens?

Overigens is de sequentiële transferrate van die raid 10array wel veel beter dan die raid 5 array, maar als mijn gebruikers op hun files moeten wachten, met alle problemen van dien ben ik niet geholpen met hoge seq. transferrates.

[Wim-Bart]

5 x WD caviar 400GB RE - Raid 10 in Raid 10?????? Raid 10 vereist altijd een even aantal disks dus is het 4+1 Hotspare of 5xRaid 0 of Raid 5?

Overigens zal Windows het beste performen bij volumes tot 500GB, grotere volumes verlagen de performance drastisch.

Wanneer je een RAID-5 set hebt dan zou ik even zoeken in Google met de termen "alignment disk". Staan genoeg performance tips.....

[Profidiam]

Wimbart, er zit een spare bij, was ik vergeten vermelden. Het probleem is niet de RAID 5 set, maar de RAID 10 set. Ik dacht dat die een stuk beter moest performen dan die RAID 5 set, maar dit blijkt niet zo te zijn. Ik vraag mij af hoe dit kan komen ...

[Bierkameel]

Niet alle controllers zijn even geweldig in RAID10.
Een slimme controller kan lezen en schijven van de RAID0 en deze op de achtergrond schrijven naar de RAID1.
Een buget controller schrijft en lees tegelijk naar alle 4 schijven waardoor je nogal eens wachttijden krijgt.
Hoe de 9550SX-LP het doet weet ik niet want ik kan er niet veel over vinden op internet.

[Verwijderd]

Wat is de stripesize, wat is de offset, welk FS gebruik je, welke partitie-parameters, zijn die IOmeter scores voor read of write?

Ik vermoed dat je random I/O performance begrenst wordt doordat een enkele I/O requests meerdere disks beslaat, en dat kan komen door:
- te kleine stripesize
- misalignment
- filesystem ("partitionering") parameters

Trouwens.. performantie, is dat serieus een Nederlands woord?

[ Voor 4% gewijzigd door Verwijderd op 23-01-2007 16:29 ]

[lier]

Heb je die RAID 5 verdeeld over 6 disks ?

Ik kan me voorstellen dat bij voldoende disks de writetime enorm laag is, omdat de data over 5 disks wordt geschreven (+ parity op 1 disk).

[Verwijderd]

lier schreef op dinsdag 23 januari 2007 @ 16:33:
Ik kan me voorstellen dat bij voldoende disks de writetime enorm laag is, omdat de data over 5 disks wordt geschreven (+ parity op 1 disk).

Random I/O behoort normaal gesproken maar op 1 disk neer te komen. Dat biedt ook de meeste performance verbetering. Op die manier kun je met 5 disks (excl. parity) dus 5 read-operaties uitvoeren; tegelijkertijd. Dat is het parallellisatie-voordeel van RAID. Gebeurt een I/O request op alle schijven (b.v. door een te lage stripesize) is het hele effect weg en heb je vrijwel geen snelheidsvoordeel.

[Profidiam]

@Bierkameel: Ik weet ook neit hoe die controller werkt, maar vind het nu ook niet bepaald een budget controller...

@Enlightenment: Stripe size: 64kB en er is een NTFS bestandssysteem gebruikt. de IOPS scores zijn gecombineerde scores, dus read+write. Ik weet niet wat je bedoeld met 'offset' en misalignment, dus dat ga ik nu uitzoeken.

@lier: Inderdaad, raid 5 set, verdeeld over 6 disks

De volledige scores:

code:

Nieuwe server:
       IOPS IOPSR   IOPW
 8  245 194 51
 4  228 182 46
 2  239 191 48
 1  208 166 43
Oude server:
 8  347 277 69 
 4  311 249 62
 2  248 198 50
 1  165 131 34

[Verwijderd]

Dan denk ik dat je de stripesize eens op 128KB of nog beter: 256KB moet instellen en nog eens moet benchen, ik vermoed dat je dan een veel hogere score krijgt, zie hier mijn bevindingen:

code:

Single drive (ad8)
concurrency     Performance in I/O's per sec.   average
1               106     106     107             106
4               106     106     106             106
16              116     116     116             116
32              127     125     126             126
128             151     151     150             150
256             156     156     157             156

gstripe 4xad - 128KB stripe - FM off - zero offset
concurrency     Performance in I/O's per sec.   average
1               173     173     173             173
4               270     270     270             270
16              338     338     338             338
32              370     370     370             370
128             444     434     434             437
256             465     465     465             465

gstripe 4xad - 16KB stripe - FM off - zero offset
concurrency     results (3 times)               average
1               129     129     129             129
4               151     150     151             150
16              173     173     172             172
32              188     188     190             188
128             222     222     222             222
256             232     229     229             230

Zoals je ziet vernielt een te lage stripesize je random I/O performance aanzienlijk.

[Profidiam]

Ok, ik ben er achter wat die offset betekent, maar ik vermoed dat ik daar met mijn NTFS bestandssysteem niets kan aan beïnvloeden? Kan je je ntfs bestandssysteem alignen met je stripe blocks op een of andere manier?

Heb dit ondertussen gevonden: http://technet.microsoft....36-9cb4-2bd8e98806e7.aspx

Dan align ik op "256" zodat mijn fs blokken overeenkomen met mijn fysieke blokken op disk en formatteer ik met een cluster size van 64KB ?


Ok, ik zal een kopie nemen van de data en dit weekend de array opnieuw maken. Met een zo groot mogelijke strip size (256KB)

offtopic:
Je voorbeeld werkt verhelderend en volgens Van Dale is performantie geen serieus Nederlands woord... Vreemd, performant bestaat wel.

[ Voor 39% gewijzigd door Profidiam op 23-01-2007 17:08 . Reden: offtopic toegevoegd ]

[Profidiam]

Even voor de volledigheid vermelden dat het probleem nu opgelost is en de performantie is zoals verwacht, maar met de cache op de controller uit, blijkbaar is de queueing methode van die controller niet zo best.

[Verwijderd]

Kan zijn idd dat jouw controller niet zo goed schaalt met multiple concurrency. Areca is daar bijvoorbeeld sterk in, en andere controllers ook. Niet iedere RAID implementatie is even "slim" zoals ik dat noem. Maargoed haal je nu wel betere scores dan voorheen?

[Profidiam]

ja, vooral bij grotere queues/concurrency... Je ziet duidelijk dat er dan een verbetering is.

8 370
4 350
2 270
1 145

dit zijn scores voor een werkende server, dus met een korrel zout te nemen. Ik ben dus tevreden.