Linux performance van Areca 1220 met 4xRaptor

[bartvb]

Ik ben op dit moment bezig met het opzetten van een nieuwe database server, intel 5000PSL met 2x Xeon 1130 en 4x2GB FB-DIMM. In die machine zit een Areca 1220 (firmware 1.41) met 256MB cache en battery backup in een 8x PCIe slot. Aan die areca hangen 4 500GB disks en 4 74GB Raptors, alles dus via SATA.

Die Raptors hangen allemaal in een RAID10 van in totaal 140GB, ik verwachte daar eigenlijk wel redelijk fatsoenlijke performance van. Nu ben ik wat aan het benchmarken geweest en nu kwam ik op het volgende:

resultaten van "bonnie++ -f" op de RAID10:

code:

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
gullfaxi        16G           27347   5 21146   3           113281  11 680.2   0

resultaten van "bonnie++ -f" op de RAID5:

code:

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
gullfaxi        16G           13277  61 46469  19           138472  14 281.3   0

Schrijf prestaties zijn bij beide arrays dus behoorlijk bagger en de RAID5 doet het nog beter dan de RAID10 ook.

Ik snap echt niet wat hier nu mis gaat. Kernel is 2.6.19.1, filesystem op beide plaatsen is ReiserFS met standaard settings, beide zijn async gemount (gewoon standaard) met noatime. Disk caches van de drives worden als het goed is niet gebruikt, cache van de areca wordt wel gebruikt.

Iemand enig idee waar ik dit probleem zou moeten zoeken of wat ik kan testen? Het irritante is dat archttp64 het op het moment niet wil doen, als ik deze opstart blijft deze hangen zonder een controller te vinden. De CLI client doet iets meer maar geeft geen bruikbare info bij een aantal opties, die CLI client lijkt enorm buggy te zijn, die heb ik nooit fatsoenlijk aan de praat gekregen.

Ik las trouwens op de Areca site (die nu niet bereikbaar is lijkt het) dat er een nieuwere versie van archttp64 is dan 1.71, heeft iemand die liggen? Ik kon deze namelijk nergens downloaden bij Areca.

[John2B]

ftp://ftp.unnet.nl/pub/ar...ds/AP_Drivers/Linux/HTTP/

Er zijn bij mijn weten geen problemen bekend met archttppci of CLI onder Linux.

Zijn alle disken OK, 1 disk een beetje brak dan beinvloed die de performance van de hele array.

[ Voor 25% gewijzigd door John2B op 29-12-2006 23:05 ]

[bartvb]

Ah, thanks! Ook daar niets nieuwers dan 1.71 helaas. De problemen lijken begonnen te zijn toen ik de serial console functionaliteit van het moederbord aan heb gezet, is alleen een beetje lastig testen omdat ik dat alleen via de serial console aan/uit kan zetten op het moment Firmware menu via de serial console gebruiken gaat echt heel erg bagger :\

Oh, vergeten te melden in mijn eerste post. De RAID10 bestaat uit twee 'oude' raptors en twee nieuwere. De oude disks zijn de WD740GD, de nieuwe de WD740ADFD maar ik neem aan dat dat niet de verklaring is voor deze beroerde prestaties.

Disks zijn allemaal OK voor zover ik weet. En stel dat er een disk problemen heeft dan zou iig de andere array prima door moeten blijven draaien zou ik denken?

[ Voor 12% gewijzigd door bartvb op 29-12-2006 23:07 ]

[John2B]

Oh, vergeten te melden in mijn eerste post. De RAID10 bestaat uit twee 'oude' raptors en twee nieuwere. De oude disks zijn de WD740GD, de nieuwe de WD740ADFD maar ik neem aan dat dat niet de verklaring is voor deze beroerde prestaties.

Zou niet mogen uitmaken

Disks zijn allemaal OK voor zover ik weet. En stel dat er een disk problemen heeft dan zou iig de andere array prima door moeten blijven draaien zou ik denken?

Ja, inderdaad.

- Kan je de disk gegevens SMART uitlezen?
- Of iets in de log van de Areca zelf?



Disken kan je alleen los testen door ze aan het moederbord aan te sluiten op een SATA poort en met een WD tool te testen. Indien je alleen test en niets schrijft blijft de array gegevens gewoon op disk staan en kun je ze na het testen gewoon allemaal weer aansluiten en zal de array zo weer verder draaien.

[ Voor 3% gewijzigd door John2B op 29-12-2006 23:41 ]

[bartvb]

Via de CLI krijg ik alleen:

code:

CLI> disk smart drv=1
GuiErrMsg<0x02>: Invaild Data Returned From Rs-232.

Die melding krijg ik vaker in die CLI applicatie, dat heeft nooit gewerkt, ook niet toen de http proxy perfect functioneerde. Ik ga eens kijken via de serial console.

SMART ziet er allemaal perfect uit voor alle disks, niets speciaals in de logs, alleen wat reboots en initialisatie van de RAID die klaar is e.d. De oude raptors staan op SATA150, de nieuwe op SATA150+NCQ. De Deskstar 7K500's staan allemaal op SATA150+NCQ


'Disk Write Cache Mode' lijkt op 'Enable' te staan (lijkt want inverse video lijkt niet te werken waardoor vrijwel niet te zien is waar je in een menu zit). Ik neem aan dat het hier gaat om de 256MB cache op de kaart die ook gebruikt wordt voor writes? 'HDD Read Ahead Cache' staat op 'Enabled',

Alle RAID en Volume sets staan in een 'Normal' state.

RAID10 heeft een stripe size van 32KB, Block size van 512 Bytes, 4 disks, Cache Attribute staat op Write-Back en Tag Queuing op Enabled.
RAID5 heeft een strip size van 64KB, Block size van 512 Bytes, 4 disks, Cache Attribute staat op Write-Back en Tag Queuing op Enabled.
Er is ook nog een RAID10 op de 500GB disks met een stripe size van 64KB en verder dezelfde settings.

Lijkt allemaal dus normaal te zijn? Vreemde is dat ik zo geen verschillen zie tussen de 500GB en de 74GB raid sets.

Overigens is het zo dat het hele systeem enorm traag wordt als er b.v. een benchmark op de RAID10 draait. Het inlezen van b.v. vi van de RAID5 kost op zo'n moment enorm veel moeite, duurt soms een seconde of 5 voor er wat reactie komt. Scheduler staat voor alle volumes op deadline.

[ Voor 8% gewijzigd door bartvb op 30-12-2006 00:22 ]

[bartvb]

Als ik meekijk met vmstat tijdens het schrijven in de benchmark zie ik dit:

code:

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
1  1      0  50104  33728 7779356    0    0 58816 58018 1049 1047  0  4 66 30
 1  1      0  48964  33728 7780724    0    0   640     0  269  516  0  0 75 25
 1  2      0  48964  33740 7780784    0    0     0     4  254  511  0  0 70 30
 1  1      0  51892  33716 7777184    0    0 57664 58018 1056 1043  0  4 67 29
 1  1      0  51832  33716 7777244    0    0   128     0  255  511  0  0 75 25
 1  2      0  51832  33728 7777232    0    0     0     4  253  511  0  0 69 31
 1  1      0  49736  33724 7778960    0    0 58688 60918 1060 1036  0  3 72 25
 1  1      0  49316  33724 7779984    0    0   320     0  294  514  0  0 75 25
 1  1      0  52020  33724 7777292    0    0  2368  2086  286  543  0  0 65 35
 1  1      0  50112  33724 7779400    0    0 54976 53872 1016 1015  0  3 74 23
 1  1      0  50112  33724 7779532    0    0     0     0  254  509  0  0 75 25
 2  1      0  49272  33736 7780180    0    0 22400 22798  570  722  0  2 66 32
 1  1      0  49448  33736 7780272    0    0 36096 36290  752  832  0  2 74 23
 1  1      0  49448  33736 7780344    0    0     0     0  254  509  0  0 75 25
 3  0      0  51788  33728 7777496    0    0 39680 38220  763  868  0  3 74 23
 1  1      0  51124  33728 7778600    0    0 17600 19046  535  669  0  1 74 24
 1  2      0  51124  33740 7778588    0    0     0     4  254  513  0  0 71 29
 2  0      0  49556  33352 7780268    0    0 51264 51802  977  988  0  3 62 35
 1  1      0  50816  33224 7779044    0    0  8576  8288  370  592  0  0 75 25
 1  2      0  50816  33236 7779032    0    0     0     2  255  511  0  0 75 25
 1  1      0  50160  32676 7780188    0    0 52224 49744  966 1000  0  3 62 35
 1  1      0  52012  32668 7777888    0    0 12736 14504  446  623  0  1 74 24

Op de RAID5 ziet dit er een stuk logischer/gelijkmatiger uit:

code:

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 1  3      0 5645148  23868 2331540    0    0     4 117972 1291  599  0 11 37 52
 1  3      0 5645768  23868 2331484    0    0     0  1770  272  530  0  0 43 57
 1  3      0 5369488  24152 2605480    0    0     6 114264 1264  600  0  8 36 56
 1  3      0 5369612  24152 2605740    0    0     0  1092  266  557  0  0 41 59
 1  2      0 5098168  24424 2867612    0    0     4 118224 1344  816  0 11 39 50
 1  2      0 4838264  24676 3118376    0    0     2 98702 1157  770  0  9 59 32
 0  4      0 4566580  26740 3379948    0    0     4 24824  464  566  0  7 50 43
 0  4      0 4419516  26892 3521876    0    0     4 113032 1222  610  0  5 39 56
 1  3      0 4241204  27068 3694260    0    0     2 34578  567  572  0  4 39 56
 0  3      0 4013532  27296 3915216    0    0     4 110734 1215  627  0  7 47 46
 0  5      0 3877776  27428 4046412    0    0     2 21820  450  561  0  3 36 61
 1  5      0 3482340  27816 4428368    0    0     4 123604 1320  633  0 11 11 78
 0  5      0 3335516  27964 4569520    0    0     4 115070 1256  625  0  5 20 75
 0  5      0 3199860  28100 4700588    0    0     2 16628  384  573  0  3  1 96
 0  6      0 2801556  28504 5093784    0    0     6 112892 1278  700  0 14 26 60

Ik snap het dus niet echt :\

Sinds de reboot (om in de firmware te komen) gaat de benchmark van de RAID5 een stuk beter trouwens:

code:

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
gullfaxi        16G           79654  17 40820   6           100731  10 411.4   0

Misschien dat die partitie toch nog met 'sync' gemount was? Alles staat nu iig zeker op async.

[ Voor 7% gewijzigd door bartvb op 30-12-2006 01:02 ]

[John2B]

SMART ziet er allemaal perfect uit voor alle disks, niets speciaals in de logs, alleen wat reboots en initialisatie van de RAID die klaar is e.d. De oude raptors staan op SATA150, de nieuwe op SATA150+NCQ. De Deskstar 7K500's staan allemaal op SATA150+NCQ

Desktars..? je had toch 4 raptors in RAID10? Zet NCQ maar uit, werkt toch niet, en als het werkt alleen vertragend.

'Disk Write Cache Mode' lijkt op 'Enable' te staan (lijkt want inverse video lijkt niet te werken waardoor vrijwel niet te zien is waar je in een menu zit). Ik neem aan dat het hier gaat om de 256MB cache op de kaart die ook gebruikt wordt voor writes? 'HDD Read Ahead Cache' staat op 'Enabled',

Nee, om de disk cache gaat het hier.

DE Volume Cache Mode moet je op WRITE BACK zetten (mits je natuurlijk een BBU hebt) in RAID0 merk je daar niet veel van in RAID5 wel.

Je zult wel geen BBU hebben omdat de Areca dan by default staat op 'Disk Write Cache Mode' 'Enabled'

Je kunt de WRITE BACK wel even aanzetten om te kijken of dat een betere performance geeft.

Alle RAID en Volume sets staan in een 'Normal' state.

RAID10 heeft een stripe size van 32KB, Block size van 512 Bytes, 4 disks, Cache Attribute staat op Write-Back en Tag Queuing op Enabled.
RAID5 heeft een strip size van 64KB, Block size van 512 Bytes, 4 disks, Cache Attribute staat op Write-Back en Tag Queuing op Enabled.
Er is ook nog een RAID10 op de 500GB disks met een stripe size van 64KB en verder dezelfde settings.

Zet stripesize op 128KB, in alle situaties een iets betere performance.

Lijkt allemaal dus normaal te zijn? Vreemde is dat ik zo geen verschillen zie tussen de 500GB en de 74GB raid sets.

Overigens is het zo dat het hele systeem enorm traag wordt als er b.v. een benchmark op de RAID10 draait. Het inlezen van b.v. vi van de RAID5 kost op zo'n moment enorm veel moeite, duurt soms een seconde of 5 voor er wat reactie komt. Scheduler staat voor alle volumes op deadline.

Klinkt niet goed...

[Verwijderd]

Je zou eigenlijk met een livecd ofzo moeten kijken of het probleem zich ook dan voordoet, misschien is er iets met je linux install?

Ook vraag ik me af of je je volume gedisklabeled hebt, en welke offset je daarvoor gebruikt. Maar de 5 seconde vertraging die je noemde ik daarmee niet verklaren.

[ Voor 38% gewijzigd door Verwijderd op 30-12-2006 02:14 ]

[bartvb]

Ik heb 4 raptors in RAID10 en daarnaast 4 Deskstars met daarop een RAID5 en een RAID10 (voor de swap). 8 disks in totaal dus verdeeld over 2 raidsets met in totaal 3 volumesets.

Het lijkt er op dat alle caches die aan kunnen nu aan staan, wat reliability betreft niet helemaal handig, moet daar dus nog eens naar gaan kijken (heb wel een BBU), maar de performance zou met de huidige settings optimaal moeten zijn.

Een stripe size van 32kb vs 64kb mag wel wat verschil geven in performance maar geen factor 4 verschil zoals nu.

LiveCD is wat lastig want die kaart en dit moederbord draaien alleen of met 2.6.19 of met een gepatchte oudere 2.6 kernel. Ander (en groter) probleem is dat die machine in een rack in Amsterdam hangt en eigenlijk vandaag online moet :\

@Enlightenment: Wat bedoel je met disklabels en offsets?

Niemand die een nieuwere versie van archttp64 heeft liggen?


------

Net de controller verteld dat ik geen NCQ wil, lijkt niet echt te helpen, het lijkt eerder slechter te zijn geworden. Net weer bonnie opgestart en wilde ondertussen via ssh inloggen voor een extra sessie. Dat inloggen heeft meer dan een minuut (!) geduurd. Echt te bizar gewoon. Er lijken niet ongewoon veel interrupts te zijn:

code:

           CPU0       CPU1       CPU2       CPU3       
  0:      52644      52532      52483      52573   IO-APIC-edge      timer
  1:          0          0          1          1   IO-APIC-edge      i8042
  3:          3          1          1          1   IO-APIC-edge      serial
  4:         50         54         54         60   IO-APIC-edge      serial
  9:          0          0          0          0   IO-APIC-fasteoi   acpi
 12:          2          0          0          2   IO-APIC-edge      i8042
 14:         11          7         10          9   IO-APIC-edge      ide0
 16:      41997      41979      41992      41916   IO-APIC-fasteoi   arcmsr
 22:          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:usb2, uhci_hcd:usb4
 23:          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:usb1, uhci_hcd:usb3, ehci_hcd:usb5
373:        136        128        124        137   PCI-MSI-edge      eth1
374:        573        562        598        564   PCI-MSI-edge      eth0
NMI:        145         44         55         46 
LOC:     210148     210140     210107     210078 
ERR:          0

Dit is halverwege een run van bonnie met 16GB.

Resultaten van Bonnie zonder NCQ:

code:

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
gullfaxi        16G           24463   4 20488   3           93252   9 633.3   1

Nog steeds even beroerd dus.

[ Voor 55% gewijzigd door bartvb op 30-12-2006 12:09 ]

[Verwijderd]

bartvb schreef op zaterdag 30 december 2006 @ 10:14:
@Enlightenment: Wat bedoel je met disklabels en offsets?

Disklabelen is het aanmaken van een label op de disk zodat je verschillende 'partities' krijgt. Wellicht heet het anders in linux-land; ik ben alleen FreeBSD gewend. Kort gezegd heb je twee opties:
- fdisk en disklabel
- "Dangerously Dedicated"

Met de eerste optie maak je keurig een BIOS partitie aan (63 bytes offset geloof ik) en daarna kun je nog labelen om binnen je BIOS partitie ('slice' genoemd in BSD land) nog "BSD partities" te maken. Als ad0 je hardeschijf is, krijg je dan ad0s1 voor je 1e partitie en ad0s1a voor de partitie die je krijgt dmv disklabeling. Zo is ad0s1b bedoeld voor SWAP; etc. Als je dit niet slim doet, heb je een offset die niet gelijk is aan je stripesize en dat kan je performance hinderen. Maar dat zou niet zo extreem mogen zijn als in jouw geval, dus ik denk dat het probleem zich elders voordoet.

Ik denk wel dat je opzeker eens een andere distributie zou moeten proberen, of bijvoorbeeld FreeBSD die standaard de Areca-drivers in zich heeft en dus 'gewoon werkt'. Dan zou je bonnie kunnen draaien of met een simpele dd-bench kunnen testen of het met BSD wel goed werkt, zoals met:
dd if=/dev/da0 of=/dev/null bs=1m count=2000
Daarmee lees je 2000MB in en zal hij na afloop de snelheid van deze sequentiele transfer doorgeven. Dan kun je op een mounted partitie proberen door middel van:
dd if=/dev/zero of=/tmp/zerofile bs=1m count=2000
Dan schrijf je een 2000MB testfile weg in de /tmp/ directory.

Daarnaast wil ik opmerken dat het niet slim is om je server al in het rack te hebben gehangen voordat je deze op orde gemaakt hebt; hier kun je spijt van krijgen en is allerminst de veilige oplossing; ik zou het zelfs slordig willen noemen; wat als er met je config toch iets niet goed zit? Dat kan vervelende downtime tot gevolg hebben. Voordat je een productieserver in bedrijf neemt dien je eerst uitgebreid te testen, naar mijn mening dan.

[bartvb]

Dat disklabelen werkt in Linux idd wat anders, eigenlijk gewoon op de DOS manier. Op het moment heb ik 2 RAID sets aangemaakt op de Areca controller, 1x 4x500GB en 1x 4x74GB. Op die 4x500GB RAID set is een RAID5 gemaakt van 1.4TB en een RAID10 van 20GB. Op de 1x4x74 is een RAID10 aangemaakt van 140GB.

De RAID5 bevat twee partities, een /boot en / (/dev/sda1 en /dev/sda2), de andere twee zijn /dev/sdb1 en /dev/sdc1 Lijkt me dat dat iig niet de oorzaak is van de problemen

Server is uitgebreid getest voor deze naar de colo ging maar hier had ik geen 4xraptor zo op de plank liggen. Had er hier 2, de andere 2 zaten al in de oude DB server.

Overstappen naar b.v. FreeBSD is geen optie en is ook geen oplossing. Alles is gestandaardiseerd op Debian, niet handig om daar dan ineens een FreeBSD doos tussen te zetten. Linux heeft sinds 2.6.18 trouwens ook (eindelijk) standaard kernel support voor de Areca.

Ik ga de server volgende week maar eens streng IRL toespreken. Dan meteen kijken of die serial console instelling idd de oorzaak is van de archttp64 problemen is. Ook even 4 andere disks meenemen en kijken of die wel op een normalere snelheid willen functioneren in die bays (is een Chenbro RM215 kast) in RAID10 met dezelfde instellingen.

Het begint langzamerhand iig te lijken op een nogal vage interactie van vage driver en hardware bugs ofzo *grmbl* Allemaal nogal erg zonde van die 800 euro kostende controller

Ik ga eens kijken of mail wel doorkomt bij Areca. FTP en FAQ server van Areca zijn nog steeds onbereikbaar.

[n4m3l355]

Wat ik me afvraag of die schijven daadwerkelijk hetzelfde zijn. Je zei dat er twee nieuwere raptors in zitten is het niet mogelijk dat die ook van een nieuwere revisie zijn? Ik heb dat ooit eens meegemaakt met Maxtor schijven en dat vernachelde ook behoorlijk de prestaties. Die bleken van een verschillende rivisie te zijn (wel met dezelfde productie naam) en blijkbaar was er toch een minimaal verschil tussen de schijven.

[LosserNL]

Ik merk zelf ook een redelijke delay als ik de controller op beide raidsets op mijn Areca ARC-1220 aan het werk zet. Ik heb zelf 2xRaptor in RAID-1 voor het OS, en 2xRaptor in RAID-0 voor games en temp. Als ik dan bijvoorbeeld wat moet uitpakken van RAID-0 naar de RAID-1 array dan gaat dat niet vloeiend, maar volgens mij volt ie de cache vol, wordt die gedumpt, de cache wordt weer vol gegooid, etc etc. Dit ook als ik beide volume sets ga defragmenteren. Het is dan altijd de RAID-1 set die hangt, aangezien dan de Access LED's van beide schijven 5 seconden of langer vol branden terwijl er ogenschijnlijk niks gebeurd.

Is het aan te raden om Write-Through aan te zetten op RAID-1 en RAID-0 schijven om dit probleem wellicht te omzeilen? Volgens mij kakt de performance dan wel in elkaar namelijk.

Ik wil deze maand 3 of 4 schijven in RAID-5 op dezelfde controller hangen, maar als ik nu al problemen heb met 2 simpele raidsets en dito volumes, hoe gaat dat straks dan als de controller ook nog parity moet doen voor de 3e raidset?

Heb Firmware 1.42 en 1.41 gedraaid, en de combinaties met driver 1.20.0.13 en 1.02. Storport ook geprobeerd (draai XP x64) maar ook geen duidelijke verbetering. volgens mij is mijn probleem dus op zich vergelijkbaar met de topicstarter. Deadlocks als de cache volloopt waardoor er raid-sets onbereikbaar worden tot de cache leeg genoeg is?

[maratropa]

LosserNL schreef op maandag 01 januari 2007 @ 13:15:
Ik merk zelf ook een redelijke delay als ik de controller op beide raidsets op mijn Areca ARC-1220 aan het werk zet. Ik heb zelf 2xRaptor in RAID-1 voor het OS, en 2xRaptor in RAID-0 voor games en temp. Als ik dan bijvoorbeeld wat moet uitpakken van RAID-0 naar de RAID-1 array dan gaat dat niet vloeiend, maar volgens mij volt ie de cache vol, wordt die gedumpt, de cache wordt weer vol gegooid, etc etc. Dit ook als ik beide volume sets ga defragmenteren. Het is dan altijd de RAID-1 set die hangt, aangezien dan de Access LED's van beide schijven 5 seconden of langer vol branden terwijl er ogenschijnlijk niks gebeurd.

Is het aan te raden om Write-Through aan te zetten op RAID-1 en RAID-0 schijven om dit probleem wellicht te omzeilen? Volgens mij kakt de performance dan wel in elkaar namelijk.

Ik wil deze maand 3 of 4 schijven in RAID-5 op dezelfde controller hangen, maar als ik nu al problemen heb met 2 simpele raidsets en dito volumes, hoe gaat dat straks dan als de controller ook nog parity moet doen voor de 3e raidset?

Heb Firmware 1.42 en 1.41 gedraaid, en de combinaties met driver 1.20.0.13 en 1.02. Storport ook geprobeerd (draai XP x64) maar ook geen duidelijke verbetering. volgens mij is mijn probleem dus op zich vergelijkbaar met de topicstarter. Deadlocks als de cache volloopt waardoor er raid-sets onbereikbaar worden tot de cache leeg genoeg is?

Hetzelfde is hier ook goed merkbaar, Ik heb een cache+bbu van 128mb en je ziet bij grote bestanden dat het eerste gedeelte heel snel gaat en dan is de cache vol. Al heb ik dan niet onwijze vertragingen door het flushen van de cache daarna. Maar m'n cache is ook niet zo heel groot natuurlijk...Ik heb hier trouwens nog wel eens iemand horen klagen over dat soort "delays" op zijn areca.

[John2B]

LosserNL schreef op maandag 01 januari 2007 @ 13:15:
Is het aan te raden om Write-Through aan te zetten op RAID-1 en RAID-0 schijven om dit probleem wellicht te omzeilen? Volgens mij kakt de performance dan wel in elkaar namelijk.

Maar waarom zou je geen gebruikmaken van de aanwezige 128MB cache als het er toch op zit? WRITE THROUGH kan natuurlijk, in RAID0 en RAID1 zal je er in principe weinig voordeel mee hebben.

Ik wil deze maand 3 of 4 schijven in RAID-5 op dezelfde controller hangen, maar als ik nu al problemen heb met 2 simpele raidsets en dito volumes, hoe gaat dat straks dan als de controller ook nog parity moet doen voor de 3e raidset?

Die parity berekeningen worden dan geheel in het geheugen van de controller berekend en in 1x weggeschreven. Bij WRITE THROUGH worden de berekeningen per disk 1 voor 1 berekend en 1 voor 1 weggeschreven wat dus meer i/o opleverd en dus performance verlies t.o.v. WRITE BACK bij RAID5/6.

Heb Firmware 1.42 en 1.41 gedraaid, en de combinaties met driver 1.20.0.13 en 1.02. Storport ook geprobeerd (draai XP x64) maar ook geen duidelijke verbetering. volgens mij is mijn probleem dus op zich vergelijkbaar met de topicstarter. Deadlocks als de cache volloopt waardoor er raid-sets onbereikbaar worden tot de cache leeg genoeg is?

STOREPORT drivers op een XP X64..? Ik weet dat met STORPORT drivers onder Windows er eerst een patch moet worden geinstalleerd. Ik weet niet of dat ook voor the XP x64 geld...misschien het uitzoeken waard. Want de STORPORT heeft grote voordelen t.o.v. SCSIPORT driver.

http://www.microsoft.com/...landeploy/storportwp.mspx

The Scsiport driver, however, was designed to work optimally with the parallel SCSI interconnects used with direct attached storage. It was neither designed to meet the high performance standards of Fibre Channel SAN configurations, nor to work well with hardware RAID.

In addition to the ScsiPort driver, Microsoft Windows Server 2003 and later versions provide Storport (storport.sys), a storage port driver that is especially suitable for use with high-performance buses, such as Fibre channel buses, and RAID adapters.

The difference is the mini-port driver is layered between the NT SCSI port driver and the adapter. Its limitations come from the NT SCSI Port driver (ex. number of LUN's per target).

There are several advantages to using Storport rather than the ScsiPort driver:

· Improved miniport interface that addresses the needs of high-end storage vendors, particularly host-based RAID and fibre channel vendors.
· Improved performance, both in terms of throughput and the system resources that are utilized. The Storport driver should also perform on a par with, or better than, a monolithic port driver.

All vendors are encouraged to use Storport where possible, rather than the ScsiPort driver. Both Scsiport and Storport driver can be used on Windows 2003.

Windows 2003 has a bug on the system Storport driver before, please make sure your system having the Storport.sys hotfix before using Storport driver.

You can find the hotfix in Microsoft official site.

[LosserNL]

Storport werkt op XP x64 omdat deze dezelfde kernel gebruikt als Windows 2003. Ik heb inderdaad de hotfix moeten toepassen voor de Storport driver goed werkt

Met Write-Through gaat de performance van writes op de RAID-1 array onderuit van ongeveer 400MB/sec naar 9MB/sec (gemeten met ATTO, ook al is deze tool met 256MB cache beetje obsolete ) Dat laat ik dus voorlopig even schieten.

Vrijdag krijg ik 4 WD Caviar RE2 500GB schijven binnen die in RAID-5 gaan draaien. Ik zal dan even bekijken hoe de performance is als ik veel tussen de 3 raid-sets ga kopieren enzo.

[John2B]

Ik heb net 31GB van de ene RAID5 array naar de andere RAID5 array overgezet, merk niets van delays en kan ongestoord doorwerken.

[bartvb]

De raptors zijn idd niet helemaal het zelfde (zoals ik hierboven ook al zei:

De oude disks zijn de WD740GD, de nieuwe de WD740ADFD...

Ik ben nu in de colo, Ik ga maar eens kijken of het wel goed werkt in RAID10 met 4 exact dezelfde disks (4 250GB WD schijven). Eerst zorgen dat archhttp64 weer werkt :\ Zonder dat moet die machine nog lang plat en dat is geen optie op het moment.

-------

Grrr! Het werkt nu, of ja, ik kan archttp64 weer gebruiken. Het probleem met archttp64 was opgelost toen ik getty op de seriele poorten afschoot :\ Echt _te_ vaag gewoon. Tot nu toe ben ik iig nog niet bepaald onder de indruk van de Areca :\ Rare drivers, vage support, onvoorspelbare performance, support tools die niet of maar half werken

Nu door met het 4xRaptor verhaal.

[ Voor 32% gewijzigd door bartvb op 03-01-2007 12:53 . Reden: Toevoegen oplossing archttp64 probleem ]