Ram geheugen opgebruikt bij schrijven raid array

[Tom_G]

Naar aanleiding van dit topic: [rml][ 3Ware Escalade 7506]Schrijfsnelheid valt repeterend omlaag[/rml]
Omdat het specifiek een ram geheugen vraag is (eventueel in combinatie met mobo, pci,..) stel ik deze vraag hier.

Ik heb dus een thuis server config met volgende hardware:

- MSI KT4 Ultra
- Athlon xp 2200+
- 2x 256 MB pc 2100 ddr ram
- 40 Gb bootdiskje
- 250 Gb data disk op secundary ide controller als master (cd drom zit op slave)
- 3Ware Escalade 7506 net onder de vga kaart in een 32 bit pci slot. 4 schijven van 200 Gb in raid 5 met stripe block size van 64 k (ik kon geen andere waarde kiezen). Array write cache staat aan.
- Intel Pro/1000 GT netwerkkaart in het pci slot net onder de raid controller

Nu is het blijkelijk zo, heb ik pas vandaag gemerkt dat het ram geheugen volledig opgebruikt wordt bij het schrijven naar de array, en dan uiteindelijk ook de transfersnelheid voor korte tijden naar 0 terugvalt (zie ander topic voor details).

Overigens maakt het aan- of uitzetten van write cache in de raid controller bios niks uit.

Het systeem lijkt dan ook op een zekere manier te hangen. Vb hiervan zijn dat een andere client ook geen connectie krijgt naar de server (specifiek naar het webserver gedeelte of fileserver gedeelte).

Ik had inmiddels al een mobo met 64 bit pci sloten overwogen, maar het lijkt me intiütief dat het probleem een andere basis heeft, dewelke zou moeten opgelost worden.

Ik zou kunnen begrijpen dat dergelijke situatie zich voordoet bij software matig raid, maar deze controller handeld zelf alles af, dus lijkt me dit fenomeen onverklaarbaar. Bij het lezen vanaf de controller is er niks aan de hand.

alvast bedankt

[ Voor 21% gewijzigd door Tom_G op 04-09-2005 13:50 ]

[Abbadon]

Het OS gebruikt een deel van het geheugen (vaak dat deel wat nog helemaal leeg is) als filesystemcache. Wanneer je dus flink aan het downloaden bent zal dit filesystemcache voller raken (helemaal vol zelfs als je veel data download) maar tegelijkertijd ook wegschrijven naar je disk, zeg als een soort van buffer. Gaat dit downloaden sneller dan het wegschrijven naar je disk (b.v. snelle gigabit verbinding maar brakke RAID5 array) dan kan de download idd gaat horten en stoten omdat er even niet zo snel bufferruimte vrij is voor de te ontvangen data.

Misschien dat dit alles te maken heeft met je RAID5 array die niet goed is afgesteld, maar ook omdat zowel de controller als de GB NIC op dezelfde PCI bus zitten (dat kan dan een bottleneck worden).

Wat is intern de schrijfsnelheid v.d. RAID5 array? (dus van je losse 250GB disk naar de vier disks RAID5). En krijg je dit horten en stoten probleem ook wanneer je gaat downloaden naar je losse 250GB disk?

[Tom_G]

[b][message=24110905,noline]
Wat is intern de schrijfsnelheid v.d. RAID5 array? (dus van je losse 250GB disk naar de vier disks RAID5). En krijg je dit horten en stoten probleem ook wanneer je gaat downloaden naar je losse 250GB disk?

Bij het kopieren van de raid 5 naar de lokale disk, gaat dit vlot, zonder onderbrekingen of haperingen.

Omgekeerd (van losse disk naar array) gaat het al vrij vlug in horten en stoten.
In het begin gaat het om 1 seconde, maar na verloop van tijd lopen die haperingen op tot ongeveer 10 seconden.

Wat opmerkelijk is, wat ik weet van de netwerk performance is, dat de maximum schrijfsnelheid naar de raid array vanaf een client wel opmerkelijk goed is. Deze heeft als maximum 40 à 42 MB/s (als dit naar de losse disk is, wordt die hooguit 35 MB/s). Dit duurt dan ook hooguit 1 seconde. Maar door het frequent stilvallen met schrijven naar de raid array, is de gemiddelde snelheid drastisch laag, en is de server voor andere toepassingen onbruikbaar op dat moment, wat niet het geval is als we hetzelfde uitvoeren met schrijven naar de losse disk.
Het lijkt wel alsof alles "vast" zit op dat moment.

Ik kan er niet zo goed meer aan uit, eerst doe ik m'n verhaal op OM over de controller zelf, ik weet nu nog niet of het aan de pci bus, moederbord of de controller ligt.

[ Voor 5% gewijzigd door Tom_G op 04-09-2005 14:35 ]

[Verwijderd]

Ik krijg het gevoel dat er 1 van je schijven defect is waardoor er teveel time-outs of retries voorvallen waardoor heel de performance van je controller als een pudding in elkaar zakt.

Ik zou al die schijven eens een voor een aan een grondige controle onderwerpen...

[TD-er]

Ik heb vrijwel exact hetzelfde probleem.
Ik heb de 3ware Escalade 6410B en bij mij is de gemiddelde schrijfsnelheid dus ook vrij laag door dit effect.
Helaas heb ik in de loop der tijd dus 4 verschillende schijven in RAID-5 staan (defecte schijven worden lang niet altijd voor hetzelfde model omgeruild in de winkel) Ik had het dus geweten aan die verschillende schijven en dat 'ie mogelijk telkens moest wachten.

Bij mij is echter de laatste tijd de lees-performance ook bagger (4-speed DVD-branden trekt 'ie soms al niet eens), dus ik vermoed dat de keuze van de blokgrootte en de mate van fragmentatie ook erg meespelen.
Ik ben dus heel erg benieuwd of er een ervarings-verklaring gaat komen van iemand hier.

[Tom_G]

Ik heb een Quick Test op alle 4 de WD schijven laten lopen met WD Data Lifeguard (onder dos) en alle disks zijn volgens deze tool zonder fouten.

Aangezien ik een back-up heb van de data, heb ik maar besloten om de raid controller onder andere raid levels te proberen.

Omdat ik wil dat de Linux server nu voorlopig verder draait op die 250 gb opslag disk, heb ik een andere pc gekozen, waar ik de raid controller in geplaatst heb. De configuratie is wellicht niet relevant voor het probleem.

Ik heb dus bij wijze van testen met de 4 disks één raid 0 array (die ik overigens nooit zou willen gebruiken als definitieve oplossing) gezet, de pc waar de controller nu in zit, draait op Windows XP zodat ik een Atto Disk bench kon uitvoeren:

De schrijfsnelheid blijft dus ook hier barslecht (hooguit een 14 MB/s), de leessnelheid blijft goed (de pci bus zit waarschijnlijk af en toe vol).

[ Voor 6% gewijzigd door Tom_G op 04-09-2005 16:34 ]

[TD-er]

Zonet even een testje gedaan.


Schrijven van een grote file (2 GB grote AVI) vanaf Windows naar de Raid-array via Samba: (transfer in de screenshot gaat over de eerste zoveel-100 MB van die file)


Lezen van een grote file (>3 GB grote ISO-file) vanaf de fileserver (data staat op de RAID-array) via Samba naar Windows. (transfer gaat over de eerste zoveel-100 MB van de file)

De load van de fileserver schiet bij het schrijven omhoog en hij reageert dan ook erg traag.

code:

top - 17:02:33 up 89 days,  9:08,  2 users,  load average: 6.50, 4.57, 2.28
Tasks:  75 total,   1 running,  74 sleeping,   0 stopped,   0 zombie
Cpu(s): 11.0% us, 14.0% sy,  0.0% ni,  0.0% id, 65.0% wa,  0.7% hi,  9.3% si
Mem:    776508k total,   767748k used,     8760k free,    16336k buffers
Swap:  1494036k total,        4k used,  1494032k free,   629108k cached

[Tom_G]

Ik heb die drops nog voorgehad bij lezen ook, maar in mindere mate van voor schrijven. Die lange drop op 0 is iets vergelijkbaars als bij mij wat schrijven betreft.

Ondertussen heb ik nog andere tests gedaan: 2 raid 0 arrays met dus elk 2 disks en dan tenslotte de 4 disks appart (zonder raid) aan de controller.

Maar wat ik ook probeer, de schrijfsnelheid komt niet boven de 13 MB/s uit, terwijl de leesnelheid altijd ok is.
Ik heb daarnet diezelfde drives aan een eenvoudige pci ide controller kaart gehangen, die ik in hetzelfde pci slot heb gestoken als de raid controller, en hier halen de disks wel elk hun goede snelheid (+- 50 MB/s, zowel lezen als schrijven).

Er moet dus iets vrij grondigs mis zijn met die raid controller....

[Tom_G]

Ondertussen wat meer nieuws. Zoals gevonden op de 3Ware site is er voor Windows een register aanpassing waarmee je de juiste waarden meet in benchmarks.

Nu haal ik dus wel goede schrijfsnelheden (ik weet ze niet meer van buiten, maar laat de schrijfsnelheden van deze keer aanvaardbaar noemen, toch voor deze controller en pci bus).

Dan maar een praktijktest. Op de 80 gb op de on board ide controller staat een file van 3,94 Gb. Deze heb ik gekopierd naar de raid array, en dit duurde 1'39''. Omgerekend is dit dus 40 MB/s, wat nettjes is gezien "de slechte controller".
Het ram gebruik blijft stabiel, van de 512 mb in die config is de helft gebruikt, en dit veranderd quasi niet tijdens de transfer.
Enkel de cpu load is hoog, gemiddeld zo'n 70% (het testsysteem is een Athlon 1200 mhz).

Waarom werkte dit niet zo goed op het Linux systeem? Tenadere heb ik dit moederbord (één of ander onbekend merk met Sis chipset, ik dacht Eagletec) ook al gebruikt onder diezelfde linux install, en toen waren die snelheidsdrops evenveel het geval als met het oorspronkelijke mobo.

[ Voor 5% gewijzigd door Tom_G op 04-09-2005 23:04 ]

[TD-er]

Wat ik mij afvraag is in hoeverre deze setting aanpassen (onder Windows dus) gevaarlijk is voor je data.
_{(voor de volledigheid een linkje naar het artikel op de 3ware-site)}

Ik neem aan dat de enige plek waar de data mogelijk nog kan staan wanneer deze niet op fysieke schijven weggeschreven is, het geheugen op de controller is. Of zou de Windows-driver ook een stukje werkgeheugen als cache alloceren?

De cache op die 3ware controllers is niet erg groot, dus je raakt geen 10-tallen MB's kwijt wanneer de boel crashed, maar evengoed zou het toch vervelende effecten kunnen hebben.

Wat betreft de Linux-support voor die kaarten.
Wie heeft de drivers eigenlijk gemaakt die in de kernel zitten? 3Ware of een ander?

[Tom_G]

TD-er schreef op zondag 04 september 2005 @ 23:33:
Wat ik mij afvraag is in hoeverre deze setting aanpassen (onder Windows dus) gevaarlijk is voor je data.
_{(voor de volledigheid een linkje naar het artikel op de 3ware-site)}

Ik neem aan dat de enige plek waar de data mogelijk nog kan staan wanneer deze niet op fysieke schijven weggeschreven is, het geheugen op de controller is. Of zou de Windows-driver ook een stukje werkgeheugen als cache alloceren?

De cache op die 3ware controllers is niet erg groot, dus je raakt geen 10-tallen MB's kwijt wanneer de boel crashed, maar evengoed zou het toch vervelende effecten kunnen hebben.

Wat betreft de Linux-support voor die kaarten.
Wie heeft de drivers eigenlijk gemaakt die in de kernel zitten? 3Ware of een ander?

Ik heb dus die bovenste register aanpassing gebruikt.

Ondertussen zit de controller met de schijven terug in de linux server, waar het probleem alweer aanwezig is. Het enige verschil is dat ik nu een Ext3 partitie met Partion Magic 8 onder Windows heb aangemaakt. Merk ook op dat een NTFS partitie dmv schijfbeheer onder Windows een pak sneller gaat dan die Ext3 partitie onder PM8 aan te maken.

Ik denk dat er toch iets moet mis zijn met die driver in Linux. Dewelke het is? Fedora Core 3 bracht er standaard ondersteuning voor, zodat ik enkel 3DM (de monitoring tools via webinterface) moest installeren.

Over enkele dagen zal ik eens op diezelfde server config op een andere hd even win xp installeren, een ftp server opzetten, zodat ik met identiek dezelfde hardware opstelling een vergelijking tussen Linux en Windows kan maken (ook eventueel eens wel en niet die reg verandering toepassen).

Daarnet was dit niet het geval, gezien het om een ander mobo, vga kaart, ram geheugen, boot disk, chipset,... ging. Maar toch bewijst dit dat de controller het gewoon moet kunnen, de vraag is waarom niet in die Linux server?

Dat de performance niet op en top is, daar heb ik mee leren leven gezien de 32 bit bus. Het zou erger geweest zijn mocht ik een duur mobo met pci 64 bit of pci-x aangeschaft hebben om tot deze problemen te komen.

[Tom_G]

Ok, ik heb dus die win xp op een andere hd gezet, die draait op de oorspronkelijke hardware waaronder de linux server zelf op draait.

Een copy van een losse hd naar de raid array gaat aan ongeveer 30 MB/s, stabiel.
Over het netwerk (via ftp) is dit ongeveer 25MB/s. Dit is wel met die register aanpassing. Zonder is het een stuk lager, en transfer over lan is minder stabiel qua snelheid.

Het lijkt er dus op dat het probleem bij Linux zit, de vraag is waar? Hoe kom ik aan die hoge snelheidspieken, met drops, ram geheugen dat volloopt en systeem op dat moment amper bruikbaar is?

[The__Virus]

Misschien is DMA niet ingeschakeld voor de schijven? Maar ik zou het alsnog eens proberen met wat meer RAM en dan nog eens kijken.

[Tom_G]

The__Virus schreef op maandag 05 september 2005 @ 20:12:
Misschien is DMA niet ingeschakeld voor de schijven? Maar ik zou het alsnog eens proberen met wat meer RAM en dan nog eens kijken.

Hoe controlleer ik dat onder Linux?

Meer ram betwijfel ik, het is tenslotte maar een fileserver en onder windows doet het vreemd genoeg wel stabiel.

[TD-er]

Tom_G schreef op maandag 05 september 2005 @ 20:35:
[...]

Hoe controlleer ik dat onder Linux?

Meer ram betwijfel ik, het is tenslotte maar een fileserver en onder windows doet het vreemd genoeg wel stabiel.

Daar ben ik ook erg benieuwd naar.
Bij mijn weten test je de DMA-status met hdparm <device>
maar wat voor device is een losse schijf aan een 3ware controller?

Wat betreft de snelheid zou het wel kunnen, maar dat zou niet verklaren waarom je ineens van die drops in snelheid krijgt.

[Tom_G]

TD-er schreef op maandag 05 september 2005 @ 21:49:
[...]

Daar ben ik ook erg benieuwd naar.
Bij mijn weten test je de DMA-status met hdparm <device>
maar wat voor device is een losse schijf aan een 3ware controller?

Wat betreft de snelheid zou het wel kunnen, maar dat zou niet verklaren waarom je ineens van die drops in snelheid krijgt.

Ik heb even hdparm uitgevoerd:

code:

> hdparm /dev/sda1
 HDIO_GET_MULTCOUNT failed: Invalid argument

/dev/sda1:
 readonly     =  0 (off)
 readahead    = 256 (on)
 geometry     = 7427/255/63, sectors = 600141072384, start = 63

De controller op zich wordt als een scsi controller aanzien, en daarvan wordt er één drive herkend (zijnde de volledige raid array).