Re: Hängt, aut of memory mit 64 GB Ram...
Am Sonntag, 7. Oktober 2012 schrieb Vladislav Vorobiev:
> Hi,
Hallo,
> > Zum Geschehen, das das Bildschirmfoto abbildet: Bitte schicke da mal
> > die Protokoll-Dateien. Es ist in der Regel nicht erforderlich, ein
> > Bildschirmfoto zu schicken, solange sich der Server nicht so
> > aufhängt, dass gar nichts mehr in kern.log / syslog landet. Und da
> > ist dann auch alles drin und nicht nur ein kleiner Ausschnitt.
>
> Das system hängt und reagiert nicht.
> In logs befindet sich nichts relevantes, es logt nicht deshalb
> screenshot. Es ist mir keine Methode bekannt wie ich auf die vorigen
> screens zugreifen kann.
Es kann sinnvoll sein, es in einem solchen Zustand mal etwas laufen zu
lassen. In der Regel hängt sich der Kernel nicht komplett auf, sondern ist
einfach nur extrem beschäftigt. Über eine offene SSH-Sitzung oder ein
offenes TTY läßt sich evtl. noch ein sync absetzen, was den Kernel
veranlasst, doch noch zu versuchen etwaige Logs rauszuschreiben. Evtl.
auch ein /etc/init.d/rsyslog restart davor, damit rsyslog auch noch alles
rausschreibt.
> > Aber nun dazu, was ich dem Bifo entnehmen kann:
> >
> > Es gibt trotz 64 GiB RAM Speichermangel. Der Out Of Memory Killer
> > beendet eine ganze Reihe von Prozessen, die jeweils den Namen
> > „paster“ tragen und knapp 2 GiB physikalischen Speicher für sich
> > selbst beanspruchen (anon rss). RSS = Resident Set Size =
> > physikalisch belegter Speicher, ggf. aber mit Bibliotheken, weiß
> > nicht, wie genau der Kernel das hier aufdröselt. Sie haben wohl auch
> > eine Datei oder mehrere Dateien offen, aber das spielt mit etwa 2
> > MiB kaum eine Rolle (file rss).
> >
> > Was ist das für ein Programm? Führe mal dpkg -S $(which paster) aus
> > und gebe das Ergebnis hier bekannt. Hast Du ein Programm am
> > Paketmanagement vorbei installiert? Wenn ja und wenn dpkg -S nichts
> > findet, dann schaue mal dort.
>
> Paster ist ein python Programm. Ich denke auch nicht dass es ein
> Problem ist. Es wird einfach beendet weil es nicht genügend Speicher
> insgesamt zur Verfügung steht.
Wie kommst Du darauf, dass Paster keine Probleme macht, Vlad?
Der OOM Killer wählt seine Prozesse nach Kriterien wir deren
Speicherverbrauch aus. Er kommt also nicht zufällig dazu, gerade eine
ganze Reihe Prozesse von Paster zu entsorgen.
Auffällig eben ist auch, dass es eine ganze Reihe Prozesse sind, die je 2
MiB verbrauchen. Wiebviele sind es? Bei 64 GiB und etwa 2 GiB pro Prozess
reichen, wenn man etwaigen Anteil für Bibliotheken mal rausrechnen, 32-40
Paster Prozesse um das System in ernsthafte Schwierigkeiten zu bringen.
Und das berücksichtigt nicht mal, was sonst auf dem System noch passiert.
Was macht denn der Paster-Prozess? Bitte Vlad, liefere Infos. Wenn ich
Dich nach was frage, dann habe ich dazu in der Regel gute Gründe. Dass es
ein Python-Programm ist, sagt relativ wenig aus. Ich kann auch selbst
$SUCHMASCHINE bemühen, aber das seh ich gerade ehrlich gesagt nicht ein.
Denn es ist Dein Problem, nicht Meines.
Eine Idee noch, die ich mal abprüfen würde: Ist BTRFS schreib-technisch
während des rsync-Workloads am Ende? vmstat / iostat -xd 10 und atop oder
so sollten Aufschluß geben. Was ich mir dann vorstellen könnte, ist dass
auch Paster-Prozesse auf I/O warten und wenn der Prozess, der die Paster-
Prozesse startet, einfach lustig weitere startet und diese sich dann
stapeln, dann wundert mich nicht mehr, warum Dein System am Ende ist.
Könnte schnell passieren, wenn z.B. ein Cron-Job Paster in regelmäßigen
Abständen startet.
Daher wäre auch mal sinnvoll
ps aux | grep " D"
auf die Anzahl an Prozessen, die in einem ununterbrechbaren Schlaf sind,
zu beobachten. Das sollten im Regelfall nur wenige bis gar keine Prozesse
sein.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: