Hoeveel CPU-belasting in RAID 5 ?

[Verwijderd]

Ik als net een artikel over het feit dat RAID 5 belastend zou zijn voor je CPU, omdat de CPU constant aan het wegschrijven zou zijn.

Ok, nu wil ik graag weten hoe nadelig het voor mij is als ik een Intel 2 Duo E6600 in mijn systeem heb??

-----------------------

Is RAID 5 (met 3 HD's) zo belastend voor mijn CPU... en dus ook de snelheid van het systeem, dat ik beter een RAID 0+1 (4 HD's) kan opstellen?

[Monkii0110]

Software raid (via je onboard controller) is altijd heel erg cpu belastend.
In ieder geval dat is mijn ervaring.

Raid 5 is sneller dacht ik dan Raid 1+0 en je hebt meer GB's.

Als je echt Raid 5 wil, dan zou ik een raid kaartje kopen

[Verwijderd]

Wat voor Raid controller is de grote vraag. Onboard zal je wel merken jah, als je een mooie Smart Array Controller van HP koopt met wat sas diskjes merkt je cpu er niks van, dat regelt de controller dan.

[frankknopers]

Gewone CPU's zijn niet gemaakt voor pariteitsberekeningen die bij RAID5 horen. Dat geeft dus een vrij hoge CPU load als je softwarebased raid draait. Het kan zo 30% CPU tijd kosten en ook zijn de snelheden in software raid niet hoog.

Bij hardwarematige raid heb je een speciale processor op een insteekkaart die speciaal voor pariteitsberekeningen is gemaakt. Dat is veel sneller, maar ook erg duur.

Als ik jou zo hoor heb je meer aan een raid 1 of een raid 0+1

[Guardian Angel]

Nog meer RAID FAQ

Ik zie dat je al meerdere topics heb lopen die allemaal over een nieuw systeem gaan. Ook deze RAID-vraag stelde je daar eerder. Het lijkt me, mede gezien de sluitingen van vrijwel al je postings, handig als je zelf ook eens op onderzoek uitgaat.

[ Voor 76% gewijzigd door Guardian Angel op 17-05-2007 19:55 ]

[roger1234]

Ik heb hier een highpoint 2320 met 6 x 400gb seagate sata2 schijven in raid5 nu en deze snoept zo'n 5 tot 10% van mijn cpu als ik er wat naar wegschrijf.
Als ik met meerdere threads tegelijk naar de array wegschrijf kan het cpu gebruik oplopen tot zo'n 90%, de cpu die ik gebruik is een x2 4200+.
Zoals Bart-Man al aangeeft is het afhankelijk van de controller die je gebruikt als je namelijk een controller gebruikt die zijn eigen IO cpu heeft dan zal je bijna geen cpu load hebben.
Nadeel van deze controllers is, dat ze aardig geprijsd zijn.

[Verwijderd]

Verwijderd schreef op donderdag 17 mei 2007 @ 19:39:
Ik als net een artikel over het feit dat RAID 5 belastend zou zijn voor je CPU, omdat de CPU constant aan het wegschrijven zou zijn.

Elk storage level geeft overhead, ook op kale disks. Hoe meer 'lagen' je softwarematig aanbrengt des te meer CPU verbruik. Maar je moet het niet overdrijven; RAID0 en RAID1 bijvoorbeeld zijn erg simpele RAID-levels die weinig van je CPU zullen vragen (0,5% bijvoorbeeld). RAID5 is een ander verhaal; bij het schrijven kan deze erg veel CPU vragen sterk afhankelijk van welke implementatie van RAID5 je gebruikt. Onboard en Windows RAID5 kent hierbij een belabberde performance en is vaak ook niet erg betrouwbaar.

Is RAID 5 (met 3 HD's) zo belastend voor mijn CPU... en dus ook de snelheid van het systeem, dat ik beter een RAID 0+1 (4 HD's) kan opstellen?

Ligt eraan wat je ermee gaat doen, ik zou geen onboard RAID5 als systeemschijf gebruiken, gebruik je het om je MP3tjes te streamen dan is dat prima te doen.

ThaPizza schreef op donderdag 17 mei 2007 @ 19:44:
Software raid (via je onboard controller) is altijd heel erg cpu belastend.

Dat is ook maar relatief, met schone drivers ben je waarschijnlijk meer CPU cycles kwijt aan de interrupts van je controller dan aan de RAID-driver zelf; onder de 1% dus.

Raid 5 is sneller dacht ik dan Raid 1+0 en je hebt meer GB's.

Qua schrijven helaas in de praktijk vaak erg traag, tenzij je voor een Linux / UNIX oplossing gaat die kunnen wel heel snel schrijven.

frankknopers schreef op donderdag 17 mei 2007 @ 19:49:
Gewone CPU's zijn niet gemaakt voor pariteitsberekeningen die bij RAID5 horen. Dat geeft dus een vrij hoge CPU load als je softwarebased raid draait. Het kan zo 30% CPU tijd kosten en ook zijn de snelheden in software raid niet hoog.

Nu generaliseer je aangezien je het duidelijk over Windows-based oplossingen hebt. Ook software RAID5 kan 400MB/s write halen. In feite is je CPU vele malen sterker dan de CPU op een Areca. Een moderne CPU kan met gemak 3000MB/s aan XOR-berekeningen halen, dus daar mag het niet aan liggen. Het meest cpu-vretend onderdeel bij RAID5 software zijn geheugentransfers; splits en combines en het samenvoegen van blocks, niet de XOR operatie zelf.

[frankknopers]

Verwijderd schreef op vrijdag 25 mei 2007 @ 11:23:

[...]

Nu generaliseer je aangezien je het duidelijk over Windows-based oplossingen hebt. Ook software RAID5 kan 400MB/s write halen. In feite is je CPU vele malen sterker dan de CPU op een Areca. Een moderne CPU kan met gemak 3000MB/s aan XOR-berekeningen halen, dus daar mag het niet aan liggen. Het meest cpu-vretend onderdeel bij RAID5 software zijn geheugentransfers; splits en combines en het samenvoegen van blocks, niet de XOR operatie zelf.

Dus onder Linux (ubuntu 7.04 bijvoorbeeld)kun je wél een hele snelle software RAID5 bouwen? Dat is dan misschien nog wel goedkoper dan een speciale raidcontroller. Gewoon een moederbord met veel sata poorten, een leuke Athlon X2 CPU en iets van 2GB ram..

[Verwijderd]

frankknopers schreef op vrijdag 25 mei 2007 @ 14:04:
[...]

Dus onder Linux (ubuntu 7.04 bijvoorbeeld)kun je wél een hele snelle software RAID5 bouwen? Dat is dan misschien nog wel goedkoper dan een speciale raidcontroller. Gewoon een moederbord met veel sata poorten, een leuke Athlon X2 CPU en iets van 2GB ram..

Met name geom_raid5 onder FreeBSD met de juiste hardware is het mogelijk om zeer snelle sequentiele schrijfsnelheden te krijgen. Daarvoor is nodig:

• Een moderne versie van geom_raid5, genaamd TNG.
• Een snelle processor zoals Core2Duo or Athlon 64 X2
• 6 of 8 hardeschijven
• Voldoende geaggregeerde bus-bandbreedte (dus niet dat 4 schijven aan PCI hangen)

Dan zou je 400MB/s write moeten kunnen halen tegen een CPU belasting van 55%. Daarmee verslaat geom_raid5 Areca met eenzelfde configuratie, alhoewel daarbij wel de nodige kanttekeningen geplaatst moeten worden. Voor niet-sequentiele I/O maakt Areca bijvoorbeeld gehakt van geom_raid5. Maar voor opslag van grote bestanden is geom_raid5 ideaal, met een theoretisch hogere veiligheid dan een Areca zonder BBU.

[Stropdas]

Verwijderd schreef op vrijdag 25 mei 2007 @ 11:23:
[...]

Elk storage level geeft overhead, ook op kale disks. Hoe meer 'lagen' je softwarematig aanbrengt des te meer CPU verbruik. Maar je moet het niet overdrijven; RAID0 en RAID1 bijvoorbeeld zijn erg simpele RAID-levels die weinig van je CPU zullen vragen (0,5% bijvoorbeeld). RAID5 is een ander verhaal; bij het schrijven kan deze erg veel CPU vragen sterk afhankelijk van welke implementatie van RAID5 je gebruikt. Onboard en Windows RAID5 kent hierbij een belabberde performance en is vaak ook niet erg betrouwbaar.

On-board Intel ICH8R Southbridge 6-port RAID controller

http://blogs.zdnet.com/Ou/?p=484

De snelheid van schrijven naar RAID5 bij deze onboard chipset vind ik niet belabberd. Er is hoge CPUbelasting wat volgens die gast nauwelijks voorkomt bij gewoon werken met de schijven. In mijn ervaring met werken is CPU eigenlijk altijd uit z'n neus aan het vreten als de schijf aan het ratelen is dus in mijn geval zou dat niet eens erg zijn dat de ongebruikte kloktikken voor RAID5 gebruikt zouden worden. Ik zou t persoonlijk geen belabberde performance noemen dus. Dit alles wel aannemende dat je werkt met grotere bestanden. In dat artikel staat ook een test over de snelheid van verschillende configuraties met bestanden van 32KB, daar is het wel stuk langzamer dan de rest. Voor opstartschijf kan ik me voorstellen dat het niet lekker kan werken met al die kleine bestandjes maar voor gebruik als opslag en videobewerking etc. zou ik niet weten waarom het slecht zou zijn

[Mentox]

Ik heb zelf een Intel P965 chipset en een E6600 met 6 Seagate 320GB S-ATA schijven.

Met RAID5 kwam ik niet hoger dan 55MB per sec. De CPU belasting was ongeveer 12%.

Dit was met drie schijven maar omdat dit gewoon te traag was om lekker mee te werken heb ik een extra schijf gekocht.

Deze draaid in RAID10 en ik haal er 145MB per sec mee. De CPU belasting is rond de 3%.

Als je dus een 4e schijf kan permiteren dan zou ik voor RAID10 gaan. Mocht je een goede controller hebben dan zal RAID5 waarschijnlijk voldoen.

[maratropa]

En als je raid 10 gaat draaien dan zou je ook raid 0 kunnen gaan draaien met 2 schijven, en met 2 andere de backup verzorgen. Als je het backuppen goed doet dan is dat veiliger dan raid..

[Mentox]

maratropa schreef op zaterdag 16 juni 2007 @ 11:09:
En als je raid 10 gaat draaien dan zou je ook raid 0 kunnen gaan draaien met 2 schijven, en met 2 andere de backup verzorgen. Als je het backuppen goed doet dan is dat veiliger dan raid..

Dit was de oplossing die ik eerst had. De reden dat ik voor RAID10 ben gegaan is dat wanneer een schijf uitvalt ik gewoon nog kan doorwerken. Met RIAD0 zul je moeten wachten totdat je een nieuwe HDD hebt of tijdelijk op 1 HDD draaien.

[Verwijderd]

Stropdas schreef op vrijdag 15 juni 2007 @ 19:47:
De snelheid van schrijven naar RAID5 bij deze onboard chipset vind ik niet belabberd.

Als de resultaten kloppen, inderdaad. Maar ik heb wat twijfels. Zo heb ik de RAID5 write scores nog niet ergens gezien zoals hij ze voorstelt, is het voor mij onduidelijk waar die "640KB" precies op slaat, is het voor mij onbegrijpelijk waarom een RAID1 array sneller kan schrijven dan een enkele schijf en vind ik het artikel een onbetrouwbare uitstraling hebben door o.a. het gebrek aan normalisatie bij CPU gebruik. Dat doet mij vermoeden dat er nog meer mis is aan zijn testmethode. Dus op grond van alleen dit artikel raak ik niet overtuigd.

Maar theoretisch zijn de scores van RAID5 zeker mogelijk, zo is het met geom_raid5 (ook softwarematige RAID5) ook mogelijk om met 400MB/s te schrijven.

Er is hoge CPUbelasting wat volgens die gast nauwelijks voorkomt bij gewoon werken met de schijven.

Dat klopt.

In mijn ervaring met werken is CPU eigenlijk altijd uit z'n neus aan het vreten als de schijf aan het ratelen is dus in mijn geval zou dat niet eens erg zijn dat de ongebruikte kloktikken voor RAID5 gebruikt zouden worden.

Klopt ook helemaal. Alleen bij servers kan het anders liggen. En ook bij een NAS die ook veel CPU cycles nodig heeft om gigabit vol te krijgen.

[Femme]

In de praktijk hoef je voor een hoge cpu-belasting met moderne cpu's niet bang te zijn. Een cpu-belasting van 30 procent in een benchmark waar meer dan 200MB/s wordt verplaatst is niet iets waar je voor hoeft te vrezen. Het zal namelijk niet vaak voorkomen dat je voor lange tijd een doorvoer van 200MB/s hebt. Als je een netwerkcopy doet tegen bijv. 35MB/s zal de cpu-belasting veel minder zijn, met de bovengenoemde getallen zou je op ongeveer 5 procent uitkomen.

[Verwijderd]

Femme schreef op zaterdag 16 juni 2007 @ 17:08:
In de praktijk hoef je voor een hoge cpu-belasting met moderne cpu's niet bang te zijn. Een cpu-belasting van 30 procent in een benchmark waar meer dan 200MB/s wordt verplaatst is niet iets waar je voor hoeft te vrezen. Het zal namelijk niet vaak voorkomen dat je voor lange tijd een doorvoer van 200MB/s hebt. Als je een netwerkcopy doet tegen bijv. 35MB/s zal de cpu-belasting veel minder zijn

Dat hangt natuurlijk maar wel af wat voor storage backend je hebt. Gebruik je een softwarematige RAID5 implementatie die bij 120MB/s write tegen 100% cpu aanzit, en om gigabit te verzadigen zit je ook al rond de 70%, dan zul je dus met zo'n machine in een NAS-configuratie niet het maximale eruit halen; je CPU is dan bottleneck. Of dat erg is, is een tweede natuurlijk.

Voor desktopgebruik is het vaak anders, omdat gebruikers wachten tot de transfer klaar is. Dan liever 70% usage en dat het 2 minuten duurt, dan 30% en dat het 4 minuten duurt.

[Femme]

Ik uit van software RAID aangezien de vraag van de topicstarter daar betrekking op heeft. Voor hardware raid-oplossingen is cpu-gebruik geen issue.

De werkelijke cpu-belasting hangt natuurlijk af van vele factoren, zoals de specifieke raid-implementatie, de prestaties van de processor en de hoeveelheid data die weggeschreven wordt (lezen is niet zwaarbelastend met software raid 5). De HighPoint RocketRAID 1820A en de RAIDCore BC4852 zaten met een Opteron 240 (1,4GHz) op 29 procent per 100MB/s writes. De RocketRAID 2320 kwam met een Optero 248 2,2GHz op 19 procent per 100MB/s. Een moderne dualcore processor zal er helemaal geen moeite mee hebben. Je houdt nog genoeg cpu cycles over voor andere zaken zoals het afhandelen van verkeer van/naar de netwerkcontroller.

Software raid moet je dus niet laten staan vanwege de cpu-belasting. Er zijn andere redenen om voor duurdere intelligente raid-adapters te kiezen, bijvoorbeeld de veelal hogere robuustheid van deze oplossingen en de performancewinst van een grote cache. De voordelen die hiermee zijn te behalen lopen echter ook sterk uiteen per product.

[Verwijderd]

Is het niet zo dat RocketRAID (de 2300-serie iig) onder 'hardware assisted' valt en welliswaar de XOR-berekeningen aan de CPU overlaten maar zelf wel aan request combining doen? Dus wel een andere klasse dan zeg een Silicon Image SiI-3132 waarbij de RAID dus echt in de drivers uitgevoerd wordt en de chip niets meer is dan een IDE controller met metadata write en bootstrap support.

19 procent per 100MB/s write is in RAID5 natuurlijk fantastisch, de vraag is of je dat ook haalt met iets als ZFS (RAID-Z), iets als Windows software RAID5, nVidia MediaForce RAID5 of gvinum/geom_raid5. Laatstgenoemde weet een Sempron 2800+ gemakkelijk tot 100% te bewegen en een Athlon 64 X2 tot 65%. Dat komt dan vooral wegens de request combining zodat er geen leesrequests meer aan te pas komen bij het schrijven van data (1-phase writes).

Mijn ervaring is dat er maar weinig goede 100% softwarematige RAID5 implementaties zijn die de cijfers halen die jij noemt. geom_raid5 zal daarin nog de best presterende zijn, die ik heb getest dan iig. Maar ook daarbij kun je je singlecore CPU met gemak tot 100% bewegen en dualcore is weer bottleneck vanwege gebrek aan een goed threaded design waardoor dualcore niet de verwachte winst kan boeken. Conclusie in zo'n geval: CPU blijft bottleneck.

[Termi]

Andere kant denk ik ook, die processor moet toch wat doen Iedereen wil 0 % gebruik hebben, maar dat haal je toch nooit!

[NoepZor]

En bijvoorbeeld als je gaat gamen, dan lees je voornamelijk (lagere cpu load) en tijdens het gamen is het meeste al ingeladen dus besteedt je CPU minder tijd aan de raid. En de keren dat je wel met een flinke snelheid aan het wegschrijven bent zul je wel geen andere zware applicaties draaien.

[_JGC_]

Let wel dat de rest van je systeem staat te wachten op je CPU bij een schrijfactie, terwijl bij een normale hardware RAID-controler met BBU een schrijfcache aanwezig is. Je hebt dus niet alleen CPU belasting bij RAID-5, maar ook nog eens flink vertraging bij het schrijven van data.

[Verwijderd]

_JGC_ schreef op zondag 17 juni 2007 @ 14:23:
Je hebt dus niet alleen CPU belasting bij RAID-5, maar ook nog eens flink vertraging bij het schrijven van data.

Het aardige is nu juist dat vertraging bij schrijven geen bal uitmaakt, daarom hebben Areca controllers ook een buffercache; het maakt - qua performance - niet uit dat er vertraagd naar de schijven geschreven wordt. Het zijn de leesrequests die snel afgewerkt moeten worden, schrijfrequests kunnen wel even wachten.

Dus ik snap je argument niet zo?

[_JGC_]

Een areca is een fatsoenlijke controler met cache ja, maar software RAID of zo'n fakeraid controler heeft dat niet.

Edit:
Heb wel eens een MySQL server gedraaid met linux en software RAID. Argumentatie was zoiets als in "Dit is een quad opteron met een sloot geheugen, dan moet het kunnen". CPUs kwamen slechts aan een kwart van het maximale gebruik, hele systeem hing in de I/O wait en het hele ding presteerde waardeloos. Is uiteindelijk een hardware RAID controler ingekomen waarna alle problemen opgelost waren.

[ Voor 63% gewijzigd door _JGC_ op 18-06-2007 17:46 ]

[Verwijderd]

Je OS doet dit zelf al, FreeBSD gebruikt daarnaast SoftUpdates, waarbij schrijfopdrachten tot 30 seconden worden uitgesteld. geom_raid5 en ZFS gebruiken een RAM combine-buffer, van soms meer dan 100MB. Dus ja, ook software is hiertoe instaat.

fakeRAID en RAID5 is sowieso een slechte combinatie.

En wat betreft je verhaal: om welk RAID-level ging het hier? Indien het om RAID5 ging is dat vrij logisch. Sowieso is het niet ongebruikelijk dat databaseservers zijn gelimiteerd qua I/O ipv CPU. Zeker als het om grote databases gaat of als er veel mutaties plaatsvinden.

[ Voor 16% gewijzigd door Verwijderd op 18-06-2007 22:12 ]