Mailinglist Archive: opensuse-de (5973 mails)

< Previous Next >
Re: Speicherverwaltung und Absturz
  • From: corsepiu@xxxxxxxxxxxxxx (Ralf Corsepius)
  • Date: Wed Oct 25 11:25:46 2000
  • Message-id: <39F6C33A.528172B4@xxxxxxxxxxxxxx>



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@xxxxxxxx
For additional commands, e-mail: suse-linux-help@xxxxxxxx

< Previous Next >
References