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
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
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
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
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.
Zitat von: rudolfkoenig am 09 November 2014, 21:52:58
- 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
okay, Devel::Size::Report auf $defs loslassen geht ohne Neustart... Mal sehen, ob ich das am Wochenende hinbekomme.
Grüße
Boris
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:
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
Zitat von: Dr. Boris Neubert am 15 November 2014, 17:28:37
Dummerweise gibt es Devel::Size::Report nicht als Debian-Paket.
Das Paket hilft Dir nicht weiter? libdevel-size-perl
Leider nein, es enthält Devel::Size::Report nicht.
bn
Installation dauert per CPAN auf einem Cubietruck weniger als eine Minute. Gerade getestet.
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
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