Raid performance problemen

[pixel]

Ik ben bezig om mijn nieuwe pc te maken alleen loop ik tegen het volgende vreemde ding aan.
Eerst had ik een desktop systeem met een intel onboard raid controller en had daar twee WD 1200JD aan hagen in RAID 0. Werkte prima en snel, maar wou meer disk snelheid.
Nu heb ik een Intel SE7525GP2 syteem, met daarin een SATA WD36 (raptor 10K rpm) disk als op start disk en vier WD1200. (7200RPM 8mb cache). Deze vier hdd's zijn aangesloten op een LSI Logic MegaRAID 150-6 RAID controller. De controller zit een een PCI-X 64/66 slot.
Als ik nu met een disk benchmark util (hd tach 3) ga meten dan vallen de resultaten heel erg tegen.
De raptor haalt met burst read 104 mb/s en avarage 56 mb/s
De raid set haalt 87 Mb/s burst en avarage 48 Mb/s
Het maakt niet uit of en RAID 0,1,5 wordt gebruikt, de performance blijft gewoon ruk.
Nou had ik dus die RAID set gemaakt om snel ISO images te kunnen uitpakken. Met de Raptor disk duurt dat een 5 min voor 4,7 Gb. Met de RAID set duurt het 10min per procent uitpakken!!!! ofwel heeeeel lang!

Ik heb geen flauw idee waar ik het moet zoeken.
Alle firmwares zijn geupdate, laatste versie drivers, enz. Raid controller in andere sloten gezet, maar maakt geen verschil.
Heeft iemand een idee waar dit aan zou kunnen liggen?

Specs systeem:
-Intel SC5275 kast
-Intel SE7525GP2 bord
-2 maal Xeon 3,4 Ghz 800 Mhz 1 Mb cache
-2,5 Gb aan geheugen.
-Sb audigy.
-Linksys wlan kaart.
-LSI logic 150-6 RAID controller met 64 Mb cache
-1 maal Wd raptor 36Gb
-4 maal WD 120GB
-Floppy drive

[Femme]

De maximale sequentiële transfer rate die de LSI MegaRAID SATA 150-4 en 150-6 kunnen hebben is zo'n 120MB/s. Meer trekt de I/O processor niet. Met een STR van 56MB/s zit je daar nog ver onder.

Ik zou eerst eens een andere benchmark dan HDTach gaan gebruiken. Ik HDTach eens gebruikt op m'n MegaRAID SCSI 320-2X en toen kwam ie een idioot lage STR op de proppen terwijl STR volgens andere benchmarks veel hoger was. Probeer eens de Disk Inspection Test van Winbench 99 v2.0. Geen ATTO gebruiken want die test alleen maar de cachebandbreedte van je MegaRAID.

Dan is het nog de vraag welke cacheinstellingen je gebruikt. Mijn ervaring is dat de combinatie write-back cache, 128K stripe-size, normal read-ahead en direct I/O het beste presteert op de MegaRAID SATA 150-5/6. De write-back cache van de harde schijven kun je instellen via de textbased pre-boot setup die te bereiken is via ctrl-m tijdens het booten. De write-back cache van de controller kan zowel via ctrl-m als ctrl-h (grafische setup) ingesteld worden. Het gebruik van write-back cache zonder battery backup unit is minder veilig, maar in een hobbyomgeving hoeft dat niet zo'n probleem te zijn. De kans op gegevensverlies is erg klein als je pc gewoon stabiel is.

[Verwijderd]

pixel schreef op zondag 09 januari 2005 @ 16:20:
-Intel SE7525GP2 bord
-LSI logic 150-6 RAID controller met 64 Mb cache

Welkom bij de club. Dat is ook toevallig zeg...

Ik kan je (nog) niet vertellen waar het aan ligt. Wat ik je wel kan vertellen is dat het niet aan de SE7225GP2 board ligt en/of de andere componenten in je systeem. Dit weet ik nl. omdat ik een vergelijkbaar systeem hier heb staan en twee maanden problemen heb gehad, ook met een LSI SATA 150-6.

In eerste instantie zei LSI support dat de kaart defect zou zijn dus via de leverancier is deze terug gegaan en is er een nieuwe verstrekt. Helaas, exact de zelfde problemen (met nog wat meer problemen tussendoor omdat de BIOS versies P04 en P05 (voor de GP2) er voor zorgen dat het systeem tijdens POST na de LSI blijft hangen (maar dat is een ander verhaal). Uiteindelijk heb ik een 3Ware 9500-8 besteld, na een 8000 series 4-port uitgetest te hebben maar die werkte weer niet met de P03, P04, of P05 BIOS versies. Na overleg met de dealer besloten we de Intel SRCS16 controller te bestellen met de nadruk dat Intel garant stond dat het ook zou werken met de GP2. Voor deze SRCS16 was er nl. een firmware upgrade bij Intel (met het oog op de GP2). Deze SRCS16 is gewoon de LSI 150-6 maar met Intel firmware en iets aangepaste BIOS. Helaas gaf die controller ook de zelfde problemen als de originele LSI kaarten zelf.

Kortom, 2 maal een 150-6 en 1 maal de Intel versie van de 150-6, en het probleem was nog steeds het zelfde. Inmiddels was de P06 BIOS af en zaten er fixes in voor AMCC 3Ware controllers dus inmiddels draait mijn systeem met die controller op en top. De LSI is terug gegaan naar de leverancier om in te bouwen in een klein servertje welke in opbouw is (een Asus board, niets bijzonders vergeleken met de GP2). En wat denk je? De LSI controller laat daar exact de zelfde bagger performance zien!! Ik zit momenteel te wachten op wat LSI en de leverancier hier verder mee kunnen doen want het is wel erg raar.

Je kan er dus vanuit gaan dat de rest van je systeem niet echt van invloed is op de problemen die je merkt met de LSI controller. Wat je wel kan doen als test is het volgende; sluit 3 HD's aan op de LSI, gebruik hiervoor de porten 0, 2, en 4. Draai daar eens mee en ik denk dat je zult zien dat de performance is zoals te verwachten valt. Doe nu het zelfde met de andere porten, 1, 3, en 5. Als het goed is zul je bagger performance opmerken. Ook als je slechts een van die drie porten gebruikt met een disk kun je dat waarschijnlijk al zien. Dus, als je op de porten een set HD's heb zitten gaat de RAID performance sterk naar beneden (zelfs onder het nivo van de throughput van een single IDE diskje) omdat het systeem zich zal gedragen op basis van de trage HD. Als je deze test kunt doen kun je ook beter aantonen dat het gedrag van de LSI niet is wat je mag verwachten, alle porten zouden toch een gelijke performance (goed *of* slecht) moeten laten zien, dus waarom dat verschil? Precies.

Tevens sluit ik me aan bij wat Femme net schrijft over de cache instellingen maar zelfs met elke combinatie van cache/read-ahead/etc. is het duidelijk dat er met die 150-6 controllers iets aan de hand is wat kennelijk nog niet door LSI toegegeven wordt (maar wel bekend is, inmiddels). Twee maanden hebben we de GP2 de schuld gegeven van het probleem maar nu blijkt dus dat het toch iets erg specifieks is met die LSI.

[Femme]

Opmerkelijk dat de SRCU16L en de MegaRAID SATA 150-4/6 zoveel problemen geven op het Intel-bord. Ik heeft bij mij altijd probleemloos gewerkt op AMD 760MPX en AMD-8000 chipsets.

Wat versta je onder baggerperformance? Is het systeem ook daadwerkelijk traag of baseer je je bevindingen alleen op de testresultaten van discutabele benchmarks zoals HDTach? De MegaRAID SATA 150-6 is een middelmatige performer tussen nieuwkomers zoals de RAID-adapters van Areca en RAIDCore, maar hij zou zeker niet verschrikkelijk traag moeten zijn. In RAID 5 moet je er altijd nog meer uit kunnen halen dan de prestaties van één Raptor WD740GD en die is niet echt traag te noemen.

[Verwijderd]

Femme schreef op maandag 10 januari 2005 @ 17:35:
Wat versta je onder baggerperformance? Is het systeem ook daadwerkelijk traag of baseer je je bevindingen alleen op de testresultaten van discutabele benchmarks zoals HDTach?

Het is ook opmerkelijk. Over de afgelopen 15 jaar heb ik eigenlijk altijd goede ervaringen gehad met controllers + Intel mobo's (alhoewel dat wel SCSI was en niet SATA) terwijl het de laatste maanden er op lijkt dat zelfs eigen Intel componenten niet zo lekker met elkaar willen werken. Nu blijkt dat de P06 BIOS voor het GP2 board de problemen met 3Ware controllers heeft gefixed maar dat nu een Intel SCSI controller niet meer werkt met die BIOS (die controller is ook een OEM van LSI overgens).

Met baggerperformance bedoel ik in het algemeen dat de performance ver onder het nivo ligt van wat je mag verwachten (gemiddeld minder performance dan een IDE disk of net iets meer dan een single IDE disk), ook in RAID0. Benchmarks gebruik ik alleen om verschil te kunnen zien tussen settings en configuraties (een relatief verschil) omdat ze toch geen echte harde getallen geven. Maar ik denk dat ik je beter een voorbeeld kan geven;

3 raptors op porten 0, 2, 3 en de performance is wat je mag verwachten (laten we dat even x noemen). Nemen we nu de zelfde raptors op de andere drie porten en de performance (het verschil) is ruim x/5 (gemiddeld). Het hangt sterk af van wat er gebeurd maar in sommige gevallen is het ruim x/8. Acht maal trager op de zelfde controller. Dus met meer dan 3 raptors op die LSI 150-6 vervalt de hele array naar de snelheid van de traagste disk (traagste port in dit geval). Waar het goed mee te merken is zijn file copies. Tijdens een copy (van bijvoorbeeld IDE naar RAID0 array) blijkt dat de IDE het sneller kan lezen dan de array het kan schrijven (wat vreemd is voor 4 raptors op een LSI 150-6). Tijdens de file copy (zeg, een file van 1GB) van +/- 3 minuten (IDE naar RAID0) zie je ook dat er delays ontstaan waarbij de copy blijft hangen voordat hij vrolijk verder gaat (alle combinaties van settings/cache hebben wel effect maar die delays blijven voorkomen).

Als ik in de Performance Monitor kijk naar avg. disk queue length, etc. is er ook een vreemd pulse patroon te zien waarbij de queue inzakt en weer opkomt tijdens dergelijke delays (welke dus voorkomen op 3 van de 6 porten). Vreemd is dat ik dat niet zie op de 3Ware, het ook niet eerder heb gezien op simpele RAID0 SATA controllers (zoals Promise en Highpoint), en bij de SCSI controllers (Adaptec's) heb ik dat ook nog nooit gezien. Het zijn voor zover ik kan zien ook die delays en dat constante 'start en stop' gedrag van al het IO op die 3 porten wat voor een bizar slechte performance zorgt. Zeker als je verwacht (zoals je mag verwachten) dat alle porten op de controller de zelfde performance geven.

Ik heb alle tests ook nog eens gedaan met extra HD's, dus een setup van een RAID0 met 2 x SATA en RAID0 met 4 x Raptors en afhankelijk van de indeling van de HD's op de porten is meteen te zien dat er geen uniformele performance over de gehele controller te ontdekken is.

Pixel heeft het over 10 minuten per procent van een unpack en dergelijk gedrag heb ik inderdaad ook van de LSI 150-6 en SRCS16 gezien. Zodra er een lading IO ops via de controller loopt (read's voor de archive en writes voor de files) dan gaat de algehele performance nog meer achteruit (x/20 of meer). Wat hierbij vooral te merken valt is dat de *write* performance het meeste hinder heeft van wat het ook is dat dit veroorzaakt.

Een andere indicatie die ik had om te merken dat de performance sub-standaard was is 1 Raptor onboard = performance x, 1 Raptor op een van de "trage porten" op de LSI = x/3. Single disk, single RAID0. Dat is per definitie raar want je verwacht die zelfde performance x te halen in zo'n situatie en niet een heel stuk minder. Met alle cache settings optimaal (met of zonder BBU) is er wel een verbetering te zien maar nog steeds niet de performance x van de "bare disk" zelf.

Een andere indicator is algehele write performance (ook weer alleen op 3 van de 6 porten). Via het 1GB switched netwerk hier haal ik meestal een stabiele stream van +/- 35MB/s (uitschieters naar 40MB/s en gemiddelde van 30MB/s). Op het moment dat data over het netwerk naar de LSi controller gaan zakt dat gemiddelde naar 11-14MB/s wat ook ongewoon is (vergeleken met alle andere machines in het zelfde netwerk). Duidelijk is hierbij ook te zien hoe de TCP/IP stream spontaan stopt en na 2-4 seconden weer verder gaat, dit compleet synchroon met de vreemde IO patronen van de disk queue.

Nu het dus ook voorkomt met de zelfde LSI/Intel controllers op een Asus board begin ik dus echt te vermoeden dat er meer aan de hand is wat niet zo makkelijk op te sporen is.

Pfew... lang verhaal. Maar in het kort; wat ik bagger performance noem is dus een file copy van 1GB naar 4 raptors die er 3 minuten of langer over moet doen op een RAID0. :-)

[pixel]

Ik ben blij dat ik dus niet gek ben ofzo, begon al aan mezelf te twijvelen.
Toen ik de LSI erin zette werkte deze inderdaad niet goed. Ik heb hem eerst moeten update in een andere pc naar firmware versie 713N.
Maar STD wat ik nu niet zo goed begrijp: heb jij nu wel een goede performance met de 3ware?
Als ik vanaaf thuis ben zal ik even de schreenshots posten die ik heb gemaakt met HD-tach.

Op het moment draai ik RAID 0 met de onboard controller. Ik heb daar nu twee Raptors 74Gb op aangesloten. Dit werkt best wel rap! haal burst speed van 150 mb/s en avarage van 105 Mb/s. Dit soort getallen had ik dus ook minimaal verwacht van de vier 120GB in stripe.

ik zal vandaag eens contact opnemen met LSI. de meer mensen klagen des te sneller de oplossing komt

[Verwijderd]

pixel schreef op dinsdag 11 januari 2005 @ 13:25:
Maar STD wat ik nu niet zo goed begrijp: heb jij nu wel een goede performance met de 3ware?

Yep, de performance van de GP2 met de 3ware 9500-8 is acceptabel (geen super performance vergeleken met b.v. een Broadcom) maar ik heb wel het e.e.a. moeten tweaken met de cache settings (en gebruik moeten maken van 2 registry hacks die via 3ware support online stonden). Vanwege de cache (en de 128MB op de controller) geven benchmarks geen normale resultaten meer maar het verschil met de LSI controller is als dag en nacht. Een andere leuke feature van de 3ware is de pin headers voor LED's (voor elke port een aansluiting)... altijd leuk als kerstverlichting.

Als je contact op gaat nemen met LSI support europe kun je ze altijd verwijzen naar een case die geopend is op Mon 10/25/2004 (van Stefan via e-mail naar [e-mail]). Daarin had ik ze ook al de info gegeven over de vreemde performance verschillen op de porten van de controller. Ik had al binnen een uur of twee een reactie. Alleen het vermoeden van LSI dat de controller defect was bleek achteraf dus niet juist te zijn (de 2e LSI controller vertoonde het zelfde en de SRCS16 van Intel ook). Ik denk dat ik zelf ook nog een keer contact ga opnemen met LSI alhoewel mijn leverancier ook met ze bezig is nu het zelfde probleem zich voordoet op een compleet ander mobo.

Het performance verschil tussen die porten is echt het meest opmerkelijke omdat je eigenlijk zou verwachten dat ze of allemaal traag zijn of allemaal normaal werken.

[pixel]

Ik had dus op de 3ware hetzelfde probleem. Ook super traag.
Wel iets beter dan de LSI maar niet zoals het zou moeten zijn. Nog steeds ging het uitpakken van een ISO rete traag. Ik had trouwnes de 64Mb versies van de 3ware.

[Verwijderd]

Met 64MB op de 3ware klinkt het als een 8000 of 7000 series controller wat net weer anders is dan de 9000 series. Ik denk dat daar dus nogal wat verschil tussen kan zitten.

Edit: En oh ja, niet te vergeten, BIOS P06... anders werkt die 9000 series niet (met P05 werkte een 8000 hier wel).

[ Voor 26% gewijzigd door Verwijderd op 11-01-2005 15:50 ]