FHEM Arbeitsspeicher nutzung

[der-Lolo]

Hallo Comunity,
ich habe festgestellt dass, wenn der FHEM-Server einige Tage läuft die Belastung des Arbeitsspeichers vom FHEM-Host ansteigt.
Nach einigen Tagen Laufzeit habe ich aktuell 54% Arbeitsspeicher nutzung durch FHEM.
Das Host System ist eine Synology DS716+ii mit ActivePerl 5.24 und aktuell noch 2GB RAM
Gibt es eine möglichkeit mit Bordmitteln herauszufinden wie lange FHEM schon läuft?
Gibt es eine möglichkeit zu sehen welche Informationen der FHEM-Server in den Arbeitsspeicher legt?

Sooo groß ist FHEM noch nicht - aber vielleicht wird es schwierig weil module im Einsatz sind die nicht so weit verbreitet sind (ModbusTCP von ChrisD)

Spontan würde ich sagen das es kein großes Problem ist, ich könnte ja FHEM ja einmal wöchentlich neustarten z.b. ich würde aber lieber der sache auf den Grund gehen.

Hat jemand eine Idee was ich tun kann?

Danke schonmal....

Code Auswählen Erweitern

System Info
ConfigType: configFile
SVN rev: 15292
OS: linux
Perl: 5.24.2
uniqueId: b6f...

Modules Model Count
DOIF 3
FHEM2FHEM 1
FHEMWEB 3
FileLog 1
ModbusCoil 35
ModbusRegister 26
ModbusTCPServer 1
PRESENCE
event 2
RESIDENTS 1
ROOMMATE 3
TelegramBot 1
Unifi 1
cloneDummy 3
dummy 1
harmony 8
notify 2
readingsGroup 1
telnet 1

[frank]

Gibt es eine möglichkeit mit Bordmitteln herauszufinden wie lange FHEM schon läuft?

der fhem befehl "uptime".

das problem verstehe ich noch nicht wirklich.
belegt fhem 50 prozent von 2gb, also 1gb?
oder ist allgemein der arbeitsspeicher zu 50 prozent belegt?

warum stört es dich, wenn der arbeitsspeicher benutzt wird?

[der-Lolo]

htop zeigt das der fhem Prozess nach einigen Tagen etwa 50% in der Spalte MEM% erreicht.
Es stört mich nicht wirklich, es gibt auch kein problem mit FHEM es läuft alles sehr stabil, zuverlässig und angenehm performant...
Mir fällt einfach nur auf - das über einige Tage die auslagerung von FHEM in den Arbeitsspeicher größer wird. Ich möchte einfach vermeiden das FHEM nach ein paar Wochen laufzeit stehen bleibt, weil kein RAM mehr zur verfügung steht.

uptime kannte ich noch nicht - wenn man help eingibt bekommt man diesen befehl auch nicht angezeigt. fheminfo fehlt aber auch in dieser liste.

Die Diskstation hat soeben ein upgrade auf 8GB Speicher bekommen - mal schauen wie es sich damit verhält...

[juemuc]

Warum definierst Du nicht ein Gerät mit SYSMON?

Hier lasse ich mir alle Systemwerte anzeigen.

Viele Grüße

Jürgen

[der-Lolo]

Das würde ja auch nichts ändern - nur das ich nebenher per Terminal schauen müsste... Die Speicherauslastung wäre aber ja die gleiche....
Mich wundert nur das FHEM nach einer Woche laufzeit etwa 1GB Daten gesammelt hat.

[Thorsten Pferdekaemper]

Hi,
ich habe bisher einen ganz brauchbaren Debugger (perldebug) und Performance Profiler (nytprof) gefunden, aber Speicheranalyse ist wohl etwas schwieriger. Ich kann mir schon vorstellen, dass manche Module nach langer Laufzeit Probleme bekommen, insbesondere da der Garbage-Collector in Perl anscheinend ein einfaches Reference-Counting macht und daher keine Zyklen auflösen kann.
...auf jeden Fall ist das ein interessantes Thema.
Gruß,
   Thorsten

[ChrisD]

Hallo,

Du kannst versuchen den Befehl 'fhemdebug memusage' zu benutzen. Dieser zeigt den Speicherverbrauch der internen Strukturen an. Am Besten ist es FHEM neu zu starten, kurz nach dem Start den Befehl einzugeben, die ausgegebenen Daten zu kopieren und abzuwarten bis der Speicherverbrauch merklich gestiegen ist. Anschließend den Befehl erneut eingeben und schauen bei welchen Zeilen es größere Unterschiede gibt.

Grüße,

ChrisD

[herrmannj]

Das fhem 1gb Speicher beim system anmeldet ist per se problemlos.

Generell arbeitet de facto alle Programme in etwa so: wenn ein prozess, auch vorübergehen, speicher benötigt dann fragt er beim system (os) an.

Das os gibt dem prozess den speicher, der macht was damit. Wenn der dann nicht mehr benötigt wird behält der prozess den speicher aber (er gibt ihn nicht an das os zurück) und merkt sich, intern, das er den speicher, intern, vergeben kann. Falls benötigt.

Das führt nach einer gewissen Laufzeit dazu das vermeintlich viel speicher "gebraucht" wird. Wenn Du irgendwann mal einen grossen logfile anschaust braucht fhem (- perl) dafür viel speicher. Den behält fhem (- perl) dann "für sich" - auch wenn der logfile schon lange "fertig" ist.

Man muss also untersuchen ob der Speicher immer weiter anwächst, dann passiert was Du sagst. Irgendwann ist er alle. Oder ob 1gb (plus minus) bleibt -> alles ok.

garbage collector: korrekt! Dies (Vereinfacht!!!):

Code Auswählen Erweitern

$hash_a->{'chiild'} = $hash_b;
$hash_b->{'parent'} = $hash_a;
return;

gibt eine Leiche. Wenn $hash_b aus dem scope ist kommt man nicht ran. Da jedoch $hash_a auf $hash_b zeigt (und $hash_b auf $hash_a) leben die auf ewig weiter. Wenn das zb bei (häufigen) IO Operationen passiert kann sich das ganz schön summieren. Das Beispiel vereinfacht! Mit "weaken" kann man die auflösen, man muss aber beim programmieren darauf achten.

vg
joerg

[chris1284]

Irgendwann ist er alle. Oder ob 1gb (plus minus) bleibt -> alles ok.

es ist auch ok wenn fhem (oder programm x) den ganzen Speicher für sich anmeldet solange das os selbst oder anderen Prozessen davon wieder was abzwacken könnebn wenn diese Speicher benötigen.

[der-Lolo]

Konkret habe ich der DS716+ii ja gestern ein Speicherupgrade verpasst, der FHEM-Host verfügt also jetzt über 8GB Speicher.

Ich hätte auch kein problem damit FHEM einen großen Teil dieses Speichers zuzuweisen - grundsätzlich würde ich fhem eh gerne von den Festplatten fernhalten sodass die DiskStation auch mal die Festplatten herunterfahren kann. Vielleicht auf dem Weg DBLog Daten nur alle 12 Std. oder so wegzuschreiben. Logging ist aber noch nicht aktiv, ich scheitere zur Zeit beim einrichten der SQLite verbindung.

FHEM läuft nun seit dem Speicherupgrade:

1 day, 03:47:51

  0  [|                                                                      0.7%]   Tasks: 81, 93 thr, 109 kthr; 1 running
  1  [|                                                                      0.7%]   Load average: 1.02 1.10 1.08
  2  [|                                                                      1.3%]   Uptime: 1 day, 03:50:25
  3  [|||||||                                                                7.9%]
  Mem[||||||||||||||||||||                                             724M/7.72G]
  Swp[                                                                   0K/6.63G]

PID  PPID  TGID NLWP USER      PRI  NI IO  VIRT   RES   SHR S CPU CPU% MEM%   DISK READ  DISK WRITE   TIME+  Command
11706     1 11706    1 fhem       20   0 B4  455M  400M  4888 S   0  8.5  5.1    0.00 B/s    0.00 B/s  2h47:05 /opt/ActivePerl-5.24/bin/perl /usr/local/fhem/opt/fhem.pl /
22863 22840 22863    1 root       20   0 B4 26804  2328  1372 R   2  2.0  0.0    0.00 B/s    0.00 B/s  0:07.75 htop
8362     1  8362    1 root       20   0 B4  220M 15892 10100 S   1  0.7  0.2    0.00 B/s    0.00 B/s  2:36.66 /usr/bin/snmpd -fLn -c /etc/snmp/snmpd.conf -p /var/run/snm
4083     1  4083   11 system     20   0 B4  944M  7512  4128 S   1  0.7  0.1    0.00 B

Ich habe herausgefunden das es einen großen einfluss auf die Prozesslast hat wenn ich den poll des WagoControllers verändere - der Poll ist nun so eingestellt das FHEM um 10% (+- 5%) pendelt

Bei der MEM% anzeige hat FHEM vom Neustart an 0.7%.
Gefühlt wächst dieser Wert stündlich um 0.1

Einmal habe ich zu 2GB zeiten die Speicherauslastung bis auf 80% hochlaufen lassen, hatte dann aber Energieversorger seitig einen Stromausfall.

@ChrisD: ich habe den befehl ausprobiert und bekomme eine Perl Meldung das ich das fehlende Modul Devel::Size brauche...

Can't locate Devel/Size.pm in @INC (you may need to install the Devel::Size module) (@INC contains: . /opt/ActivePerl-5.24/site/lib /opt/ActivePerl-5.24/lib ./FHEM) at (eval 55174) line 2.
BEGIN failed--compilation aborted at (eval 55174) line 2.

Werde mich mal bei ppm umschauen welche Module unter ActivePerl nun installiert werden müssen.
Ausserdem werde ich sysmon mal aktivieren um Plots zur CPU und RAM zur verfügung zu haben.

@herrmannj
zur Zeit ist FHEM hier noch nicht voll am werkeln - die komponenten werden nach und nach hinzugefügt, Logging und Plots laufen leider noch nicht - FHEM hat also aus dieser sicht nicht wirklich viel zu tun - manchmal lasse ich jedoch einen eventMonitor BrowserTab über 4-6 Std. laufen. Ich hoffe nun bald den Zustannd zu erreichen das FHEM mehr als 1GB Ram benötigt.

garbage collector sagt mir mal noch nix, aber das Forum spukt dazu was aus, ich schaue es mir mal an.
FHEM darf gerne VIEL Speicher benutzen, ich brauche hier ja nicht sparsam zu sein...
Eine gute Performance erwarte ich, deswegen habe ich ja auch etwas stärkere Hardware gewählt.

[chris1284]

Vielleicht auf dem Weg DBLog Daten nur alle 12 Std. oder so wegzuschreiben

Wenn du sicherstellen kannst dass zb kein Stromausfall die Daten löscht innerhalb der 12h. Der Speicher wird sicher nicht Batteriebuffered sein.
Generell wäre sicher auch keine 8gb nötig gewesen solange das von Synology hin gebogene OS sauber werkelt.

Etwas OT: Ich würde mir aber noch mal überlegen ob ich mit (FHEM-)Server seitig mit einer (in meinen Augen überteuerten NAS Lösung) künstlich beschränken will (Stichwort OS, Perl, Pakete, Treiber usw usw). Für die 400€(?) kann man sich locker einen Server (der auch als Nas fungiert) mit mehr bums bauen der im Stromverbrauch gleichwertig ist und man selber die Wahl des OS und der Software hat

[der-Lolo]

Zur Synology kann ich nur sagen, das ich begeistert bin - DSM das Syno betriebssystem arbeitet sauber, letztendlich hat mich Andre bei der entscheidung Hardware zu kaufen ein bisschen unterstüzt.
Ich habe natürlich auch darüber nachgedacht einen Nuc oder ähnliches einzusetzen, mich aber dann für Synology entschieden um eben auch unsere Datenhaltung und Sicherung zu erneuern. Das ich bzgl. Linux und Perl ein wenig eingeschränkt bin auf der Syno stimmt natürlich - sollte unser FHEM-Haus wenn es mal vollständig integriert ist die grenzen der Syno sprengen können wir immer noch auf ein zweit System (Nuc) ausweichen...
Unsere TimeCapsulle hat halt mittlerweile knapp 8 Jahre auf dem Buckel, es wurde Zeit hier mal auf nummer sicherer zu gehen. Die entscheidung zur Syno hat also nicht nur mit FHEM zu tun.

[Thorsten Pferdekaemper]

Hi,
meiner Meinung nach war die einzige echte Antwort bisher diese:

Du kannst versuchen den Befehl 'fhemdebug memusage' zu benutzen.

Anscheinend hast Du (der-Lolo) aber recht schnell aufgegeben:

@ChrisD: ich habe den befehl ausprobiert und bekomme eine Perl Meldung das ich das fehlende Modul Devel::Size brauche...

Das ist meiner Meinung nach das einzige, das Du brauchst. Einfach mal installieren und nochmal probieren. Ich denke, dass das zumindest mal einen Anhaltspunkt geben könnte, welches Modul das ist.
...außer wenn es hier um zyklische Referenzen geht, die der Garbage collector nicht auflösen kann, aber das muss ja nicht so sein.
Gruß,
    Thorsten

[der-Lolo]

naja, aufgegeben habe ich noch nicht - wie schon gesagt, auf der Syno Plattform läuft ActivePerl hier installiert man per ppm am besten Module nach. Ich habe noch nicht herausgefunden welches Paket ich nachinstallieren sollte sodass die abhängigkeit zu Devel::Size sich auflöst.

https://forum.fhem.de/index.php/topic,78678.0.html
Leider noch keine antwort - und auch mit Google bis jetzt keinen erfolg gehabt.

Ich arbeite daran und werde euch hier auf dem laufendem halten.

Die 1GB marke bei der RAM auslastung wurde soeben gerissen - hinter dem link ein Plot der RAM auslastung...
https://www.dropbox.com/s/yvfdz8o061d7xl6/Screenshot%202017-10-30%2014.49.41.png?dl=0

[der-Lolo]

Ich habe nun endlich Devel-Size per ppm nachinstalliert, das absetzen des befehls fhemdebug memusage führt allerdings dazu das sich der FHEM Prozess sofort beendet. Nun kann ich natürlich nicht sagen ob es an der ActivePerl installation liegt oder an FHEM

Das logfile zeigt nichts an, das web interface ist sofort verschwunden und nicht mehr erreichbar. In htop verschwindet der Prozess - die RAM auslastung war auf >13% angewachsen - stetig über den Tag. Wie auf dem Plot zu sehen... Ich habe nach Neustart der Disk-Station nochmal versucht den Befehl abzusetzen, leider das gleiche Ergebnis...