Areca ARC-1120 slechte prestaties ?

[Thoughtless]

Ben al 2jaar in het bezit van een Areca ARC-1120 V2 met BBU.
Ben redelijk tevreden over de prestaties echter bij het checken met quickpar en het uitpakken van files ben ik erachter gekomen dat de prestaties naar mijn inzien te traag zijn.


Systeem configuratie
Mobo: ASUS M2N32 WS Professional
Proc: AMD Phenom X4 9750
Mem: 2x 2GB DDR2 OCZ
OS: Windows Vista Ultimate SP1

Disk configuratie Areca
4x Hitachi HDT721010SLA360 1TB Raid5

Controller instellingen Areca
HDD Read Ahead Cache: Enabled
Volume Data Read Ahead: Enabled
HDD SMART Status Polling: Enabled
Disk Write Cache Mode: Enabled
Volume Cache Mode: Write Back
Volume Stripe Size: 128KB
Tagged Command Queuing: Enabled

Disk configuratie Nvidia
2x Samsung Spinpoint 250GB Raid0

Wat heb ik al geprobeerd ?

Nieuwste firmware en bootrom
Firmware Version V1.46 2009-01-06
BOOT ROM Version V1.46 2009-01-06

Tests gedraait op de raid set
Uitpakken dvd5 op de areca +/-5minuten (4500MB / 300 = 15MB/s) 7 ~ 20% cpu belasting
Uitpakken dvd5 op de nvidia 1minuut en 5 seconde (4500MB / 65 = 69MB/s) 20 ~ 22% cpu belasting

Het viel mij op dat tijdens het uitpakken de areca wel eens door schoot met een paar procent, dus wanneer het gecached stond liep het wel snel, wanneer hij van disk moest lezen zakte de snelheid weer dramatisch in. Heb verschillende instellingen geprobeerd op de areca zoals het uitschakelen van de read cache. Dit heeft geen verschil gemaakt en de controller lijkt nog steeds even traag.

Mijn vraag is dus of iemand een oplossing weet voor dit probleem ? Kan mij namelijk niet voorstellen dat het zo traag hoort te gaan op zo'n controller

[maratropa]

Ja hallo logisch toch? Je belast 1 raid 5 volume, toch al geen ster in schrijfsnelheid, met een continue stroom lees en schrijf acties. (vanwaar pak je uit eigenlijk?)

Je heb je setup gewoon verkeerd in elkaar gezet zou ik denken. Die cache cached een stukje maar als ie vol zit en de data blijft komen zit je met de slechte raid 5 schrijf snelheid, wat NIET komt door de berkeningen, maar puur door het feit dat schijven niet 2 dingen tegelijk kunnen doen.

Splits je schijven in 2 raid 1 of 0 volumes, en zet het bron bestand op de 1 en het doel op de ander. Of zet ze met z'n 4en in raid 0 of 10 ofzo.

Iig, raid 5 is ruk als je het continu met schrijven belast.

[ Voor 10% gewijzigd door maratropa op 26-03-2009 12:38 ]

[Thoughtless]

Ik vind het alles behalve logisch eerlijk gezegd, aangezien quickparren gewoon bijna 5x zo lang duurt op de raid5 set als op de raid0 set, en hier spreken we volgens mij toch echt over alleen lezen tijdens het checken of de bestanden niet corrupt zijn.

Tijdens het uitpakken lees en schrijf ik naar de zelfde set, dus bron van raid5 doel naar raid5 maar zo test ik dus ook op bron van raid0 naar doel van raid0.


Nog een testje gedaan, van raid0 uitpakken naar raid5:

4500MB / 45sec = 100MB/s

Hoezo raid5 is traag in schrijven ? en volgens mij kun je dus echt wel van bron raid5 naar doel raid5 hogere prestaties verwachten.

[maratropa]

Thoughtless schreef op donderdag 26 maart 2009 @ 12:45:
Ik vind het alles behalve logisch eerlijk gezegd, aangezien quickparren gewoon bijna 5x zo lang duurt op de raid5 set als op de raid0 set, en hier spreken we volgens mij toch echt over alleen lezen tijdens het checken of de bestanden niet corrupt zijn.

Tijdens het uitpakken lees en schrijf ik naar de zelfde set, dus bron van raid5 doel naar raid5 maar zo test ik dus ook op bron van raid0 naar doel van raid0.


Nog een testje gedaan, van raid0 uitpakken naar raid5:

4500MB / 45sec = 100MB/s

Hoezo raid5 is traag in schrijven ? en volgens mij kun je dus echt wel van bron raid5 naar doel raid5 hogere prestaties verwachten.

Juist dan helemaaaaaal niet. Je moet even gaan lezen hoe raid 5 precies werkt, maar het komt er op neer dat als je bron en doel op de raid 5 set hebt staan, voor 1 "actie" er gelezen moet worden, en dan voor het schrijven er ook nog eens pariteit gelezen en geschreven moet worden. Aangezien schijven dit niet tegelijk kunnen zit je dus voor elke actie aan 2 reads en 2 writes vast. (ik weet niet zekeer of ik dit helemaal goed heb trouwens, maar iets in die richting. ) Voor raid 0 heb je maar 1 read en write.
De controller is er voor pariteits berekeningen, en caching. Caching helpt, maar tot de cache vol zit, zoals je gemerkt hebt.

Het kan nog steeds dat er wat mis is, ik weet niet hoe dit setje zou moeten presteren, maar een continue stroom data naar een raid 5 volume is relatief traag door het gebrek aan snelheid van een harde schijf. (Raptors of 15k schijven zouden je snelheid verbeteren bijv.) Als je dan ook nog eens lees acties gaat toevoegen zakt het helemaal in.

Maar zo te zien aan je laatste test licht het vooral aan het willen lezen van het volume waar je ook naar schrijft.. 100 mb lijkt me wel prima toch?

[ Voor 16% gewijzigd door maratropa op 26-03-2009 13:48 ]

[Thoughtless]

Ja 100MB/s is inderdaad genoeg , als ik deze snelheid ook +/- zou kunnen behalen bij het uitpakken van en naar dezelfde raid5 set.

Er is mij nog iets opgevallen dat als ik een willekeurige map met data kopieer, laten we zeggen een linux iso en deze kopieer naar een andere map op dezelfde raid5 set. Leest en schrijft hij met +/- 100MB/s dus een map is in 45sec gekopieerd.

[Demo]

Lees- en schrijfacties tegelijk is inderdaad niet bevorderlijk voor de snelheid van een RAID5-array, maar een ARC1120 zou qua pariteitsberekeningen toch wel zo'n 400 MB/s moeten kunnen verwerken. Je zou eens met een Linux-distro kunnen testen, hoe snel je een testbestand van random data weg kan schrijven (met dd if=/dev/urandom of=/array/test.bin bs=1M count=4096 schrijf je 4 GB aan onzin weg) dan ben je in ieder geval van de vertraging door die leesacties af.

[Thoughtless]

Dat zou ik eventueel kunnen proberen.
Maar wat me dan toch niet helemaal lekker zit is dat quickpar ook gewoon veelste traag gaat, en hier hebben we het over alleen lees acties toch

[dvl-2]

Ik kan me voorstellen dat je het traag vindt.

Heb zelf een ARC-1280 met daaraan 13 hitachi disks in raid6. DVD extracten op dat array gaat gewoon in 35sec. Je hebt gewoonweg teweinig disks aan je array om de snelheid te kunnen halen die jij wil (het zijn veel meer lees/schrijf bewerkingen, zie vorige posts). Ik heb jouw probleem ook gehad toen in nog 3 disks had en het extracten 'rent en stilstaat'. Dit is gewoon dat je disks de controller niet bijhouden. Meer disks eraan hangen is dus de oplossing wil je extracten van en naar dezelfde raid5 array

[ Voor 3% gewijzigd door dvl-2 op 27-03-2009 08:30 ]

[Thoughtless]

Ah oke dan wordt het binnenkort maar 4 disks bijplaatsen denk ik

[Demo]

Met 4 disken die zo'n 90 MB/s per stuk kunnen halen in RAID5, zou je toch echt wel 200 tot 250 MB/s moeten kunnen halen. Ik zie trouwens staan dat je writeback cache aan hebt staan, met een BBU zou je veilig writethrough moeten kunnen gebruiken. Dat zal voor schrijfacties al een redelijke boost geven

[maratropa]

Demoniac schreef op vrijdag 27 maart 2009 @ 10:19:
Met 4 disken die zo'n 90 MB/s per stuk kunnen halen in RAID5, zou je toch echt wel 200 tot 250 MB/s moeten kunnen halen. Ik zie trouwens staan dat je writeback cache aan hebt staan, met een BBU zou je veilig writethrough moeten kunnen gebruiken. Dat zal voor schrijfacties al een redelijke boost geven

juist andersom he, writeback is sneller dan writethrough

[dvl-2]

Demoniac schreef op vrijdag 27 maart 2009 @ 10:19:
Met 4 disken die zo'n 90 MB/s per stuk kunnen halen in RAID5, zou je toch echt wel 200 tot 250 MB/s moeten kunnen halen.

Met read of write only inderdaad wel maar met read en write tegelijk niet.

[kalizec]

Inderdaad, als je vanaf een array leest EN naar diezelfde array schrijft dan lijkt dat sterk op random read + random write. Test de boel eens door vanaf een andere set schijven de schrijven naar die RAID5-array en kijk of de performance dan wel Throughput * (N-1) benaderd.

[Thoughtless]

Ik zal maandag een aantal testjes draaien en in deze post verwerken.

[jordi5050]

Al resultaten van de tests die je kunt posten?