[RAID] Nieuwe schijven maar matige performance

[Verwijderd]

Server setup
Mobo: Tyan thunder 8kse
CPU: 2 X AMD opteron 270 dual core's, 64-bit
Geheugen: 6GB Kingston DDR PC3200, CL3, ECC
Raid controller: LSI megaraid 320-2x met battery pack en 256 MB DIMM cache
PSU: Zippy 650 watt triple redundant
HDD's: 8 X gloednieuwe seagate cheetah 15k.5, U320, SCA, 73GB, 16mb cache
Backplane: Chenbro U320 SCSI met 2 channels, ieder 4 SCA poorten.

Tot mijn grote verbazing vallen de benchmarks nogal tegen. Het is een high-end server en er valt veel meer uit te halen qua performance.
Ik heb een aantal benchmarks zowel in linux (hdparm) als in windows xp gedraaid (hdtune, sisoft sandra), met verschillende raid setups. Het vreemde is dat de geteste raid levels ongeveer voor dezelfde performance zorgen, buffered reads in hdparm ligt altijd rond de 175 mb/sec. De geteste raid levels zijn raid 0, raid 1, raid 5 en raid 10 met 8 hdd's. Wat ook vreemd is dat write back even snel is als write through....
Wat kan de oorzaak zijn van de slechte performance? Slechte kabels of misschien een slecht functionerende backplane?

HDtune screenshot, getest in windows XP, raid 10 met 8 hdd's.

[Verwijderd]

Laat eens wat meer resultaten zien, IOmeter en filesystem benchmarks. SCSI schijven zijn natuurlijk gemaakt voor multiconcurrency dus met een queue depth van 1 zul je geen records breken met je setup.

[Verwijderd]

Zal ik doen, welke benchprogramma's raad je aan? Ik heb even voor het gemak windows server 2003 geinstalleerd.

[Verwijderd]

IOmeter bijvoorbeeld, maar h2benchw zou ook kunnen. En anders sisoftware sandra of zelf eens testen met kopieeracties etc. (vanaf een ramdisk naar/van je RAID volume zou ook kunnen).

[Verwijderd]

Ik heb IOmeter geinstalleerd.
Met welke queue depth en read/write ratio kan ik het beste testen? De server host een zeer grote Vbulletin forum met mysql database. De beste read/write ratio om te testen zal dan rond de 65/35 zijn toch?

[ Voor 3% gewijzigd door Verwijderd op 12-08-2007 17:52 ]

[maratropa]

Zet je cache policy eens op normal read ahead, direct IO en write through. En test dan eens met ATTO.
Dat zegt helemaal niks over de performance in het echt maar je kan er ideaal je maximale doorvoer mee meten. Je kan er bijvoorbeeld mee zien of er ergens een "cap" zit.

In raid 0 moet die 320-2x toch zeker boven de 200 kunnen komen. M'n 320-2E doet met 2 schijven al 180mb...

[Verwijderd]

Ik heb een paar basic benchmarks gedraaid.

Policies: normal read ahead, direct IO
Stripesize 128kb
Raid 10
8 X seagate cheetah 15k.5, U320, 73GB

ATTO:
write back


write through


Hoe kan ik de total length en queue depth voor ATTO eigenlijk het beste instellen?

Sisoft sandra physical disks
write back


write through


Sisoft sandra filesystem
write back


write through


Het is niet bepaald indrukwekkend he... Met de snelste scsi schijven, en een snelle raid controller toch zulke magere resultaten behalen.

[ Voor 43% gewijzigd door Verwijderd op 12-08-2007 22:19 ]

[Hardware Junk]

maratropa schreef op zondag 12 augustus 2007 @ 17:55:
...
M'n 320-2E doet met 2 schijven al 180mb...

Om met 3 schijven een piek te krijgen en met 8x 15K schijven in Raid 0 onder de 100MB/s te eindigen in HDtach.......

[Verwijderd]

queue depth 10 ofzo, read/write op 100% / 0% en dan andersom, 100% sequentieel. Dan test je de echte sequentiele snelheid (STR). Daarna kun je ingewikkeldere benches doen, femme of balusc had ook nog wat IOmeter definities geloof ik. In het RAID benchmarktopic staat hier meer info over. Je kunt in het eerste tabblad een limiet voor het de grootte van je testbestand instellen, dat kun je doen op 10GB ofzo. Je moet het in sectoren invullen dus:

aantal bytes / 512 = aantal sectors

@maratropa: 2 schijven die 180MB/s doen is 90MB/s per schijf, dat halen enkel de nieuwe F1 schijven of SAS schijven, ik denk dat je geen zuivere benchmark hebt gedraaid maar dat je uitkomst kunstmatig is geweest.

[Verwijderd]

Oeps ik had beter eerst f5 kunnen drukken.
Maar even reagerend op de benches van van 3maal6: atto is geen betrouwbare benchmark voor een controller met buffercache. Sandra zie je een hogere write-through performance, dat komt waarschijnlijk doordat sandra geen rustpauze inlast en dus een benchmark begint terwijl je RAID-controller nog data aan het wegschrijven is van de vorige benchmark run.

Ik raad je aan om IOmeter te proberen, dat is echt een uitstekende benchmarksuite, die helaas iets ingewikkelder is als "druk op deze knop om te beginnen" maar de resultaten die je krijgt wel kloppen. Je kunt een sequentiele benchmark per keer draaien, of je kunt een cooldown periode inlassen tussen de benchmarks. Zo voorkom je 'contaminatie' van je resultaten als je je write-back buffercache hebt ingeschakeld. Zorg dat je minimaal met 10GB test voor betrouwbare resultaten.

[maratropa]

Nouja 180 of ergens in de buurt, iig 2 MAU's zijn best snel... Maar dat boeit verder ook niet m'n punt was dat je in princiepe met zo veel schijven met raid 0 oid wel meer zou moeten kunnen krijgen dan wat ie nu heeft...sequentieel heb ik het dan over. Wat me verder ook niet zo veel kan schelen omdat het verder ook niet zo veel zegt.

Ik zou ook even die IOmeter testen doen die balusc in het IOmeter topic geeft, dan kun je een beetje met de rest vergelijken.

oh oh en er staat ook 320-2x materiaal in de benchDB

http://tweakers.net/bench...20-2x&ColcomboID=&x=0&y=0

[ Voor 12% gewijzigd door maratropa op 13-08-2007 00:46 ]

[Verwijderd]

@ Enlightenment, bedankt voor de toelichting.

Ik heb IOmeter als volgt ingesteld:
Disk targets
- Maximum disk size: 20971520 sectors = 10GB
- # of outstanding I/O's: 10
- 4 workers (raid 10 = 4 X raid 1 spans, dus totaal 4 workers)

Access specifications
transfer request size: 32kb (of moet meer transfer request sizes toevoegen? tussen 512b en 128kb ofzo?)
100% sequential
testen met 100% read en 100% write

Test setup
run time: 1 minuut
ramp up time: 10 seconden
Number of workers to spawn automatically: # of cpus (4)
Cycling options: normal - run all selected targets for all workers

Bij cycling options kan ik kiezen tussen meerdere opties.


@ Maratropa, ik heb de workloads file van Femme gedownload. Daar ga ik straks mee aan de gang.

[Verwijderd]

Ik heb de afgelopen week een paar benchmarks gedraaid met IOmeter.
klik-> Benchmarks. Ik ben geen benchmark specialist, dus zou graag van jullie willen horen of het een beetje goed is.

Het valt mij op dat writeback voor een enorme IO en mb/sec boost zorgt bij kleine bestanden tot +/- 4kb. Bij grotere bestanden is er amper verschil.

[Verwijderd]

Niemand?

[Verwijderd]

Laatste bump... Enlightenment, maratropa?

[Madrox]

Verwijderd schreef op zondag 19 augustus 2007 @ 15:32:
Ik heb de afgelopen week een paar benchmarks gedraaid met IOmeter.
klik-> Benchmarks. Ik ben geen benchmark specialist, dus zou graag van jullie willen horen of het een beetje goed is.

Het valt mij op dat writeback voor een enorme IO en mb/sec boost zorgt bij kleine bestanden tot +/- 4kb. Bij grotere bestanden is er amper verschil.

Logisch, writeback gebruikt de cache van de harddisk hiervoor. Cache is niet zo groot (8 a 16MB), wat verklaart waarom vooral kleine bestanden hiervan profiteren (grote bestanden passen er niet in!).