Re: Hängt, aut of memory mit 64 GB Ram...
HI Martin
> 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.
Das System lief in diesem Zustand über 10 Stunden.
Nun es reagiert zwar auf die Tastatur, zum absetzen von irgend etwas
kommt es leider nicht.
Enter kann man betätigen für eine neue Zeile...
Ich versuche mal sync ins cron einzutragen .
>> 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?
Es gibt ins gesamt 10 paster Prozesse. Die werden aber per cronjob
minutlich neu gestartet.
> 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.
Ich werde mal rsync für ein paar tage abschalten um zu sehen ob es
dann immer noch auftritt.
> 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.
Wie gesagt, es sind 10 die jede minute speicher frei geben.
> 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.
Paster ist eine eigene implementierung von bild generierung.
Die skalieren und bearbeiten bilder.
> 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.
Hm, das ist interesant.
Ich schalte mal rsync ab und melde mich wieder.
Danke
> 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
>
>
> --
> 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: [🔎] 201210071435.42389.Martin@lichtvoll.de">http://lists.debian.org/[🔎] 201210071435.42389.Martin@lichtvoll.de
>
--
Best Regards
Vlad Vorobiev
Reply to: