Hallo @rudolfkoenig,
zuerst einmal: Ich hab den Topic mit einem ,,?" versehen, weil ich nicht weiß ob ich irgendwo die Doku nicht richtig gelesen habe.. ;o)
Vorgeschichte: Zwischen den Jahren ist mir aufgefallen dass einer meiner Watchdogs angeschlagen hat, weil FHEM nicht mehr (bzw. nur noch sehr langsam) über Telnet reagierte. Im Log (FHEM & Server) stand nichts was auf einen Grund hingedeutet hat. Also habe ich mich mit dstat auf die Lauer gelegt und festgestellt das das Verhalten genau dann auftritt, wenn FHEM major Pagefaults generiert. Hintergrund: Meine FHEM Instanz war von anfänglich ~150MB auf inzwischen ~500MB angestiegen.
Der Data Stack von FHEM ,,wächst" bei mir zur Zeit mit ~0.6MB/Tag. Und wenn ich da mal mit dumper reinschaue, bin ich glaube ich schnell fündig geworden: Zur Zeit werden bei mir ~350 Hashes/Tag unter $FW_id2inform{<Unix Timestamp>} erzeugt, die nicht wieder aufgeräumt werden. Bei mir sind das aktuell 3200 Hashes, allein in den letzten 8 Tagen, die Unix Timestamps haben die älter als 1 Tag sind.
Die Hashes die bei mir da so rumliegen sind z.B.:
$FW_id2inform{"1741505366.15507"}{"Authenticated"}
$FW_id2inform{"1741505366.15507"}{"AuthenticatedBy"}
$FW_id2inform{"1741505366.15507"}{"AuthenticatedUser"}
$FW_id2inform{"1741505366.15507"}{"BUF"}
$FW_id2inform{"1741505366.15507"}{"FW_ID"}
$FW_id2inform{"1741505366.15507"}{"LASTACCESS"}
$FW_id2inform{"1741505366.15507"}{"NAME"}
$FW_id2inform{"1741505366.15507"}{"NR"}
$FW_id2inform{"1741505366.15507"}{"NTFY_ORDER"}
$FW_id2inform{"1741505366.15507"}{"PEER"}
$FW_id2inform{"1741505366.15507"}{"PORT"}
$FW_id2inform{"1741505366.15507"}{"READINGS"}{"state"}{"TIME"}
$FW_id2inform{"1741505366.15507"}{"READINGS"}{"state"}{"VAL"}
$FW_id2inform{"1741505366.15507"}{"SNAME"}
$FW_id2inform{"1741505366.15507"}{"SSL"}
$FW_id2inform{"1741505366.15507"}{"STATE"}
$FW_id2inform{"1741505366.15507"}{"TEMPORARY"}
$FW_id2inform{"1741505366.15507"}{"TYPE"}
$FW_id2inform{"1741505366.15507"}{"WBCallback"}
$FW_id2inform{"1741505366.15507"}{"canAsyncOutput"}
$FW_id2inform{"1741505366.15507"}{"encoding"}
$FW_id2inform{"1741505366.15507"}{"inform"}{"devices"}{"#FHEMWEB:WEB"}
$FW_id2inform{"1741505366.15507"}{"inform"}{"devices"}{"FGW14"}
$FW_id2inform{"1741505366.15507"}{"inform"}{"filter"}
$FW_id2inform{"1741505366.15507"}{"inform"}{"fmt"}
$FW_id2inform{"1741505366.15507"}{"inform"}{"since"}
$FW_id2inform{"1741505366.15507"}{"inform"}{"type"}
$FW_id2inform{"1741505366.15507"}{"websocket"}
Wenn ich das richtig gesehen habe, werden diese Hashes via FHEMWEB verwaltet. Ist das so richtig ? Jetzt könnte ich natürlich hingehen und einen Aufräum-Job schreiben.. aber macht es nicht Sinn das Aufräumen in FHEMWEB zu verankern ?
Gruss & Danke, hasselh
Vielen Dank fuer den Hinweis!
Beim Schliessen der Websocket Verbindung wurde nicht aufgeraeumt.
Ich habe das jetzt nachgeholt und eingecheckt.
Danke Dir !! Ich wollte die neue Version gleich mal testen und hab sie hier runtergeladen: SVN (https://svn.fhem.de/trac/export/29751/trunk/fhem/FHEM/01_FHEMWEB.pm)
Dann habe ich die alte 01_FHEMWEB.pm testweise damit ersetzt. Allerdings will die die Weboberfläche nach einem shutdown restart nicht mehr hochkommen. Im Log steht (trotz attr global verbose 3) nix verdächtiges. Hast du irgend eine Idee ?
UPDATE: Ok, die Meldungen von Ralli habe ich auch im Log.. Sorry, war ein langer Tag.. ;o)
01_FHEMWEB.pm ist kaputt, kann ich bestätigen:
2025.03.15 08:07:12 1: Including fhem.cfg
2025.03.15 08:07:12 1: PERL WARNING: Bareword found where operator expected at ./FHEM/01_FHEMWEB.pm line 401, near "// Want"
2025.03.15 08:07:12 1: PERL WARNING: (Missing operator before Want?)
2025.03.15 08:07:12 1: PERL WARNING: Bareword found where operator expected at ./FHEM/01_FHEMWEB.pm line 401, near "call FW_Undef"
2025.03.15 08:07:12 1: PERL WARNING: (Do you need to predeclare call?)
2025.03.15 08:07:12 1: reload: Error:Modul 01_FHEMWEB deactivated:
syntax error at ./FHEM/01_FHEMWEB.pm line 401, near "// Want to "
BEGIN not safe after errors--compilation aborted at ./FHEM/01_FHEMWEB.pm line 592, <$fh> line 10.
2025.03.15 08:07:12 0: syntax error at ./FHEM/01_FHEMWEB.pm line 401, near "// Want to "
BEGIN not safe after errors--compilation aborted at ./FHEM/01_FHEMWEB.pm line 592, <$fh> line 10.
Moin,
gerade eben auch upgedatet. Schnelle Lösung ist in Zeile 401
// Want to call FW_Undef
zu ersetzen durch
# Want to call FW_Undef
und FHEM restarten auf OS-EBene. Wird Rudi sicherlich umgehend fixen.
LG,
Heiko
Habs angepasst, und auch fuer update aktualisiert.
Ich wollte nur kurz Rückmeldung heben, das sich bei mir keine $FW_id2inform{<Unix Timestamp>} Hashes mehr ansammeln. 👍 Der Data Stack von FHEM wächst zwar immer noch langsam, aber die Anzahl der Objekte/Strukturen im Stack bleibt jetzt zumindest gleich. ✅ Insofern schiebe ich das jetzt mal auf das Memory Mgmt. von Perl (v5.36.0).
Mal schauen, ob sich der Speicherbedarf dann in ein paar Wochen nicht mehr ändert..
Hallo!
Spannend! Ich suche derzeit auch den Grund warum ich einen stetigen Speicherverbrauch habe.
Die Analyse dazu ist sehr schwierig, denn in einer Testumgebung habe ich diesen Effekt nicht wirklich nachstellen können. Bin mal gespannt wie viel sich durch dieses Update ändert.
@hasselh
Wie hast du die Analyse hinbekommen?
Ich versuche es derzeit mir alle Objekte in einzelne dumps zu schreiben und diese dann zu beobachten. Schwierig.
Gruß
Bismosa
Hi @bismosa,
ZitatWie hast du die Analyse hinbekommen?
here you go: :)
- Ermitteln des aktuellen CPU & Memory Verbrauchs der laufenden FHEM Instanz (https://forum.fhem.de/index.php?topic=141380.0)
Die langfristige Analyse von FHEM CPU, Memory-Verbrauch und Antwortzeit mache ich extern (über Volkszaehler (https://www.volkszaehler.org/)) - aber das ist eher Geschmackssache.
Und die einzelnen Elemente im Stack vergleiche ich dann mit:
- Objekte/Strukturen aus dem Data Stack von FHEM miteinander vergleichen (https://forum.fhem.de/index.php?topic=141382.0)
Interessanterweise wächst der Data Stack - bei jetzt gleichbleibender Menge von Objekten/Strukturen - immer noch nahezu konstant (10% in 2 Wochen). Ich hätte erwartet, das der Speicherverbrauch irgendwann asymptotisch gegen einen Wert läuft. Aber vielleicht bin ich nur zu ungeduldig... ;)