Re: Hängt, aut of memory mit 64 GB Ram...
Hallo Vlad,
Irgendeinen Grund, dass Du in Absender-Feld einen anderen Namen als in der
Mail-Signatur verwendest?
Am Sonntag, 7. Oktober 2012 schrieb Zuzukov Zuzu:
> Screen vergessen
>
> Am 7. Oktober 2012 04:49 schrieb Zuzukov Zuzu
<mymir.org@googlemail.com>:
> > Hi,
> >
> > ich habe ein problem mit einem start belastetem server.
> >
> > Siehe screenshot.
> >
> > Problem ist das es sich täglich aufhängt.
> >
> > Swap habe ich bei der Installation ausgeschaltet.
> > Mir ist nicht klar ub man dann nicht ein speziellen
> > Kernel ohne swap installieren sollte.
> >
> > Das System is mit 64 GB RAM großzügig ausgelegt.
> > Was kann man machen, mit ist nicht klar von welcher
> > Seite ich das Problem angehen soll.
> >
> > Ich nutze btrfs mit fstab eintrag
> >
> > UUID=XXX / btrfs defaults,discard,ssd
Zunächst einmal:
BTRFS ist experimentell. Wenn Du es verwendest, tust dies auf eigenes
Risiko. Und es ist sinnvoll, wenn Du dann auch die BTRFS-Mailingliste
mitzuverfolgen.
Immerhin ist…
> > Kernel 3.5-trunk-amd64 #1 SMP Thu Aug 2 17:16:27 UTC 2012 x86_64
> > GNU/Linux
… recht aktuell.
Ich wundere mich da immer wieder. BTRFS bitte nur einsetzen, wenn die
Bereitschaft da ist, auch mal Probleme damit zu beheben. Zugegeben, hatte
bislang weniger davon, aber je nach Workload können Performance- und oder
andere Probleme auftreten.
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.
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.
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 :).
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: