Toon posts:

Highpoint 2220 langzaam (debian)

Pagina: 1
Acties:

Verwijderd

Topicstarter
Ik heb onlangs een Highpoint 2220 gekocht om een betaalbare fileserver te maken. Nu heb ik een aantal schijven in RAID5 draaien maar de snelheid bij het lezen is ver te zoeken.

Ik heb vier hdd's draaien in een RAID5 array met WB cachepolicy. Wanneer ik via hdparm -tT /dev/sda draai komt de performance niet hoger dan 70mb/s (met verify uit) en caching niet boven de 500mb/s

Highpoint 2220 bios 1.05
Tyan MP 1gb ECC ram
Dual 2000+mp (geen xp)
Samsung 500gb HD501LJ

Debian 3.1 2.6.10 #1 SMP i686
highpoint bios 1.05
highpoint driver (opensource) 1.07 (via kernelpatch)

Heeft iemand een idee waarom de schijven zo langzaam zijn?

Verwijderd

Welke bus/interface? PCI, PCI-X of PCI-express?
Deelt de controller IRQ's met andere devices?

Verwijderd

Topicstarter
Verwijderd schreef op woensdag 21 maart 2007 @ 18:57:
Welke bus/interface? PCI, PCI-X of PCI-express?
Deelt de controller IRQ's met andere devices?
controller is pci-x

op dezelfde irq zit 'smp_affinity'

Verwijderd

Welke snelheid krijg je met:

dd if=/dev/<RAID VOLUME> of=/dev/null bs=128k count=81920

Dat is een 'raw read' dus zonder read-ahead. Leest in totaal 10GB. <RAID VOLUME> moet je dus aanpassen aan de naam van je volume, dat weet je vast wel. :)

Verwijderd

Topicstarter
dd if=/dev/sda1 of=/dev/null bs=128k count=81920
81920+0 records in
81920+0 records out
10737418240 bytes transferred in 142.591941 seconds (75301719 bytes/sec)

dus dat is ongeveer 71 mb/s

[ Voor 8% gewijzigd door Verwijderd op 21-03-2007 19:16 ]


Verwijderd

en als je dit uitvoert op een mounted volume (met read-ahead), dus b.v.:

// bestand schrijven
dd if=/dev/zero of=/mnt/volume/10Gfile bs=128k count=81920

// en weer lezen
dd if=/mnt/volume/10Gfile of=/dev/null bs=128k count=81920

Dan krijg je ook meteen de schrijf-snelheid te zien. Ik ga er hierbij vanuit dat /mnt/volume de mountpoint is van /dev/sda1.

Verwijderd

Topicstarter
bestand schrijven:
dd if=/dev/zero of=/data1/10Gfile bs=128k count=81920
81920+0 records in
81920+0 records out
10737418240 bytes transferred in 261.698049 seconds (41029799 bytes/sec)

bestand lezen:
dd if=/data1/10Gfile of=/dev/null bs=128k count=81920
81920+0 records in
81920+0 records out
10737418240 bytes transferred in 146.318547 seconds (73383850 bytes/sec)

  • dupondje
  • Registratie: Augustus 2003
  • Laatst online: 20:45

dupondje

Powa 2 Tha PPL :)

Ik heb dezelfde controller in een Linux systeem (debian amd64) en driver crast wel elke week. Telkens gaat server down, en moet ik server hard rebooten :( HATELIJK ! En geen oplossing van HighPoint, ze hebben nu al 3x driver updated door errors die ik mail :(

Verwijderd

@denblom, het ziet er dus naar uit dat je controller met 71MB/s leest en met 40MB/s schrijft. Is dat misschien niet de performance die deze kaart hoort te halen? Heb je benches van een RAID5 config met deze kaart waarin veel hogere scores gehaald worden?

Welke stripesize heb je gebruikt trouwens?

Edit: nu ik eens kijk naar je processor; een Athlon MP 2000+ draait op 1.67GHz als ik me niet vergis, met 0,18µ procede. Ik kan me goed voorstellen dat deze maar een beperkte performance kan leveren aan de Highpoint-driver; want deze controller valt in de klasse hardware-assisted an leunt dus nog steeds voor een groot deel aan de driver.

Je zou eens via "top" kunnen controleren of tijdens het lezen en/of schrijven de CPU belasting niet tegen de 100% aanloopt.

[ Voor 43% gewijzigd door Verwijderd op 21-03-2007 21:20 ]


Verwijderd

Topicstarter
Ik loop met hdparm wel tegen de 99.9% van m'n cpu aan maar via dd niet (ik ken de werking van dd ook niet qua cpu belasting).

Ben net weer aan het toppen 8)7 en cpu load is nu stabiel rond de 50% met hdparm

[ Voor 25% gewijzigd door Verwijderd op 21-03-2007 23:41 ]


Verwijderd

hoeveel is het via DD dan? en heb je zowel raw (directe) als op een mounted volume gemeten welke cpu belasting je krijgt? Ben wel benieuwd, en natuurlijk maakt lezen of schrijven ook uit. Misschien dat je daarover nog wat nummertjes kunt verzamelen.

Verwijderd

Topicstarter
Verwijderd schreef op woensdag 21 maart 2007 @ 23:39:
hoeveel is het via DD dan? en heb je zowel raw (directe) als op een mounted volume gemeten welke cpu belasting je krijgt? Ben wel benieuwd, en natuurlijk maakt lezen of schrijven ook uit. Misschien dat je daarover nog wat nummertjes kunt verzamelen.
rond de 40% load is het bij het schrijven met uitschieters naar 60%
rond de 30% load is het bij het lezen stabiel.

Verwijderd

40% cpu utilization houdt dus wel in 80% op 1 core. Met uitschieters; het is dus niet onaannemelijk dat je CPU hierbij bottleneck is. 30% zou op 60% neerkomen en dat is vreemd als CPU toch bottleneck zou wezen. Mijn gevoel zegt dat je leesprestaties een stuk hoger zouden kunnen zijn.

Over de metingen, die heb je met top gedaan he? Dus bijvoorbeeld een regel als:
CPU states: 0.4% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.2% idle

Dan is in dit geval de utilization 100 - 99,2 = 0.8%. Je moet niet (alleen) naar de load van het DD-proces kijken. Daarin zitten interrupts namelijk niet verwerkt.

Heb je misschien de mogelijkheid de kaart in een ander systeem uit te proberen?

Verwijderd

Topicstarter
Ik heb nog een tyan mpx liggen met dual 1800+ maar daarop zou ik de kaart kunnen proberen maar dan moet ik een nieuwe kernel maken voor dat bord (kan dezelfde kernel van de mp gebruiken maar denk niet dat het goed gaat werken).
Verwijderd schreef op woensdag 21 maart 2007 @ 21:14:
Welke stripesize heb je gebruikt trouwens?
Ik heb de standaard variant gebruikt denk ik. Kan ik dit nog zien want heb het dus niet opgeschreven.

[ Voor 37% gewijzigd door Verwijderd op 22-03-2007 11:55 ]


Verwijderd

Kun je het kaartje niet in een normaal PCtje met moderne processor (athlon 64, Core 2 Duo) steken om te zien of je dan hogere performance haalt? Ook al draait het dan via PCI ipv PCI-X.

Verwijderd

Topicstarter
Verwijderd schreef op vrijdag 23 maart 2007 @ 12:20:
Kun je het kaartje niet in een normaal PCtje met moderne processor (athlon 64, Core 2 Duo) steken om te zien of je dan hogere performance haalt? Ook al draait het dan via PCI ipv PCI-X.
Dat word een probleem omdat die pci-x kaart zo'n langere pci is. zo'n pci 64 die op 3.3 en 5volt werkt. Heb ook niet nog een pci-x bord liggen buiten de Tyan mpx om dan.

Op m'n werk gebruiken wij een Areca kaart met pci-e x8 deze kaart heeft ingebouwde cache :( . Nu vertelde mijn collega mij dat deze kaart de cpu niet stressed en dat het daarom zo'n hoge performence haalde in vergelijking met mijn kaart. (areca van m'n werk trekt 270mb/s).

[ Voor 22% gewijzigd door Verwijderd op 24-03-2007 21:25 . Reden: typo ]


  • Laurent
  • Registratie: Oktober 2000
  • Niet online
PCI-X is prima backwards compatible als ze ook op 5V kunnen werken, zie ook PMG FAQ :)
Pagina: 1