Re: OOM killer schießt mein System ab (XEN Problem?)
Hallo
On Friday 05 July 2013 15:05:40 Christian wrote:
> Hallo,
> >
> > Da hast du dein Problem schon selber beschrieben.
> > Aus irgend einem Grund ist der Zugriff auf eine Raidhälfte nicht möglich.
> > Der timeout liegt bei 120 Sec. und kann mit
> > echo 0 > /proc/sys/kernel/hung_task_timeout_secs
> > auf Null gesetzt werden. Achtung! Dann hast du aber gleich bei dem ersten
> > Hänger ein degraded Raid!
>
> Das bedeutet, dass, sobal ein Task nach 0 Sekunden die Disk als defekt
Genau. Du kannst auch 60 oder 30 Rein schreiben.
> markiert, oder wie? Kann ich das auch "pro Array" oder "pro Diak" machen
> (vgl unten)?
Meinss Wissens geht das nicht. Ich würde aber jetzt nicht meine Hand dafür ins
Feuer legen.
> > Deine hohe last, also das scheinbare eingefroren sein, Rührt also von den
> > Prozessen die auf IO warten. Das ganze schaukelt sich mit der Zeit hoch.
> > Das würde auch erklähren warum Das System nicht Swapt. Es kann nicht weil
> > es nicht an die Platte kommt.
> > Warum allerdings der oom Killer zu schlägt, kann ich in dem Zusammenhang
> > nur vermuten. Mglw. Schaukeln sich so viele wartenden Prozesse hoch das
> > der RAM aus geht?
>
> Dazu noch eine kleine Erläuterung:
> Ich habe 3 Haupt-HDs. Auf jeder Platte befinden sich rd. 7GB Swap, eine
> Partition für RAID5 (root) und eine weitere Partition für RAID5, die
> zusammen ein PV bilden.
> Zusätzlich gibt es nich ein weiteres Array mit 2 Platten (auch Level 5,
> damit ich's ggf leicht erweitern kann), die das zusammen als statische
> Partition das Backup zur Verfügung stellen. Auf den Backup Platten ist
> KEIN Swap vorgesehen. Es gibt noch eine kleine IDE Platte aus alten
> Zeiten, die auch noch ein GB Swap oder so hat.
Wie arbeitest du auf dem Raid5 weiter? LVM und dann die LV's als Blockdevice
an die domU's weiter reichen? Oder Machst du immagedateien für die domU's?
Wie sich Raid5 von der Perfomance verhält kann ich nicht sagen. damit habe ich
keine Erfahrung.
Eine Lösung mit der ich seit Jahren gut fahre ist die (stark zusammengefasst):
- Keine dienste auf der dom0. Alles in domu's
- von allen Platten die ich habe, kommen zwei Gleich große in die ersten
beiden Slots, der Rest dahinter.
- auf den ersten beiden Platten kommt ein Raid1 mit vielleicht 20GB für die
Dom0. Der rest wird für LVM partitioniert.
- Je nachdem wieviel Plattenplatz wofür man braucht, kann man die LVM
Partitionen zu einem großen PV zusammen fassen oder eben unterteilen.
- Die einzelnen LV's als Blockdevice direckt an die DomU weiter geben. Das ist
auf jeden Fall performanter als ein Immage.
> Ich weiß, dass eine der beiden Backup Platten nicht mehr richtig mag. Sie
> ist mal zu heiß geworden und zeigt seither im SMART einen Fehler. Daher
> wäre meine Vermutung dass es genau diese Platte ist, die Probleme macht.
Wenn du diese Platte weg lassen kannst dann tu das mal und schau wie sich das
System dann verhält.
> Wenn ich das richtig verstehe, müsste doch dann aber die anderen Platten
> trotzdem laufen, oder nicht? Der Swap wäer weiterhin erreichbar.
Jain. wenn das System zuerst auf eine Platte swappen will die gerade schlechte
Performance auf weist, dann kann es schon sein das sich alles verhäddert. IO
ist nunmal ein übler Lasterzeuger und wenn es Prozesse gibt die Speicher
allocieren wolle, hinten drann aber gerade das Swappen harkt, dann kommt das
System schnell ins stocken.
> Gibt es eine Möglichkeit, nachzuweisen, dass das das Problem ist?
> Was kann ich dagegen machen?
Indirekt. Wenn du eine Platte her nimmst, von der du weißt das sie ok ist, und
diese nur zum Swappen benutzt und alle anderen Swappartitionen weg lässt, dann
sollte Swappen kein Problem mehr sein. Aber auch hier muss man auf passen.
Wenn z.B. so viele Prozesse auch IO warten, das alle CPU Kerne damit
beschäftigt sind, dann muss u.U. auch das Swappen warten und es geht wieder
alles in die Knie.
> PS: Was bedeutet, "das der RAM ausgeht"? Wie ist das mit dem Cache? Kann
> der nicht genutzt werden? Laut atop war noch ein oder zwei Minuten vor dem
> Crash 400MB Cache frei und Er hat auch keine HD aktivitäten davor (1-2%
> höchstens). Da müsste also schon einiges kommen, dass das sich so schnell
> hochschaukelt.
Der Cache ist für Platten IO. Der wird nach bedarf frei gemacht und auf die
Platte geschrieben. Kann aber nicht, oder nicht so schnell auf die Platte
geschrieben werden, dann verschwindet der Cach auch nicht.
Könnte ein Indiz darauf sein das was mit den Platten nicht stimmt.
Konntest du im Fehlerfall den dmesg aufrufen? was hat der gezeigt?
> Kann das mit XEN zu tun haben? Ich habe wie gesagt bisher immer auf bare
> Hardware gearbeitet und nie derartige Probleme gehabt.
Glaub ich nicht. Von allen Virtualisierungen finde ich Xen die performanteste.
(subjektiver Eindruck).
Ich denke eher das hier eine Fehlerhafte Platte alles in den Tod reißt.
Zumindest weisen für mich die indizien darauf hin die du genannt hast.
Wie viele CPU's weißt du den DomU's zu?
Kannst du im Fehlerfall noch xm top aufrufen?
Wenn ja, was zieht die meiste CPU-Last?
Du schriebst auch das der oom Killer den syslogd ab schießt. Das weißt darauf
hin das irgendwas so dermaßen viel logt, das der syslogd viel zu tun hat bzw.
viel Speicher allokiert, weil er die empfangenen Daten nicht schnell weg
schreiben kann (weil eben die IO das gerade nicht her gibt).
Gruß,
Heiko
Reply to: