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? > > > 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. > > 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. Danke Christian
Attachment:
signature.asc
Description: This is a digitally signed message part.