FHEM RAM Verbrauch -Speicherloch in Perlversion?

[hugomckinley]

Hallo,
ich stehe vor dem Problem, dass seit einem OS-Upgrade meines Systems der RAM-Verbrauch von FHEM langsam aber stetig steigt.
Irgendwann beendet mir der OOM-Killer dann alle möglichen Prozesse.
Wenn ich FHEM neu starte, dann geht es wieder ein paar Tage. Heute war ich vor dem shutdown restart bei 21GB beim Perl-Prozess.

Das einzige was ich gefunden habe war: https://github.com/Perl/perl5/issues/18604
Und hier FHEM spezifisch: https://forum.fhem.de/index.php/topic,112649.msg1069721.html#msg1069721
Was mMn auf die Perlversion hin deutet. Meine ist 5.32.1

Ich nutze seit Jahren FHEM in einer FreeBSD Jail (unter TrueNAS). Bisher 11.3 und jetzt 12.2

Gibt es eine Möglichkeit herauszufinden welches Modul in FHEM wieviel RAM braucht? So könnte ich vielleicht herausfinden, was dieses Loch in Perl provoziert.
Da der händische Wechsel der Perlversion ja anscheinend eine Großbaustelle ist, bleibt mir glaube ich nur übrig auf ein Update in TrueNAS zu warten.

Mir ist das Problem vorher nicht in der Form aufgefallen. Was ich jedoch hatte, war, dass unter FreeBSD 11.3 FHEM unregelmäßig (Wochen bis Monate) plötzlich den Dienst einstellte. Ich weiß nicht wie ich es beschreiben soll, aber das FreeBSD System verhielt sich ganz normal aber FHEM reagierte auf nichts mehr.
Ich habe dieses Problem damals auf die lange Bank geschoben, weil es so selten auftrat, aber jetzt sind es nur Tage zwischen dem volllaufen des RAM Speichers.
Ich habe damals leider auch nicht geschaut wieviel RAM der Perlprozess braucht.

Ich wäre für Hinweise dankbar!

Grüße,
Hugo

[rudolfkoenig]

Ueber dieses Problem gibt es eine "ewig" lange Diskussion hier https://forum.fhem.de/index.php/topic,84372.900.html.

Ich versuche es zusammenzufassen:
- es gibt wohl diverse Ursachen fuers Speicherloch, z.Bsp. Fehler in einem der Module, im FHEM-Framework, in einem der verwendeten Perl-Bibliotheken, in Perl selbst oder im Systembibliotheken.
- Perl 5.24 hat ein Speicherloch in der Regexp-Bibliothek, was bei bestimmten DOIF Operation merkbar wurde.
- Solche Ursachen zu identifizieren ist nicht trivial, bzw. mir is keine einfache Methode bekannt.
- die Suche nach verlorenen Daten in den Perl-Strukturen, was ich mal in fhemdebug eingebaut habe, war nicht genau, hat nie ein Speicherloch gefunden, und hat in etlichen Faellen zum Perl-Absturz gefuehrt, deswegen ist es inzwischen wieder ausgebaut.
- eine andere Moeglichkeit ist regelmaessig /proc/.../maps zu dumpen, per diff den wachsenden Bereich feststellen, per GDB sie dumpen, und anhand der Unterschiede an das verantwortliche Modul zu schliessen. Leider ist diese Methode weder trivial auszufuehren, noch aus den Unterschieden an der Verursacher zu schliessen.
- die einfachste Methode ist, die FHEM-Definitionen eins nach dem anderen aus der Konfiguration zu entfernen, und so das Problem zu lokalisieren. Ist aber in einem produktiven Umgebung nicht praktikabel, und Testsysteme haben meist keine Probleme.

Ich bin bereit bei neuen Ideen in dieses Problem weitere Energie/Code/etc reinzustecken.

[hugomckinley]

Herzlichen Dank für deine Ausführungen Rudi!
Ich habe dieses Thema natürlich auch schon gelesen und auch die alten Einträge über fhemdebug.

Das mit den Regexp hört sich verdächtig an, da in dem Link von mir das Speicherloch genau durch eine Regexp provoziert wird.
Ich verwende auch viele DOIFs, was auch passen würde.
Es sieht auch so aus, als wenn es mit dieser Perlversion angefangen hätte.

Was wären denn solche "bestimmten" DOIF Operationen?
Muss ich die Definition der DOIFs löschen, oder reicht ein disable?


Danke!

Grüße,
Hugo

[rudolfkoenig]

Sorry, die Details kenne ich nicht, am besten im DOIF Bereich des Forums fragen.

[hugomckinley]

Die "Lösung" des Problems war ein Update der Perlversion.
Ich hatte das mal halbherzig per Hand versucht, das war mir dann aber zuviel Action.
Nach dem Update meines Basissystems (TrueNAS 11 [FreeBSD 12.2] auf TrueNAS 13 [FreeBSD13.1]) war das Problem behoben.

Es wurde zwar nur von Perl 5.32.1_1 auf 5.32.1_3 aktualisiert, aber das hat gereicht.

Vielleicht kann die Info er brauchen.