Hallo, vom Friday 05 July 2013 14:07:06: > Hi! > > 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 markiert, oder wie? Kann ich das auch "pro Array" oder "pro Diak" machen (vgl unten)? > 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. 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 ich das richtig verstehe, müsste doch dann aber die anderen Platten trotzdem laufen, oder nicht? Der Swap wäer weiterhin erreichbar. Gibt es eine Möglichkeit, nachzuweisen, dass das das Problem ist? Was kann ich dagegen machen? Christian 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. Kann das mit XEN zu tun haben? Ich habe wie gesagt bisher immer auf bare Hardware gearbeitet und nie derartige Probleme gehabt. Christian
Attachment:
signature.asc
Description: This is a digitally signed message part.