Kann keine Shell-Befehle "..." mehr ausführen: ENOMEM (Cannot allocate memory)

[Dr. Boris Neubert]

Hallo,

ich habe mich ja letztens darüber ausgeheult, dass meine FHEM-Installation unzuverlässig ist. Heute hatte ich den Fall, dass die Automatisierungsfunktion nicht mehr funktionierte, die dafür sorgt, dass eine virtuelle Maschine hochgefahren wird, wenn meine Tochter ihren IGEL einschaltet. Am 01.11. hatte das nachweislich noch geklappt und seitdem gab es weder Änderungen an den Modulen noch an der Konfiguration.

Ich habe dann den ganz starken Drang unterdrückt, FHEM (auf Raspberry Pi) einfach neuzustarten, und bin der Sache stattdessen nachgegangen.

Problem:
Es können keine Shell-Befehle mehr ausgeführt werden (Tüttelchen-Syntax "/path/to/controlvm.sh").

Analyse:
Process ID von FHEM: 20860

strace -p 20860 -ttT  liefert

Code Auswählen Erweitern

19:17:41.077953 read(81, "\"/path/to/controlvm.sh\"\r\n", 256) = 15 <0.008525>
19:17:41.093575 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb6fc0278) = -1 ENOMEM (Cannot allocate memory) <0.001983>


ps -p 20860 -F liefert

Code Auswählen Erweitern

UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
fhem     20860     1 20 78292 304088  0 Oct20 ?        4-03:29:23 /usr/bin/perl fhem.pl /opt/fhem/conf/fhem.conf


free liefert

Code Auswählen Erweitern

             total       used       free     shared    buffers     cached
Mem:        496632     461924      34708          0      11092      93208
-/+ buffers/cache:     357624     139008
Swap:       102396      19648      82748

FHEM kann also keinen Speicher mehr für den im Hintergrund auszuführenden Shell-Befehl bekommen. Meine Fertigkeiten reichen nicht aus, herauszufinden, ob nicht mehr genügend oder nicht mehr genügend zusammenhängender Speicher zur Verfügung steht, oder ob es einen anderen Grund gibt.

Mir ist auch im Moment nicht bewusst, ob eine Resident Set Size von 304.088 kB für ein seit ca. 20 Tagen laufendes FHEM angemessen ist.

Ich glaube, dass ich hier auf ein grundsätzliches Problem gestoßen bin, das alle Anwender von FHEM betreffen könnte, vor allem aber die mit "kleinen" Systemen. Was denkt Ihr, wie wir damit umgehen sollen?

Ich lasse FHEM weiterlaufen, damit wir bei Bedarf am lebenden Objekt weiter analysieren können.

Viele Grüße
Boris

[rudolfkoenig]

Mein 5 Tage alter FHEM hat ein RSS von 29496, und ich meine das wird nicht wesentlich mehr.



Beim clone() geht es nicht um malloc, deswegen ist "nicht zusammenhaengender Speicher" vmtl. irrelevant (wg. MMU).
Ich dachte Linux forkt auch dann, wenn nicht es nicht sicherstellen kann, dass der komplette Speicher des Prozesses dupliziert werden kann. Allerdings habe ich das seit laengerem nicht mehr verifiziert, und es scheint bei dir auch nicht der Fall zu sein, da noch ueber 200MB zur Verfuegung stehen.


- ich habe keine Ahnung, wieso du die Fehlermeldung bekommst.
- 300+ MB fuer FHEM mAn sehr viel.
- 20% durchschnittliche CPU-Belastung durch FHEM finde ich sehr hoch
- man muesste rausfinden, welche Module soviel Speicher belegen, aber auf diesem Gebiet bin ich noch nicht sehr bewandert.

[Markus Bloch]

- man muesste rausfinden, welche Module soviel Speicher belegen, aber auf diesem Gebiet bin ich noch nicht sehr bewandert.

Das sollte mit http://search.cpan.org/~nwclark/Devel-Size-0.79/lib/Devel/Size.pm zu bewerkstelligen sein.

Gruß
Markus

[Dr. Boris Neubert]

okay, Devel::Size::Report auf $defs loslassen geht ohne Neustart... Mal sehen, ob ich das am Wochenende hinbekomme.

Grüße
Boris

[Dr. Boris Neubert]

Tja, am Mittwoch abend ist der fhem-Prozess gestorben ohne auch nur einen einzigen Hinweis im FHEM-Log zu hinterlassen.

/var/log/messages ist aber aussagekräftig: der out-of-memory-Killer hat zugeschlagen.

Ich habe fhem heute nachmittag neu gestartet. Der Speicherverbrauch ist noch im grünen Bereich:

Code Auswählen Erweitern

UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
fhem     28644     1 16  9141 28804   0 15:40 ?        00:17:21 perl fhem.pl /opt/fhem/conf/fhem.conf


Ich werde das beobachten.

Dummerweise gibt es Devel::Size::Report nicht als Debian-Paket.

Viele Grüße
Boris

[betateilchen]

Dummerweise gibt es Devel::Size::Report nicht als Debian-Paket.

Das Paket hilft Dir nicht weiter? libdevel-size-perl

[Dr. Boris Neubert]

Leider nein, es enthält Devel::Size::Report nicht.
bn

[betateilchen]

Installation dauert per CPAN auf einem Cubietruck weniger als eine Minute. Gerade getestet.

[Dr. Boris Neubert]

Gut zu wissen.

Sobald der Speicherverbrauch wieder Amok läuft, werde ich das Modul installieren und dann nachsehen, was das Problem auslöst.

Im Moment wird alle 5 Minuten der Speicherbedarf vom FHEM-Prozess geloggt. Steht noch bei RSS=28.696 kB.

Grüße
Boris

[Dr. Boris Neubert]

Hallo,

die Ursache ist ein Speicherleck im RSS-Modul.

Ich nehme an, dass es am erzeugten JPG-/PNG-Bild liegt. GGf. ist das Leck auch im GD-Modul.

Ich habe die Perl-Doku gelesen und im Web gesucht. Der Garbage Collector von Perl scheint nicht auf Speichersparen ausgelegt zu sein. Ich habe es mit übermäßigem Gebrauch an undef versucht und auch die Bild-Variable mit our zur modul-globalen Variable gemacht, weil die angeblich eher weggeräumt werden, während lokale Variablen wohl nicht beseitigt werden, wenn sie aus dem Kontext gehen.

Die Alternative ist nun, das Modul als Kindprozess auszuführen, weil nach der Beendigung eines Perl-Prozesses zwangsweise aufgeräumt wird. Das gibt noch fiesere Probleme, die zuerst gelöst werden müssen. Mehr dazu im Thread zum Forken.

Viele Grüße
Boris