Raid5, Uittarren/formatteren duurt een eeuw ?

[CrankyGamerOG]

Geachte heren

SuperMicro 2U SuperServer 6025B-8R+ XEON SCSI
Intel(R) Xeon(R) 5130 @ 2Ghz
16 x 2GB Kingston DDR2 667Mhz ECC


Ik heb hier een Raid5 SCSI set draaien met 3x 500GB 10K SCSI
Deze staan in raid5 via een Supermicro AOC-LPZCR1
Er is nog een losse disk aanwezig die het systeem voor handen neemt
Als in

Disk 1 = OS

Disk 2 + 3 + 4 = Raid5 /Test

HDparm verteld me het volgende :

/dev/sdb1:
Timing cached reads: 11720 MB in 2.00 seconds = 5867.62 MB/sec
Timing buffered disk reads: 424 MB in 3.01 seconds = 140.85 MB/sec

Ondanks dit duur het uittarren van een 3gig tar roughly 7minuten
De CPU danwel load is bijna tot niks te noemen

Het formateren van de RAID5 partitie duurt bwz ook eeuwen, ok het is 3x500 in raid5, maar dan nog
ik heb het dan over ongeveer 3blocks per sec

Waar kan ik nog meer na kijken waarom het zo lang kan duren ?

[ Voor 9% gewijzigd door CrankyGamerOG op 13-09-2007 23:46 ]

[CyBeR]

Write cache? Dat maakt dingen veel sneller, maar staat op goede controllers (dunno of die supermicro daar onder valt) standaard uit omdat 't onveilig is tenzij er ook een batterij bij zit.

Als je echter die doos nog aan 't installeren bent kan 't weinig kwaad om 't even aan te zetten.

[ Voor 21% gewijzigd door CyBeR op 14-09-2007 00:07 ]

[CrankyGamerOG]

ok maar even afgezien van die write cache (die inderdaad uit staat)

Server 1

Intel(R) Xeon(R) 5130 Woodcrest @ 2Ghz
16 X 2 GB DDR2 667Mhz ECC
Supermicro LPZCR1 Hardware RAID5 3x 500GB SCSI 10K

hdparm :
Timing cached reads: 11720 MB in 2.00 seconds = 5867.62 MB/sec
Timing buffered disk reads: 424 MB in 3.01 seconds = 140.85 MB/sec

Versies:
Tar 1.15.1
Gzip 1.3.5
Kernel 2.6.18-ovz028stab035.1-smp

8,0 Min over 3GB Untar


Server2

Intel(R) Pentium(R) 4 CPU 3.00GHz
1GB ? DDR400 ?
Software Raid

hdparm :
Timing cached reads: 3428 MB in 2.00 seconds = 1713.53 MB/sec
Timing buffered disk reads: 144 MB in 3.01 seconds = 47.89 MB/sec

Versies :
Tar 1.15.1
Gzip 1.3.5
Kernel 2.6.18-ovz028stab035.1-smp


1,5 Min over 3GB untar

[LauPro]

Zonder write cache is een RAID-setup over het algemeen een blok aan je been dan. Een RAID-setup kan niet goed performen zonder write-cache omdat je anders met teveel syncronisatie zit. Zet het eens aan? En hardware RAID en software RAID is wat anders natuurlijk.

[ Voor 1% gewijzigd door LauPro op 14-09-2007 04:42 . Reden: write idd :X ]

[CrankyGamerOG]

LauPro schreef op vrijdag 14 september 2007 @ 00:26:
Zonder Wire cache is een RAID-setup over het algemeen een blok aan je been dan. Een RAID-setup kan niet goed performen zonder write-cache omdat je anders met teveel syncronisatie zit. Zet het eens aan? En hardware RAID en software RAID is wat anders natuurlijk.

ik mag hopen dat je write cache bedoeld

en de enigste reden waarom ik de 2e server erbij zet is voor vergelijk meer niet

ik zal morgenvroeg eens op dat ding de write cache enablen, hijs nu nog druk met format

[ Voor 8% gewijzigd door CrankyGamerOG op 14-09-2007 00:34 ]

[Verwijderd]

Om een lang verhaal kort te houden. Raid-5 writes zijn niet voorruit te branden zonder write-cache.

Je hebt een buffer nodig voor de parity-berekeningen. Write-cache is echt cruciaal. Voor andere raid-vormen zoals het 0, 1 en 0+1 / 1+0 maakt het praktisch niet uit.

Ik zie zoveel mensen de fout maken om raid-5 te implementeren op controllers zonder write-cache...

[ Voor 53% gewijzigd door Verwijderd op 14-09-2007 00:40 ]

[Sprite_tm]

Misschien vrij wiedes, maar is je array niet gewoon vrolijk bezig in de achtergrond de disks te syncen? Dat zou in theorie best veel bandbreedte kunnnen opeten. Dat zou dan morgen wel es klaar moeten zijn; als je array dan 'ineens' sneller is zou dat het wel kunnen wezen.

[Verwijderd]

niet om het een of het ander, maar hoe groot is de uncompressed data? als ik 4GB aan logs in 104MB kwijt kan dan zou ik een kleine 118GB uitpakken als mijn tar 3GB was i.p.v 104MB.

Raid5 staat bekent om zijn trage write-performance doordat voor elke byte een XOR berekening moet gebeuren wat best computatieve is. hardware Raid oplossingen hebben daarom hardware-matige XOR proccessors aanboard zodat deze last niet op bij de CPU opkomt. een write-cache maakt deze berekening sneller, naast dat het de I/O synced en HDD dus meer kunnen bursten en niet talloze kleine lees/writes hoeven te doen.

dus mischien dat door hardware raid het lijkt dat de computer niks berekent maar de hardware matige XOR berekening tellen niet mee met de CPU. het blijft een zware klus.

wat ik zou doen is, write-cache aanzetten en kijk ook eens ofdat het untarren naar de systeemschijf langduurt. daarnaast bevat tar geen compressie en moeten .tar.gz bestanden eerst helemaal worden uitgepakt, wat dus 3GB aan writes teweeg brengt, voordat ze kunnen worden uitgepakt. probeer deze 2e fase's te scheiden door de .tar.gz eerst uittepakken naar een uncompressed .tar en pak deze dan pas uit.

daarnaast weet ik niet of de schijven nieuw zijn maar als ook maar 1 schijf problemen heeft en veel retries moet doen hebben alle 3 de schijven daar last van want bij raid5 moeten alle schijven ready geven voordat het volgende block kan worden geschreven. dit is anders dan bij raid0 of raid1 waar 1 schijf wat achter mag blijven zonder vergaande performance problemen. het kan zijn dat 1 van de sata kabels mischien kapot is of de behuizing waarin de schijf gemonteerd is kan van invloed zijn. het kan geen kwaad de schijven eerst eens individueel te testen. eventueel met het programma van de fabrikant van de schijven.

en met Raid5 moet je nooit hoge schrijfsnelheden verwachten. Raid5 staat bekend om zijn Raid0 achtige reads en Raid1 achtige reduantie. netzoals Raid0+1 maar dan met 33% kost i.p.v 50%. de winst wordt echter gehaald bij de schrijfacties waarbij het niet ongehoord is dat software-raid soms nog sneller is dan hardware-raid.

probeer anders eenst software-raid en kijk of het iets uitmaakt in de performance want een Xeon 5130 kan heel wat XOR bewerkingen afwerken en daarmee omzeil je ook de raid-controller welke heelgoed de schuldige van jouw laag uitvallende write-performance is.

[Guru Evi]

Wat is de status van je RAID? Als een van je disks eruit gevallen is of gewoon ergens slecht is (al dan niet met een SMART of gelijkaardige status error) dan kan het ook zijn dat je die problemen tegenkomt

[ Voor 6% gewijzigd door Guru Evi op 14-09-2007 17:15 ]

[CrankyGamerOG]

Guru Evi schreef op vrijdag 14 september 2007 @ 17:14:
Wat is de status van je RAID? Als een van je disks eruit gevallen is of gewoon ergens slecht is (al dan niet met een SMART of gelijkaardige status error) dan kan het ook zijn dat je die problemen tegenkomt

jij SLAAT de spijker op zn kopt, de laatste 500GB disk was rot
hier ben ik vrijdag achter gekomen nadat ik het systeem heb overgezet naar software raid.
ik wilde dus centos5 erop mikken in software mode (nadat ik het raid kaartje eruit gerukt had)
elke keer ging alles goed totdat centos de install image ging kopieren, kwam steeds met de melding disk full (terwijl hij toch echt net die 120GB geformateerd had lol )
De install image moest naar de enkele disk die dus ook niet in de raid5 was aangemaakt, dus ik snapte echt niet waarom het niet ging, dacht eerst dat die 120GB kapot was, bleek dus de 3e 500GB te zijn, nadat ik die verwisseld had was het probleem weg
hierna dus alles terug gezet in hardware raid en ding draait als een zonnetje nu, thnx allemaal

[CrankyGamerOG]

ok hier ben ik weer

ik kom er toch niet uit met dat raid 5 , telkens als ik iets doe op een raid5 array schiet de load omhoog en is het om te huilen

of ik nu software of hardwarematig raid5 draai het maakt geen verschil uit ?

[Verwijderd]

alle schijfen al 1 voor 1 getest in een andere computer met het diagnostic programma van de producent? welk merk/type schijfen zijn het eigenlijk?

kijk ook eens of de sata-cables en/of enclosure's mischien rot zijn. gewoon 1 voor 1 testen.

probeer anders eens raid0 of raid1 in software raid en kijk of je dezelfde drop's in read/write performance ziet. voor raid0 zal de read hoog liggen maar de write alsof het een single disk is en voor raid1 zal de seek-times laag liggen en de write iets lager met de read's mogelijk iets hoger. als dat wel gewoon normaal is probeer het dan nog eens met hardware raid.

je moet gewoon de oorzaken 1 voor 1 wegstrepen en voor raid5 geld dat als 1 schijf achter raakt om wat voor reden dan ook, zij het een rote kabel, enclosure of de schijf zelf. de rest moet wachten omdat in raid5 writes altijd in sync gebeuren naar alle schijfen tegelijk.