Bernd Brodesser wrote:
* Ralf Corsepius schrieb am 25.Okt.2000:
Bernd Brodesser wrote:
ich stand mal wieder kurz vor einem Absturz. Nicht unbedingt, ob hängt davon ab, was genau passiert ist.
Klar. Deshalb auch fast.
Die von Dir beschriebenen Symptome deuten auf einen Memory-Race hin, d.h. etwas, dass entweder mehr Speicher allozieren wollte, wie verfügbar, oder auf etwas, dass rekursiv unendlich viel Speicher allozieren wollte. Dieses etwas kann ein Programm sein (dann wäre es ein Bug im Programm), der Kernel (d.h. ein Memory Leak im Kernel) oder auch einer Bibliothek (d.h. ein Bug in einer Library, zB. der Speicherverwaltung in der libc).
Wenn wir mal Hardwareprobleme außen vor lassen, Auch das wäre natürlich eine Möglichkeit. Wenn Du aber nichts an deiner HW-Konfiguration geändert hast, eher unwahrscheinlich.
dann bin ich der Meinung, daß der Kernel es im Griff kriegen müßte, egal wie kaput ein Programm ist. Wenn ein kaputes Programm mehr Speicher anfordert als es gibt, dann müßte der Kernel Stopp sagen. Tut er normalerweise auch, doch in der Zwischenzeit dauert es halt den Swap zu füllen :)
Dies tritt bei Memory-Races gerne auf, da der gerade aktive (durchgedrehte) Prozess dann allen verfügbaren Speicher allozieren will und andere Dinge (z.B. dein gerade offener Netscape oder irgendwelche schlafenden Daemons) geswappt werden. Hat sich das System danach dann wieder gefangen, bleiben diese dann bis sie wieder benutzt werden, ausgelagert.
Schon klar. Aber das System stand doch deshalb still, weil ständig geswapt wurde, nehme ich mal an.
Nicht unbedingt. Bei Races ausserhalb des Kernels wird das System oft interaktiv kaum noch bedienbar, was dann den Eindruck erweckt, als ob das System stillstände. Bei Races im Kernel habe ich allerdings auch schon erlebt, dass gar keine Eingaben mehr akzeptiert wurden (reiserfs auf SuSE-6.3/SMP #:-), mit SuSE-7.0 scheint es jetzt einigermassen stabil :)
Wenn das System danach weiterläuft und der Swap auch irgendwann mal wieder freigegeben wird ist wahrscheinlich alles in Ordnung.
Ja. Wenn er freigegeben wird.
Probier mal nach einem derartigen Vorfall einen swapoff -a. Stürzt das System danach richtig ab, ...
Warum ist überhaupt soviel frei?
Das war allerdings nachdem das System extrem langsam wurde. Passt genau. Dieses "Langsam werden" war der Memory-Race, der alle anderen Prozesse in den Swap gedrängt hat, bevor seine Speicheranforderungen zur Folge hatten, dass diese nur noch im Swap erfüllt werden konnten (680 MB Swap bei 128MB RAM ist nicht unbedingt sinnvoll).
Warum ist das nicht sinnvoll?
Darüber kann man vortrefflich streiten (Hatten wir auf dieser Liste schon öfters :). Zu Zeiten als RAM selten war (<32/64MB) galt mal die Faustregel Swap = 2-3x RAM, doch heutzutage ist das etwas fragwürdig, da das Füllen von mehreren Hundert MB Swap einfach sehr viel Zeit braucht (u.U. mehrere 10 Minuten) und das System währenddessen kaum noch nutzbar ist. Braucht man derartig grosse Mengen Swap gelegentlich auch wirklich, ist jedoch nichts gegen grosse Mengen Swap einzuwenden - man sollte sich nur im klaren darüber sein, dass es einige Zeit braucht den Swap zu füllen. Wird dann noch während des Swappens interaktiv weitergearbeitet, werden u.U. Hunderte MB vom Swap mehrfach ins RAM und wieder zurückgeschaufelt. Bei 128MB RAM reichen 128 MB Swap meiner bescheidenen Meinung nach vollkommen aus. Wenn nicht - dann mehr RAM.
Vorher war kein Swap mehr frei. Nichts, niente. Oftmals kommt es dann zum Absturz. Eigenartigerweise funktionieren die Terminalumschaltung ALT+FX auch noch nach einem Totalabsturz, nicht aber die Umschaltung von X auf einem Terminal. Überhaupt ist an einem Absturz immer X beteiligt.
Ist da mit dem neuen Kernel oder mit dem neuen XFree Besserung in Sicht?
Um dazu eine Aussage machen zu können sind deine Angaben nicht aussagekräftig genug.
Es wäre wichtig zu wissen, welches Programm durchging. Ein Top während des Memory-Races würde Auskunft geben können.
Schön, und wie rufe ich top auf, wenn nichts mehr geht? Ich kann ja noch nicht mal zur Konsole wechseln. Und auf X kann ich auch nichts machen. Ich weiß, da gibt es ähnliche Teile. Siehe unten - alternativ und falls Du das Problem einigermassen reproduzieren kannst, lass einen top parallel mitlaufen.
Ansonsten passen die Symptome auf * die berüchtigten Memory-Leaks in Kerneln < linux-2.2.16-SuSE bzw. linux-2.2.17.
linux-2.2.14 Original SuSE 6.4
OK, das wäre ein ganz heisser Kandidat. Alle Kernels vor den oben genannten Versionen hatten Memory-Leaks, die nur sporatisch und auch nicht in allen Konfigurationen auftraten, von denen die Kernelentwickler (bzw. SuSE) glauben sie nun weitgehend gefixt zu haben.
* die Memory-Leaks in der glibc2 * Treiberbugs. * Den klogd Bug in älteren Kernels
Der klogd Daemon in älteren Kernels ging manchmal durch, allokierte den gesamten virtuellen Speicher und starb danach, meist ohne das System weiter zu beeinträchtigen. Ob der 2.2.14-SuSE Kernel auch diese Problem hatte, kann ich mich leider nicht mehr errinnern. Wenn top während eines Races hohe Load durch klogd anzeigt, vorher klogd aktiv war und hinterher fehlt oder sich in einen Zombie gewandelt hat, dürfte es sich mit hoher Wahrscheinlichkeit um dieses Problem handeln. Auch hier hilft ein Kernelupdate.
* Einen Bug in g++-2.95.2 * Das End-Of-RAM Problem
Ich meinte das alte Problem mit mem=(physikaler Speicher - einige MB). Wenn der Kernel dann doch mal auf das Ende des physikalen Speichers zugreift, geht's dahin, fängt sich manchmal aber auch wieder - Die Symptome können dann so aussehen wie von Dir beschrieben.
Und solltest Du 2.4.x-Kernels oder KDE2 einsetzen, ... no comment.
Nein, ich setze keinen 2.4er Kernel ein. Ja, ich setze KDE2 ein. Na und? Es kann doch nicht angehen, daß ein wie auch immer kaputes Anwenderprogramm ein System zum Absturz bringt. Das ist doch der Riesenvorteil von einem UNIX, daß da immer noch der Kernel sitzt und das Anwenderprogramm nicht alles erlaubt. Auch nicht wenn es von root ist, was im übrigen bei mir nicht der Fall war.
Alles richtig, nur ist KDE2 so neu, dass die Wahrscheinlichkeit auf einen Race in Libraries oder Applikationen zu treffen sehr hoch ist, ich KDE2 also als sehr wahrscheinliche Fehlerquelle ansehen würde.
ALT+SysRq ist ja ganz nett, aber damit kann man auch nur den Rechner neu booten. Ich suche was um den XServer killen zu können, auch wenn alles steht.
Moment mal, wieso alles steht? Wenn Dich oben richtig verstanden habe, lief dein System hinterher doch noch, nur konntest während der Swapperei nicht interaktiv eingreifen, oder?
Ja. Ich habe jetzt nicht vom aktuellen Fall geredet. Sorry, ging ein wenig durcheinander. Aber so was habe ich schon mal von Zeit zu Zeit. Allerdings sehr selten. Waren bestimmt andere Kernel. Experimentelle Kernel benutze ich allerdings nicht. Wenn ich auch sonst gerne ein wenig rumexperimentiere, aber am Kernel lieber nicht.
Ansonsten: als Root auf der Konsole: killall -9 X
Ach und wie komme ich auf der Konsole? Tja, das ist ein Problem :-)
Meist ist es so, das während Races kaum Eingabeevents (Tastatur/Maus) mehr zum Zuge kommen, meist aber doch, d.h. liegt der Keyboardfocus während eines Races zufällig auf einem Terminal kann blindes Eintippen von killall -9 X helfen oder auch Wechseln auf die Konsole gelingen. Eine meist funktionierende Alternative besteht darin, von einer anderen Maschine aus auf der betroffenen Maschine eingeloggt zu sein und von dort aus einen killall -9 X abzusetzen zu versuchen. Ralf --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com