[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Aktionen auf der Festplatte erzeugt sehr hohe load



Am 26.05.07 schrieb Gerhard Brauer <gerhard.brauer@web.de>:
Gruesse!
* Hermann wacker <hugendubel@gmail.com> schrieb am [26.05.07 00:38]:
>
> Hardware ist ein Pentium D 2,8 GHz HT auf einem Asus P4C800 mit Intel
> Chipsätzen (weiß leider nicht wie die heißen) nebst zwei 40 GB IDE
> Seagates, die ich komfortabel per Installer zu einem Software Raid
> zusammengebacken habe.

Welcher RAID-Level wäre noch interessant gewesen.

Ups, stimmt natürlich. RAID-1 Also mirroring.


> Ich vermute also das etwas mit den IRQs sehr im argen liegt, aber ich
> weiß überhaupt nicht wie ich das prüfen könnte.

cat /proc/interrupts zeigt die Belegung, und welche Devices sich
Interrups teilen müssen.

Sieht ganz OK aus, finde ich:

cat /proc/interrupts
          CPU0       CPU1
 0:     844669          0    IO-APIC-edge  timer
 1:          8          0    IO-APIC-edge  i8042
 6:          3          0    IO-APIC-edge  floppy
 7:          0          0    IO-APIC-edge  parport0
 8:          1          0    IO-APIC-edge  rtc
 9:          1          0   IO-APIC-level  acpi
12:        104          0    IO-APIC-edge  i8042
14:     314177          0    IO-APIC-edge  ide0
15:     310761          0    IO-APIC-edge  ide1
169:          0          0   IO-APIC-level  uhci_hcd:usb1, uhci_hcd:usb4
177:          0          0   IO-APIC-level  uhci_hcd:usb2
185:          0          0   IO-APIC-level  uhci_hcd:usb3
193:          0          0   IO-APIC-level  ehci_hcd:usb5
201:       8879          0   IO-APIC-level  skge
209:          3          0   IO-APIC-level  ohci1394
217:          0          0   IO-APIC-level  Intel ICH5
NMI:          0          0
LOC:     844585     844584
ERR:          0
MIS:          0




> das einzige das ich anbieten kann ist ein
> hdparm -i /dev/hda (bzw. hdb)

Da habe wir den Übeltäter ;-)
[..]
Du erhälst dann hda und hdc.

Also ich kann mal mitteilen was so alles passiert ist.
Ich habe zum testen jeweils 60 sekunden lang cat /dev/zero > nullen
ausgeführt und dabei die load beobachtet.

Das hab ich auf drei Rechnern gemacht, mein debian sarge auf einem 900
MHz Pentium 2 machte dabei auf seiner IDE Platte eine Load von 2.09,
auf dem SCSI RAID-1 2.30.
Der zweite Rechner ist ein Root Server bei Hetzner, ein AMD 3800+ X2
Dual Core mit einem 300 GB S-ATA RAID-1  (debain etch). Der brachte es
auf eine Load von 7.13 und war damit nach 60 Sekunden fast tot :(
Der dritte ist besagter P4 2.80 GHz HT mit zwei 40 GB IDEs im RAID-1.
Dem hab ich mal die Slave Platte einfach weggenommen, da kam er auf
eine load von 2.34, nachdem ich beide als Master gejumpert und
angeschlossen hatte, kam er auf 2.18 oder so.
Trotzdem hat sich etwas deutlich verändert, der Rechner ist nicht mehr
sekundenlang "eingefroren", wo top 10 bis 15 Sekunden brauchte um die
neuen Werte anzuzeigen und ein einfaches ls -lah sofort kam.

Nachdem was ich jetzt so bei meinen Spielereien erfuhr, muß ich wohl
oder übel damit leben das intensives schreiben auf den Festplatten
dazu führt das ein handelsüblicher PC unter Linux (unter Windoze lässt
sich das irgendwie schlecht messen) spürbar Leistung einbüßt und somit
schauen das sich das meiste im RAM abspielt. Mal sehen wie ich das
hinbekomme.

Inwieweit das Umhängen deine Installation beeinflußt kann ich nicht
sagen, hängt von deiner Raid-Konfig ab. Ich würde mich also auf eine
Neuinstallation vorbereiten.

Der Debian Etch Installer hat das sehr sauber gelöst indem er die uuid
des Superblocks benutzt und es so ziemlich wurscht ist an welchem Bus
die Platte hängt.

Ansonsten brauchen wir mehr Infos übers Raid.

Als Slave-Geräte nimmt man üblicherweise CD-Roms, etc, die bei einem
konkurrierenden Zugriff halt auch mal warten können.

> Liebe Grüße
> Hermann Wacker

Gruß
        Gerhard
--
rm -rf DOESN'T mean:
read mail -really fast





Reply to: