Re: OOM killer schießt mein System ab (XEN Problem?)
On Saturday 06 July 2013 14:21:26 Christian wrote:
> Hallo noch mal,
>
> mir ist da noch was ein-/aufgefallen.
>
> vom Friday 05 July 2013 16:05:11:
> > > 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.
>
> Soll ich die Platte ausbauen oder reicht es, auszubinden?
Aushängen sollte schon reichen. Es geht nur darum das keine Zugriffe auf die
Platte gemacht werden.
>
> > > 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.
>
> Wenn es an einer hohenm IO Last hängen würde, müsste doch das an Aktivität
> der Platten erkennbar sein. Diese sind nämlich komplett rugig und geben
> keinen Mucks von sich.
Das stimmt. Allerdings kann ich dir auch nicht sagen wie sich das im Raid5
genau verhält wenn eine von 3 Platten wegen einem Defekt bremst.
Ich habe halt im software raid1 schon beobachtet das wenn eine Platte langsam
wird es das gesammte Raid mit der zeit aus bremst. Erst las ich diese eine
Platte auf faulty gesetzt habe lief es wieder.
Das war aber auch ein Einzelfall bei dem die Platte zunächst keine IO Fehler
gemacht hat sondern einfach nur langsam wurde.
Hast du vielleicht ein cacti als monitoring in dem u.A. IO der Platte
aufgezeichnet wird.
> > > 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.
>
> Moment: Warum lässt der Kernel so viel zusammenkommen, dass der halbe RAM
> "dirty" ist? Wenn ich im laufenden Betrieb die caches droppen lasse (echo 3
>
> >/proc/sys/vm/drop_caches) ist kaum was passiert. Erst ein sync zuvor leert
>
> den Cache. D.h. der Großteil von dem Cache ist noch nicht auf der Platte.
> Ich habe mal die dirty_Ratio und dirty_background_ratio reduziert (50 bzw
> 10), jetzt wirkt ein leeren des Caches auch massiv.
>
> Laut der Doku des Kernels wird, sobald dirty_ratio erreicht wird alle
> Zugriffe auf virtuellen Speicher synchron ausgeführt. Also werden
> schreibende Zugriffe direkt auf die HD geschrieben, bis sich die Situation
> entspannt hat.
>
> Das spricht dagegen, da die Platten nichts mehr machen.
ok, Missverständnis. Ich bin bei meiner Aussage oben davon aus gegangen, das
zunächst alles sauber funktioniert und dann eine oder vielleicht mehrere
Platten in die Knie gehen. Dann kann es durchaus sein das der cache auf einmal
nicht mehr weg geschrieben werden kann.
Aber zu meiner Frage oben, hast du etwas um das Lastverhalten an den
Hardwarekomponenten zu monitoren? z.B. cacti?
Gruß,
Heiko
Reply to: