Re: Aktionen auf der Festplatte erzeugt sehr hohe load
Gruesse!
* Hermann wacker <hugendubel@gmail.com> schrieb am [28.05.07 23:38]:
> >> 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 ist natürlich eine erhebliche Belastung, bei dem die Load per se
immer über 2 liegen muß. Der cat-Prozeß muß immer darauf warten, daß die
langsamen HDs irgendwann die Nullen auch wegschreiben. Die Load tritt
dann - je nach RAM-Ausbau - früher oder später auf.
Wenn du dir die Größe der entstandenen Datei mal anschaust dürften da
etliche GB angefallen sein.
> 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 :(
So ein Test ist aber IMHO weitab von dem, was täglich so anfällt. Jetzt
nicht das Volumen des Transfers, sondern eher die Größe der Datei(en)
und die Art der Erzeugung. Wenn wirklich viel mit großen Dateien
umgegeangen wird kommt es auch noch auf das verwendete Dateisystem mit
an. Und selbst bei ext{2|3} kann man noch einiges drehen - aber
irgendwann müssen alle Daten mal durch den Flaschenhals
BUS->Festplatten.
> 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.
Das war aber auch zu erwarten. Dein Raid-Level besagt ja, das beide
Platten synchron geschrieben werden. Wenn jetzt durch das
Master/Slave-Problem der Slave warten muß ist dein Raid zeitweise quasi
inkonsistent.
> 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.
Durch viel RAM ;-)
Aber wie gesagt - auch wenn durch Caching dem Kernel die Entscheidung
überlassen werden kann, wann er gecachte Daten wegschreibt: irgendwann
müssen sie geschrieben werden.
Dann kommt wieder ins Spiel: Chipsatz des Boards, Bussystem, Platten.
IDE ist unterste Stufe.
SATA besser, aber ich glaube nicht alle Kontroller/Platten unterstützen
z.B. dieses TaggedQueueing (also grob das die Platten sagen: so, der Bus
ist jetzt frei, es kann auf eine andere Platte geschrieben werden. Bei
IDE ist das - ähnlich wie bei HUBs im Netzwerk(Collisions) - mehr oder
weniger dem "Zufall" überlassen.
SCSI ist IMHO (ich bin kein Hardware-Experte) immer noch erste Wahl -
aber auch zu einem Preis. Und da wird man auch nicht mit Software-raid
arbeiten, in dieser Liga ist echtes Hardware-Raid mit eigenem RAM-Cache
angesagt.
Aber entscheidend ist doch eher, was deine Systeme täglich leisten
sollen: ein Web-Server z.B. wird selten Dateien von mehreren GB erzeugen
bzw. schreiben müssen.
Evtl. ist ein Test wie bonnie bzw. bonnie+ für deine Umstände
aussagekräftiger.
Gruß
Gerhard
--
A: Weil es die Lesbarkeit des Textes verschlechtert.
Q: Warum ist TOFU so schlimm?
A: TOFU
F: Was ist das groesste Aergerniss im Usenet?
Reply to: