Re: Hängt, aut of memory mit 64 GB Ram...
Hi,
> 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.
> 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.
> Ansonsten bietet sich an, auch mal atop oder collectd to installieren, um
> einen Eindruck zu bekommen, wie sich das Problem aufbaut. Ich empfehle
> hier mit atop aufzuzeichnen, um dann interaktiv das Problem
> nachzuvollziehen.
> Am Rande interessant wäre auch noch, wer den OOM Killer auslöst. Auch das
> findet sich im Protokoll. Und den Backtrace, also bei welcher Funktion.
>
> Swap halte ich generell für ungeplante Not-Situation für sinnvoll, würde
> aber hier – wahrscheinlich – das Problem nicht lösen, da mir das hier nach
> meinem Bauchgefühl nach einem klassischen Mem Leak aussieht. Allerdings
> läßt sich das erst mit einer Atop-Aufzeichnung mit Speicheranforderungen
> nach Prozessen genau sagen. Es könnte auch sein, dass der Workload einfach
> etwas mehr als 64 GiB RAM braucht und es mit 32 GiB Swap oder so
> zusätzlich klappen würde. Allerdings dann nur vergleichsweise langsam,
> selbst bei einer SSD, die dann auch zusätzlich mit Speicherzugriffen
> belastet wird. Daher empfehle ich bei einer solchen Situation lieber
> einfach noch 64 GiB RAM dazuzustecken :). Aber nur, wenn der Workload das
> wirklich erfordert. Ansonsten: Anwendung tauschen, aktualisieren oder
> optimieren :).
Ok, werde ich mal untersuchen.
Danke
Vlad
> Ciao,
> --
> Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
> GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
>
>
> --
> Zum AUSTRAGEN schicken Sie eine Mail an debian-user-german-REQUEST@lists.debian.org
> mit dem Subject "unsubscribe". Probleme? Mail an listmaster@lists.debian.org (engl)
> Archive: [🔎] 201210071237.39670.Martin@lichtvoll.de">http://lists.debian.org/[🔎] 201210071237.39670.Martin@lichtvoll.de
>
--
Best Regards
Vlad Vorobiev
Reply to: