ungewöhnlich hohe auslastung bei dd

M

mapet

Active OpenBSD User
hallo zusammen,

ich hab mir hier ein freebsd 6.2-release system aufgesetzt, was schon bei der installation ungewöhnlich langsam war (kernel laden, base installieren, etc.). auch das starten der maschine glich eher der eines 486er als der eines dual-p3 mit jeweils 867mhz. in der kiste steckt ein LSI MegaRAID-SATA-150-4 controller drin, der sich folgerndermaßen in der dmesg meldet:
Code: 
amr0: <LSILogic MegaRAID 1.53> mem 0xfc5f0000-0xfc5fffff irq 27 at device 2.0 on pci1
amr0: delete logical drives supported by controller
amr0: <LSILogic MegaRAID SATA 150-4D> Firmware 713R, BIOS G121, 64MB RAM

daran hängen 4 seagate SATAs die jeweils auf SATA-II gejumpert sind und in einem RAID-5 verbund hängen:
Code: 
amr0: delete logical drives supported by controller
amrd0: <LSILogic MegaRAID logical drive> on amr0
amrd0: 915723MB (1875400704 sectors) RAID 5 (optimal)

bei einem "dd if=/dev/zero of=test.tmp bs=65536 count=32768" finde ich die top-anzeige allerdings mehr als ungewöhnlich, zumindest ist die auslastung sehr hoch:
Code: 
last pid:   807;  load averages:  0.87,  2.05,  1.60            up 0+00:51:34  16:36:32
25 processes:  2 running, 23 sleeping
CPU states:  0.5% user,  0.0% nice, 68.2% system, 28.2% interrupt,  3.1% idle
Mem: 10M Active, 628K Inact, 43M Wired, 48K Cache, 111M Buf, 943M Free
Swap: 2048M Total, 2048M Free

ich finde die system- und interruptauslastung für ein wenig plattenschreiben ungewöhnlich hoch. auch der durchsatz lässt keine SATA-laufwerke erahnen:
Code: 
[marc@backup ~]$ dd if=/dev/zero of=test.tmp bs=65536 count=32768
32768+0 records in
32768+0 records out
2147483648 bytes transferred in 610.038600 secs (3520242 bytes/sec)

ist das nun ein configfehler meinerseits, oder ist der treiber nicht so dolle?

das ganze hockt auf einem tyan s2510 board, das 64bit/66mhz pci-slots bereithält und auch entsprechend gejumpert ist. die blockgröße für die stripes auf der karte sind mit 64k angegeben.

bin dankbar für tipps...
 

Anhänge

  • dmesg.txt
    4 KB · Aufrufe: 337
Wie es scheint ist das ein Billig-Controller der die ganze Arbeit im Treiber von der CPU machen lässt. Da kann man nicht viel machen, außer vielleicht auf Raid-5 verzichten.
 
also billig würd ich den controller nun nicht nennen und lsi hat auch spezielle treiber für fbsd (zumindest ist in release ein treiber vorhanden). der computer ist in allem langsam, sei es hochfahren (5 min wall-clock-time) oder sonstigen sachen. er scheint irgendwie allgemein lahmarschig zu sein... das ist für fbsd nicht normal...

EDIT: es ist ein echter hardware-controller, weil darauf hab ich beim kauf wert gelegt
 
Zuletzt bearbeitet:
Hardware-Raid-Controller, vor allem in der unteren Preisklasse können langsamer sein als Software-Raid. Wenn du auf den Platten noch keine Daten hast, könntest du vielleicht mal Sotware-Raid testen.
 
Ich wollte nachher mal schauen, ob ich vielleicht nicht doch nen jumper irgendwo falsch gesetzt habe und vielleicht nochmal das bios löschen und neu einstellen... irgendwas ist an der ganzen kiste komisch und das wurmt mich. die installation von freebsd hat 3 stunden in anspruch genommen... es ist ja nciht so, das nur die platten langsam beschrieben, das ganze teil ist zu langsam... mal sehen, vielleicht hat der auch die 512mb zusätzlichen ram in dem slot nicht so richtig vertragen...
 
okay, ich depp hatte wohl im bios was eingestellt, was er nicht so ganz vertragen hat:
Code: 
last pid:   703;  load averages:  0.45,  0.20,  0.08                 up 0+00:01:49  16:23:23
29 processes:  1 running, 28 sleeping
CPU states:  0.0% user,  0.0% nice,  6.0% system,  0.9% interrupt, 93.1% idle
Mem: 8936K Active, 179M Inact, 74M Wired, 60M Buf, 232M Free
Swap: 2048M Total, 2048M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
  694 marc        1 -16    0  3320K  1688K wdrain 1   0:03  8.87% dd

der durchsatz ist zwar immernoch nicht so der hammer, aber immerhin ist die kiste wieder bei "normaler" geschwindigkeit...

EDIT: es scheint, dass man mit einer MegaRAID-Karte entweder nen RAID oder gar nichts machen kann... auch nicht schlecht :/
 
Zuletzt bearbeitet:
thorben schrieb:
moin,
hast du batteriemodul drauf?

gruß
thorben
Zum Vergrößern anklicken....

nein, ist auch nicht optional vorgesehen bei der karte... ich frage mich, ob ich nicht die caches aktivieren sollte, um wenigstens etwas mehr geschwindigkeit zu erhalten... wenn der was aus den ports bauen muss, dauerts sehr lange und die kiste hängt eh an einer usv...
 
Heißt das, du hast den Cache deaktiviert? Wenn ja, welchen? Von der Festplatte?

Wie kommt man auf so eine Idee?
 
weil es eigentlich ja aufgabe des filesystems ist, sich um die integrität der daten zu kümmern. wenn das filesystem meint, es hätte daten geschrieben, der controller hat die aber noch im cache und sie sind nicht geschrieben, kann sein, dass nachher inkonsistenzen entstehen (z.b. bei journaling). ich werd den cache mal von writethruh auf writeback umstellen und sehen, obs was bringt :-S
 
Soweit ich den Tenor (das taucht ja öfter mal in der Mailingliste auf) mitbekommen habe, ist die Empfehlung den Write-Cache abzuschalten inzwischen obsolet. Die Kapazität der Kondensatoren aktueller ATA Festplatten reichen normalerweise aus um die gecachten Operationen abzuschließen.

Quellen kann ich blöderweise nicht nennen, wenn es also um einen wichtige Kiste geht, würde ich nochmal Nachforschungen anstellen.
 
also ich probiers mal mit angeschalteten caches (platten und controller) und schau mal, was das gibt... da ne usv das ganze absichert sollte eigentlich nichts passieren, es sei denn, der network ups daemon funzt nicht richtig.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben