[3Ware Escalade 7506]Schrijfsnelheid valt repeterend omlaag

[Tom_G]

Situatie:

Een Fedora Core 3 Linux server die draait op een:

- 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 in 2de pci slot vanaf vga kaart. 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.
- Een realtek 8169 nic die binnenkort vervangen wordt door een Intel gigabit kaartje

Wanneer ik nu vanaf het netwerk schrijf naar de raid array, dropt de snelheid om de paar seconden in elkaar.

Ik haal dus de maximum 100 mbit snelheid (die realtek nic in server wil niet op gigabit, ook niet onder windows, vandaar te vervangen door Intel), maar die valt in elkaar tot soms 1 MB/s of lager. Er zitten dus telkens drops in de datatransfer.

Met die 250 Gb disk is dit niet het geval. Deze bijft constant.

Nu heb ik een test gedaan. Ik neem een bestand van 586 MB dat ik eerst ftp naar de 250 Gb disk. Dit duurt exact 1 minuut.
Wanneer ik hetzelfde bestand ftp naar de raid array duurt dit 1min10sec.

Op de server zelf (onder Gnome desktop) kopier ik manueel dit bestand van de 250 Gb disk naar de raid array. Maar liefst 52 seconden duurt dit, dat in vergelijking met 100 mbit lan van daarnet. Ik kan ook daar aan het voortgangsbalkje zien dat het kopieren enkele keren gewoonweg stopt, voor 1 of méér seconden en daarna terug verder gaat. Mocht dit er niet tussenzitten zou de snelheid nog goed meevallen.

Zeker niet goed dus. Bij lezen vanaf de raid array via ftp, duurt dit bestand terugkopieren zelfs 1min11s.

Ik heb dus de indruk dat het probleem zowel bij lezen/schrijven is, maar schrijven is toch nog frequenter voorkomend (snelheid gaat soms wel onder 100 KB/s voor een halve seconde).

Nu lijkt het me ergens logisch dat er een probleem is met die raid array, vraag resteerd welke? Het write cache zal er wel niet toedoen denk ik aangezien het bij lezen ook voorkomt en met de losse 250 Gb disk niet.

Iemand weet die hier aan de hand is? Zo slecht kan die raid controller nu toch ook weer niet presteren?

alvast bedankt

[Shuriken]

Ik kom uiteraard weer met de VIA PCI implementatie om de hoek.

Probeer eens te experimenteren met de PCI Latency instellingen in de Bios.

[fenrir]

de write performance van een 7506 in raid 5 is om te huilen. een enkele HD gaat sneller in write dan een leuke raid 5 config met de 7506.

ter vergelijking:

code:

3*200 GB 7200.7 raid5@7506 : 35 mb/s
single schijf              : ong 70 mb/s

ik overweeg dus ook om over te stappen naar een raid 1+0.

kaart zit bij mij overigens in een PCI64/66 slot

[ Voor 11% gewijzigd door fenrir op 16-08-2005 17:27 ]

[Tom_G]

Die 35 MB/s haal ik zelfs nog niet eens. Van mij zit het in een pci 32bit 33mhz slot maar zelfs dit kan veel hoger. Ik zal eens in de bios gaan kijken dan.

edit: in bios heb ik nu pci delay van enabled naar disabled verplaatst maar geen effect. IRQ's toewijzen staat op auto. Ik heb nu trouwens de raid controller verwisseld met de netwerkkaart (raid controller bovenaan vlak onder de vga kaart, eronder de nic).

Geen resultaat dus.

Om even grafisch die drops aan te tonen, dit is te zien in DU meter over een periode van een minuut tijdens transfer.

[ Voor 63% gewijzigd door Tom_G op 29-08-2005 15:03 ]

[Shuriken]

fenrir schreef op dinsdag 16 augustus 2005 @ 17:25:
de write performance van een 7506 in raid 5 is om te huilen. een enkele HD gaat sneller in write dan een leuke raid 5 config met de 7506.

ter vergelijking:

code:

3*200 GB 7200.7 raid5@7506 : 35 mb/s
single schijf              : ong 70 mb/s

ik overweeg dus ook om over te stappen naar een raid 1+0.

kaart zit bij mij overigens in een PCI64/66 slot

Jeetje dat is inderdaad wel dramatisch. Ik haal met software raid 5 onder w2k3 bijna net zoveel.

[Shuriken]

Tom_G:
Al enige verbetering? of nog steeds huilen met de pet op?

Wat voor performance geeft een timed dd of een bench met bonnie++? op de array zelf.

[ Voor 12% gewijzigd door Shuriken op 19-08-2005 16:05 ]

[Tom_G]

Shuriken schreef op vrijdag 19 augustus 2005 @ 16:04:
Tom_G:
Al enige verbetering? of nog steeds huilen met de pet op?

Wat voor performance geeft een timed dd of een bench met bonnie++? op de array zelf.

Euh, hoe doe ik dit?

Nee, nog altijd even slecht dus. Ook lezen valt in drops naar beneden.

Ik weet niet of het aan de pci sloten ligt, want... dan zou de netwerk performance ook slecht zijn. Ik wacht nu nog altijd achter die goeie Intel gigabit nic, dewelke pas voor na volgende week pas zal binnen zijn in de winkel.

Langs de andere kant heb ik met dat mobo lang problemen gehad met een tv kaart (strepen in beeld, crashen bij opnemen), terwijl dit in andere pc geen probleem is.
Toch iets met pci?

edit:
Net nog even geprobeerd om over wireless iets te kopieren. Dat zit ongeveer beperkt tot 2 MB/s (wat normaal is) MAAR zelfs daar komen die snelheidsdrops voor (iets minder frequent). Snelheid valt zelfs één à 2 seconden terug naar 0 en paar 100 KB/s.

Blijbkaar doet het er dus niet toe hoe snel de transfer gebeurd, het komt toch repeterend terug. Straks nog eens print hiervan posten.

edit 2:
Hier het grafiekje en snelheidstest bij transferen vanaf raid array over draadloos netwerk:

Hier zie je dus dat de snelheid enkele keren volledig terugvalt naar 0. En dit ligt zeker niet aan de wireless lan, het probleem doet hem anders nooit voor.

[ Voor 35% gewijzigd door Tom_G op 29-08-2005 15:03 ]

[John2B]

3Ware performance TIP:

http://www.3ware.com/KB/article.aspx?id=10697

[ Voor 94% gewijzigd door John2B op 19-08-2005 22:06 ]

[Shuriken]

John2B schreef op vrijdag 19 augustus 2005 @ 20:23:
3Ware performance TIP:

http://www.3ware.com/KB/article.aspx?id=10697

Q10697 - Performance/Optimization: How can I improve my Windows write performance with my 75xx or 85xx? ATTO disk bench is showing slow write performance with my 3ware RAID array.

When using the 7.61 code set or newer, you can tune the Windows driver to increase the write performance by modifying the Windows registry.
3Ware tunning tip, misschien heb je er wat aan:

To disable use of the FUA (Force Unit Access) bit on SCSI writes, add the following entry to the Windows registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\3ware Storage Controller]
"CacheControl"=dword:00000001

You can also double click on the attached "3ware_noFUA_cache_setting.reg" file to automatically add the registry entry. Reboot for the changes to take effect. This will increase write performance on benchmarks such as Atto BENCH32.exe.

To ignore all SRB flush commands, add the following entry to the Windows registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\3ware Storage Controller]
"CacheControl"=dword:00000010

To ignore all SCSI flush commands, add the following entry to the Windows registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\3ware Storage Controller]
"CacheControl"=dword:00000020

To ignore all flush commands and disable use of the FUA bit (fastest write performance), add the following entry to the Windows registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\3ware Storage Controller]
"CacheControl"=dword:00000031

To restore back to the default setting, add the following entry to the Windows registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\3ware Storage Controller]
"CacheControl"=dword:00000000

You can also double click on 3ware_noFUA_noflushing_cache_setting (best write performance).reg or 3ware_default_cache_setting.reg.

After double clicking on the .reg keys and entering them into the Windows registry, you must reboot in order for them to take effect.

Warning: When Windows sends a flush command to the driver, it expects that the data has been committed to disk drive. Setting the 3ware Windows driver to ignore these flush commands will cause Windows to believe that data has been committed to disk. Windows Performance tuning.

Bedankt voor de tip. Denk alleen niet dat Tom_G de registry kan vinden in Fedora Core 3.

[John2B]

Shuriken schreef op vrijdag 19 augustus 2005 @ 22:00:
[...]

Bedankt voor de tip. Denk alleen niet dat Tom_G de registry kan vinden in Fedora Core 3.

Oeps...even overheen gelezen...was in ieder geval goed bedoelt.

[Tom_G]

John2B schreef op vrijdag 19 augustus 2005 @ 22:06:
[...]


Oeps...even overheen gelezen...was in ieder geval goed bedoelt.

Lol, don't mind it, het is goed geprobeerd

Het is en blijft toch wel erg vreemd.

Als dit zo blijft, zal ik ook eens zien wat de performance zal zijn met de gigabit nic erin (eventueel kijken of de snelheid drop's frequenter voorkomen).
In het slechtste geval denk ik anders eventueel over te stappen op raid 10 mocht dit wel stabieler èn sneller zijn. Al dan niet tijdelijk, om te bepalen of de snelheidsproblemen hiermee opgelost zijn.

[ Voor 9% gewijzigd door Tom_G op 20-08-2005 05:42 ]

[Tom_G]

We zijn ondertussen weer wat verder geraakt. De Intel Pro/1000 GT netwerkkaart zit pas in de server.

Een download via ftp van datzelfde bestand van 586 Mb duurt nu 31 seconden. Snelheid +- x2 dus. Wel vreemd dat een lokale copy van de array dan toen ik het eerder testte, veel trager ging.
Het lijkt wel of die Intel nic de algehele performance verbetererd heeft.

Nu kan ik lokaal niet meer testen met diezelfde copy, die hd van 250 gb zit er tijdelijk niet in (niet in gebruik).

Maar zelfs nu blijven de snelheids drops nog van toepassing. Niet frequenter dan bij lagere transfersnelheden heb ik de indruk.
Soms piekt de snelheid eens op een download van 30 MB/s, maar meestel is dat tussen de 18 en 25 MB/s. Screenshots volgen straks, waar je ook nog op kan zien dat die drops er nog altijd zijn (download heb ik net getest, upload naar de array moet ik nog doen).

Ik zal ook es testen wat er met de bootdisk (een oude Maxtor van 40 gb) te halen is aan download vanaf de client.

Edit: nog wat screens

Het bestand dat hieronder nu getransferd werd, is 3,94 Gb groot.

Om te beginnen, er zit een stevige bug in DU meter blijkbaar. Soms gebeurd het wanneer de snelheid enkele keren op 0 terugvalt, dat de gemeten waarden negatief worden. Op een gegeven moment begint hij dan terug op te tellen, vanaf de negatieve waarde...

Het enige wat zeker klopt aan de screens hieronder, is de maximum snelheid.

Download: server -> client, vanaf de lokale bootdisk in de server (Maxtor 40 Gb):
Transfertijd: 2'51''

Ook nu blijven die snelheidsdrops komen. Die lokale disk zit nochtans op de on board ide controller. 1ste maal dat ik dit fenomeen zie. Het is weliswaar een andere disk, maar zit op diezelfde on board controller.

Upload: client -> server, naar de lokale bootdisk in de server (Maxtor 40 Gb):
Transfertijd: 3'28''

De snelheidsdrops zijn hier enorm frequent en lang aanwezig. Soms blijft de snelheid meerdere seconden (soms wel 5 s) op 0 KB/s staan. Nochtans doet de maximum snelheid het wèl goed.

Download: server -> client, vanaf de raid 5 array:
Transfertijd: 3'04''

De snelheid blijft behoorlijk, doch de drops komen voor maar duren minder lang.

Upload: client -> server, naar de raid 5 array:
Transfertijd: 6'28''!!

Dit is echt huilen met de pet op. Terwijl de maximum snelheid vrij goed is duren de drops hier het langst vanal.

Deze laatste lijkt wel een samenloop van problemen te zijn.

Met al deze screens te posten vraag ik jullie mening, wat kan er hier mis zijn? Zou de bewering over de PCI implementatie van VIA dan toch hier voor een stuk (+ de slechte write performance raid controller) hier dan toch voor iets tussen zitten?

Heel vreemd is in alle geval dat de drops niet aanwezig waren met de data disk van 250 Gb. Ik denk om dit straks ook nog even te gaan proberen om te zien of de problemen ook hier al dan niet aanwezig zijn.

[ Voor 59% gewijzigd door Tom_G op 29-08-2005 15:23 ]

[Tom_G]

Ik heb met het kopieren naar de server ondertussen nog wat vreemds voor.

Zoals jullie in vorige post bij laatste screen zagen, is de upload van client naar server, meerbepaald naar de raid 5 array barslecht.

Wel, vandaag had ik dit ook voor, gelijkaardig scenario, maar naar een tijd viel die snelheid terug naar een constante snelheid van +- 500 KB/s. De snelheid is nu stabiel, maar het lijkt er wel op alsof deze gecapped is.

Iemand die nog kan volgen?

[Tom_G]

Aangezien hier de slechte VIA pci bus zou kunnen de oorzaak zijn, zou het interessant zijn om op zoek te gaan naar een ander mobo?

Ik dacht aan ASUS A7N8X-x zodat ik m'n cpu en ram geheugen nog kan gebruiken. Dit mobo heeft een nforce 2 chipset. Beter of niet?

Edit:

Ik heb daarnet even geprobeerd met een mobo met Sis chipset dat ik hier nog liggen had, maar ook dit brengt geen verbetering.

Write cache aan of uit, het maakt blijkbaar ook zogoed als niks uit.

[ Voor 30% gewijzigd door Tom_G op 03-09-2005 18:52 ]

[Tom_G]

Ok, ik heb nu nog een paar andere dingen uitgepluisd. Zo is het zo dat bij het uploaden naar de array het ram geheugen vult tot het volledig vol is.

Zou het kunnen dat de controller dan het ram geheugen als cache gebruikt?

Wanneer de snelheid op 0 valt, lijkt het wel alsof de volledige connectie dichtzit. De webserver is niet bereikbaar, ook op een andere client is er geen connectie met de server.

Om te testen deed ik het volgende: op een andere client liet ik een videofilmpje afspelen die op de server staat, zodat we daar een kleine download krijgen (+- 700 KB/s).

Op dat moment load ik een file up met de client met gigabit nic. Eens de snelheid dus op 0 valt (en dat duurt soms ettelijke seconden), hangt ook het filmpje, of zijn er stotteringen in het geluid ervan merkbaar.
Op die moment is de Apache webserver ook niet bereikbaar. Van zodra de transfer terug verder gaat, gaat ook het filmpje verder en is de webserver te bereiken.

Het lijkt dus wel op een soort "hang up" die het volledige systeem lam legt bij het uploaden.

Vreemd maar waar: ik ben er één maal in geslaagd om een file van 2 Gb up te loaden, zonder drops naar 0. Ook was er op dit moment geen probleem vanaf andere client. Dit heeft zich maar één maal voorgedaan, de erop volgende keren was het probleem weer zoals voorheen.

Ik snap het dus allemaal niet meer. Wat hebben die snelheidsdrops nu juist te maken met feit dat server tijdelijk hangt?
Heeft het te maken met het ram geheugen die om één of andere bizarre reden volledig opgebruikt wordt tijdens het uploaden naar de array?

Ik hoop dat iemand van jullie hier meer van weet. thx

[Tom_G]

Er moet toch wel iemand vertrouwd zijn met dit probleem? Op google vind ik er alvast niks over.

Als ik bvb op een client de uploadsnelheid voor ftp beperk op bvb 10 MB/s, dan gebeuren die drops niet.
Zet ik die op 20, dan valt hij soms wel terug, maar meestal niet naar nul.

Laat ik hem z'n gang gaan (onbeperkt), dan krijg ik hoge pieken, en lange tijden dat hij op 0 blijft.

[Tom_G]

Ondertussen heb ik hier een 2de hands MSI K7D Master (Dual Athlon MP mobo) met 2x 64 bit pci sloten op.

Alle hardware heb ik nu overgeheveld naar dit mobo, maar nog steeds krijg ik die transfer drops bij het uploaden naar de raid array op de server.
Overigens zit er op dit bord nu 1 Gb registred ddr ram (4 lattjes), en ook het ram geheugen wordt opgebruikt volgens phpMyStats.

Zou dit nu softwarematig zijn of zit er echt een probleem in die raid controller? Al bij al kan ik geloven dat die slecht presteerd bij raid 5, maar daarom mag het ganse systeem toch niet plat gaan op het moment dat de upload transfers naar 0 vallen?

[ Voor 15% gewijzigd door Tom_G op 21-11-2005 18:15 ]

[Mishmash]

Heb je al eens een andere raid controller geprobeerd? Of toevallig een software matige raid...

[Tom_G]

Mishmash schreef op maandag 21 november 2005 @ 18:39:
Heb je al eens een andere raid controller geprobeerd? Of toevallig een software matige raid...

Een andere raid controller heb ik niet. Softwarematig zou ik nog eens kunnen proberen. Of mischien een raid level zonder parity (10 bvb).

[Mishmash]

of gewoon een raid 0 natuurlijk

[Tom_G]

Mishmash schreef op maandag 21 november 2005 @ 21:16:
of gewoon een raid 0 natuurlijk

Aangezien het wat moeilijk is om nu m'n ganse raid 5 uit elkaar te halen, heb ik het volgende geprobeerd:

één Maxtor 120 Gb / 7200 rpm hd

Heb ik als enkele disk aan de 3Ware controller gehangen, en ftp uploadtest gedaan. Het te transferen bestand is 1,45 Gb groot.
Dit bestand transferen naar de Maxtor hd via de raid controller duurt 51''.

Vervolgens heb ik diezelfde hd aan de on board controller gehangen van het MSI K7D master moederbord (in de bios staat er IDE PCI, zou dit ook daadwerkelijk betekenen dat deze IDE controller op de IDE bus zit? )
Dit zelfde bestand transferen duurt 53''. Iets langer dan via de 3Ware controller dus.

Op zich lijkt er niet zoveel aan de hand met die controller. Echter, in beide gevallen krijg ik wel nog grote snelheidsdrops (naar 1 MB/s en zelfs 0), maar dit komt veel minder frequent voor tijdens het uploaden.

Als laatste nog maar even de 3Ware controller met de 4 disks in raid5 geprobeerd. Dramatisch. De transfers blijven meer op 0 staan dan een gemiddelde snelheid.
Het resultaat: 4' 2'' voor het uploaden van dit bestand.

Bij iedere testopstelling worden er vaak pieken van 40 MB/s gehaald (meestal helemaal in het begin).

[Tom_G]

Ondertussen alles even ge-back uped en wat andere raid levels geprobeerd.

Met 4 disks in raid 0 duurt 44'' om deze file te kopieren, sneller dan naar de hd on board dus.

Tenslotte met 4 disks in raid 10 duurt het uploaden 56''.

In beide gevallen zijn de stripe sizes 128Kb.

Ik denk dat ik hem in raid 10 laat, meer veiligheid, en zoveel opslag heb ik nu ook niet nodig.

[Tom_G]

Gisteren nog wat dingen uitgeprobeerd:

Als ik de disks niet in raid zet, en ik wil software raid draaien, krijg ik ook iets raars:
Er staat al onmiddelijk één disk als failed, en telkens ik de array wil mounten komt er één failed disk bij (beheer vanuit Webmin).
=> software raid wil dus blijkbaar niet

Met wat te zoeken kwam ik dan hier uit, dus heb ik maar even ReiserFS geprobeerd als filesystem (zie ook: [rml]Tom_G in "[ Fedora core]ReiserFS support toevoegen"[/rml]).

Wanneer ik de disks mbv de controller in raid 5 zet, slaag ik er zelfs niet in om een ReiserFS filesystem aan te maken.

Probeer ik hetzelfde, maar dan bij raid 10 dan lukt alles perfect. Iemand die nog kan volgen?

Ik kan nu ook niet weten of veranderen van filesystem hier de oplossing is, aangezien ik het niet aan de praat krijg in raid 5.

[ Voor 4% gewijzigd door Tom_G op 21-12-2005 10:32 ]

[wezep]

John2B schreef op vrijdag 19 augustus 2005 @ 20:23:
3Ware performance TIP:

http://www.3ware.com/KB/article.aspx?id=10697

Ideaal deze performance tip.
Was nog niet op zoek geweest voor tips, maar kwam dit topic tegen.
M'n writes zijn van 5mb/s gestegen naar dik 40mb/s.
Dit met 3 x WD 160Gb 7200rpm 8mb cache schijven.
Nu kan ik weer normaal dvd's rippen naar deze raid 5 set.

[Tom_G]

wezep schreef op donderdag 22 december 2005 @ 10:14:
[...]

Ideaal deze performance tip.
Was nog niet op zoek geweest voor tips, maar kwam dit topic tegen.
M'n writes zijn van 5mb/s gestegen naar dik 40mb/s.
Dit met 3 x WD 160Gb 7200rpm 8mb cache schijven.
Nu kan ik weer normaal dvd's rippen naar deze raid 5 set.

Dus als ik het goed begrijp heb je jouw filesystem op de raid 5 array dus wel kunnen omzetten naar ReiserFS en werkt dit wèl performant.

[wezep]

Tom_G schreef op donderdag 22 december 2005 @ 12:31:
[...]


Dus als ik het goed begrijp heb je jouw filesystem op de raid 5 array dus wel kunnen omzetten naar ReiserFS en werkt dit wèl performant.

Snap neit helemaal wat je bedoelt, maar ik draai Windows XP en had ook last van slechte writes.
Zo erg dat m'n dvd speler moest wachten op de raid5 set met rippen van een dvd.

Via de link van 3ware die genoemd werd, kun je een aantal registry aanpassingen doen.
Vervolgens rebooten en de performance is een stuk beter.

[Shuriken]

Tom_G schreef op donderdag 22 december 2005 @ 12:31:
[...]


Dus als ik het goed begrijp heb je jouw filesystem op de raid 5 array dus wel kunnen omzetten naar ReiserFS en werkt dit wèl performant.

Nee hij werkt onder windows en heeft die registry keys aangepast

[Tom_G]

Ach die link dus, nuja daar ben ik alvast niet veel mee.

[TD-er]

Ik heb zelf vrijwel dezelfde problemen als de TS hier omschrijft.
Ik heb de 6410 als ik me niet vergis. Met RAID5 is 'ie inderdaad bedroevend traag.
Ik haal hier een gemiddelde performance van zo'n 4 - 6 MB/s over Gbit.

Filesystem is hier ook ReiserFS.

[Tom_G]

TD-er schreef op donderdag 22 december 2005 @ 14:11:
Ik heb zelf vrijwel dezelfde problemen als de TS hier omschrijft.
Ik heb de 6410 als ik me niet vergis. Met RAID5 is 'ie inderdaad bedroevend traag.
Ik haal hier een gemiddelde performance van zo'n 4 - 6 MB/s over Gbit.

Filesystem is hier ook ReiserFS.

Ik heb ondertussen nog wat updates.

Ik heb nu terug de raid array in raid 5 geplaatst (hardwarematig dus).

Ik ben dan gestart met het installeren van Fedora Core 4. Daarvoor heb ik een ext3 systeempartitie aangemaakt van 7 Gb en een swap partitie van 1 Gb.
Setup netjes doorlopen, en dan via yum reiserfs-utils geïnstalleerd wat nu wel blijkt te werken (zie [rml]Tom_G in "[ Fedora core]ReiserFS support toevoegen"[/rml]).

Van deze keer kon ik nu blijkbaar ook een ReiserFS partitie aanmaken op de rest van de array (/dev/sda3), ter grootte van 550 Gb.

Samba aan het werk gezet, wat configuratie files dmv Webmin terug geplaatst (voor shares, users,...) en ProFTPD geïnstalleerd.

Ik doe dan eerste een ftp upload test naar de ext3 systeempartitie. Snelheden van maximum 43 MB/s worden enkele keren gehaald, al dropt de snelheid toch af en toe naar 0, al heb ik de indruk dat dit minder lang duurt (hooguit 1 seconde). De transfersnelheid is vrij variërend, zo gemiddeld van onder de 10 MB/s tot zo'n 30.

Wat mij echter meer interesseerd nu is de ReiserFS partitie. Ik doe dus hetzelfde, en ook zie ik gelijkaardige resultaten.
Wat me echter vooral opvalt, is dat die hoge snelheden (40+ MB/s) eingelijk vooral maar in het begin worden gehaald (transfer van file > 3 GB).
Na verloop van tijd daalt dit ook, af en toe ook naar 0 maar minder lang. Ik heb ook de indruk dat het systeem niet plat gaat op die momenten (het tijdstip van 0 KB/s is tenslotte nu ook vrij kort, om welke reden dan ook).

Gemiddeld over gans de transfer haal ik zo'n 19 MB/s, niet slecht voor een gemiddelde.

Dan de test met Samba. Ik kopier een gelijkaardige grote file via Mijn Netwerklocaties in Windows naar de ftp.
Alvast valt op dat de maximum snelheid hier beperkt is tot zo'n 32 MB/s. Meestal hangt dit in het begin vrij stabiel rond de 28.
Ook dit verlaagt af en toe, doch de transfer kent een stabieler verloop. Ik haal hier gemiddeld zo'n 20 MB/s.

Dan een ftp upload test met een file van 700 MB. Die haalt zo'n gemiddelde van bijna 28 MB/s.
Ik zou denken dat het snelle begin van de transfer iets met caching te maken heeft.
Alleen weet ik niet waar dit zich hier juist afspeeld. Het ram geheugen wordt namelijk amper gebruikt.

Ik kan momenteel niet echt klagen, al is het spijtig dat de hoge transfersnelheid via ftp niet blijft aanhouden en telkens in het begin is.
De enige verschillen tov de vorige opstelling is nu:
-De installatie van FC3 of 4 staat nu niet meer op een IDE bootdisk van 20 Gb, maar staat ook op de raid 5 array
-De data partitie op de raid array is niet meer in ext3 maar in ReiserFS geformatteerd.

[ Voor 6% gewijzigd door Tom_G op 23-12-2005 15:55 ]

[TD-er]

Het booten van het OS van de raid-schijf zou niet verschil uit moeten maken, sterker nog, je zou verwachten dat het daar langzamer door wordt.
Het verschil tussen Ext3 en ReiserFS zou ook niet zo groot moeten zijn, maar daar kan ik me nog iets bij voorstellen.
Hetgeen ik hier ervaar is dat in het begin de transfer-rate vrij goed is (25 MB/s hier) en dan steeds 0 MB/s is. Vaak is die periode van stilstand groter dan de periode waarop data geschreven of gelezen wordt.
Na een paar van die periodes is de max transfer-rate hooguit zo'n 16 MB/s.

Het systeem lijkt ook te hangen tijdens die periodes waarin niet geschreven wordt en als je met een hoop dingen bezig bent loopt de load ook vrij snel op en alle disk-IO lijkt dan te hangen.

Ik heb voor mezelf al besloten om alleen nog maar 2 raid-1 partities op die 3Ware controller te gaan gebruiken, omdat dit dus echt niet opschiet.

Wanneer je trouwens wat langzamer de data leest (bijv op 4x DVD-branden) dan blijft de transferrate wel redelijk stabiel, maar toch wel goed dat er een buffer-underrun beveiliging is

[Tom_G]

TD-er schreef op vrijdag 23 december 2005 @ 16:06:
Het booten van het OS van de raid-schijf zou niet verschil uit moeten maken, sterker nog, je zou verwachten dat het daar langzamer door wordt.
Het verschil tussen Ext3 en ReiserFS zou ook niet zo groot moeten zijn, maar daar kan ik me nog iets bij voorstellen.

Dat dacht ik ook, maar blijkbaar maakt het geen verschil in dit geval. De beste verklaring hiervoor zal zijn dat het os - eenmaal geboot - niet zoveel disk activiteit veroorzaakt. Dit is tenslotte maar een thuis servertje, daar draait kleine site op, paar kleine mysql databases en verder dus nog als fileserver via ftp en samba.
Het filesysteem zou dus wel kunnen uitmaken, aldus de eerder geposte link. Wat het verband met raid 5 daarmee is, is en blijft voor mij een raadsel.

Hetgeen ik hier ervaar is dat in het begin de transfer-rate vrij goed is (25 MB/s hier) en dan steeds 0 MB/s is. Vaak is die periode van stilstand groter dan de periode waarop data geschreven of gelezen wordt.

Idem dito dus zoals je mischien gelezen hebt in voorgaande posts. Ik weet nog dat het soms ellenlange seconden duurde voor hij terug verder ging met transfers. Leek wel een volgelopen buffer die nu "halt" toeriep.

Na een paar van die periodes is de max transfer-rate hooguit zo'n 16 MB/s.

Ik weet niet meer exact wat ik haalde, al zal het iets gelijkaardigs geweest zijn. Vrij hoge pieken, enorm variërende snelheden, terugval naar 0 waren hiervoor in mijn geval vrij typerend.

Het systeem lijkt ook te hangen tijdens die periodes waarin niet geschreven wordt en als je met een hoop dingen bezig bent loopt de load ook vrij snel op en alle disk-IO lijkt dan te hangen.

Ook terug idem dito. Zelfs een html pagina vanop apache laad op zo'n momenten niet meer in. Alsof het ding op dat moment van de buitenwereld is afgesloten.

Ik heb voor mezelf al besloten om alleen nog maar 2 raid-1 partities op die 3Ware controller te gaan gebruiken, omdat dit dus echt niet opschiet.

Waarom geen raid 10? Dat is even groot als die 2 raid 1 partities die je wilt maken (zowel raid 10 als raid 1 hebben 50% overhead qua opslag).
Dan heb je tenminste één groot volume (zoals ik het dus tot nu toe een lange tijd heb laten draaien aangezien raid 5 moeilijk doet), en voor raid 10 is er alvast geen parity nodig, dus ik zou het een kans geven in jouw geval.

Wanneer je trouwens wat langzamer de data leest (bijv op 4x DVD-branden) dan blijft de transferrate wel redelijk stabiel, maar toch wel goed dat er een buffer-underrun beveiliging is

Je hebt dit probleem dus ook bij het uploaden vanaf de server (= downloaden naar jouw pc client)? Dit was bij mij veel minder het geval, wel variërende snelheden maar geen langdurige drops naar 0.

[TD-er]

De reden dat ik geen raid 10 ga gebruiken is dat ik die 4 schijven van 80 GB die ik nu gebruik wat anders wil gaan indelen.
2x 80 GB als losse schijven op de onboard-IDE-controller en op de 3ware 2x 80 Gb in raid-1 en 2x 300GB die ik nog moet kopen in RAID1.
Dan kan ik die losse schijven gebruiken voor download-activiteiten en swap en temp enzo en die 80 GB in raid-1 als OSschijf en /home en de rest als postbus (geen idee of het een algemeen begrip is, maar binnen mijn kennissen krijgt noemen we dat zo, wanneer iedereen daar bij kan op het netwerk)

Maar goed, het lezen en schrijven gaat bij mij dus nogal haperend. Niet alleen het schrijven.

Wat het verschil kan zijn tussen de filesystemen zou bijvoorbeeld de blokgrootte kunnen zijn waarmee je het filesysteem steeds benaderd.
Als dat op de een of andere manier net ongelukkig uitpakt, kan het dus voorkomen dat het buffer- en caching-algoritme dus compleet verzuipt.

[Tom_G]

10 maanden later een een hoop frustraties erbij ben ik overgeschakeld van Fedora Core 4 naar Debian Sarge.

Aanvankelijk gebruikte ik ReiserFS voor datapartitie. Bleek dat er binnen de kortste keren corrupties te bespeuren waren in grote files. Dat was nog niet alles: bij het kopieren van files zag je het ram geheugen gewoon vollopen alsof het als cache gebruikt wordt (dit was bij ext3 ook al het geval dacht ik).
Controller cache aan of uit, het maakt allemaal niet uit.

Sinds gisteren gebruik ik nu terug ext3 en jawel hoor, het op-en-neergaande traffiek met de tussentijdse "hang-ups" van het systeem (bvb tijdens hang-up moet je wachten tot je een webpagina van Apache geserveerd krijgt op een client vanaf de server) zijn ook weer van partij zoals in het begin van topic vermeld.

Complete andere distro & kernel en in het verleden (zoals in begin van dit topic aangegeven) ook eens veranderd van moederbord.

Het mag blijkbaar allemaal niet baten, de controller lijkt wel verdoemd om z'n werk onder Linux goed te doen.

Ik denk dat ik het bij deze opgeef en de controller + disks in m'n desktop pc installeer, want dit bleek nl. onder Windows geen enkel probleem op te leveren voor zover ik mij dit nog herriner uit een test van vroeger.
In de server komt dan een SATA PCI kaartje (PROMISE SATA300 TX2 PLUS CONTROLLER) en één 320GB 7200.10 disk van Seagate.

[ Voor 3% gewijzigd door Tom_G op 09-10-2006 13:25 ]