Hallo KernSani,
bei mir hat Freezemon ($Id: 98_freezemon.pm 25141 2021-10-28) im Hauptprozess einen RAM-Zuwachs von ca. 200 MB/h verursacht (FHEM 31669/2026-09-20, Perl 5.40.5, fhem-docker auf Synology, 440 Geräte). Nach meinen Messungen und dem Quelltext liegt es daran, dass der Ersatz für Log3 auch bei deaktiviertem Gerät installiert wird und die Warteschlange dann nie aufgeräumt wird. Ich habe das auf einem System belegt und nicht auf einem zweiten nachgestellt. Bitte um Einschätzung, ob das so gewollt ist bzw. ob du es ebenfalls siehst.
Konstellation bei mir (einziges Freezemon-Gerät; fhem.cfg, alphabetische Reihenfolge der attr-Zeilen)
define fm_NASDS720 freezemon
attr fm_NASDS720 disable 1
attr fm_NASDS720 fm_extDetail 1
attr fm_NASDS720 fm_freezeThreshold 0.2
attr fm_NASDS720 fm_logExtraSeconds 2
attr fm_NASDS720 fm_logFile ./log/freeze-%Y-%m.log
attr fm_NASDS720 fm_logKeep 10
Ablauf nach dem Quelltext
1. Beim Einlesen steht disable 1 vor fm_logFile. freezemon_Attr ruft bei disable 1 freezemon_unwrap_all auf, es ist noch nichts gewickelt.
2. Bei fm_logFile (Zeile 890) wird freezemon_install_log_wrapper($hash) aufgerufen, ohne zu prüfen, ob das Gerät deaktiviert ist.
3. freezemon_Log3 (Zeilen 1285-1297) ruft das Original auf und hängt danach jeden Aufruf (Stufe ≤ 5) als [Zeit, Gerät, Stufe, Text] an @logqueue (Zeile 125). Das passiert auch dann, wenn das Original wegen der Detailstufe nichts ausgibt.
4. Aufgeräumt wird nur durch freezemon_purge_log_before (Zeilen 1468-1482), aufgerufen aus freezemon_ProcessTimer (Zeilen 476, 581). Der Timer läuft bei disable 1 nicht. freezemon_unwrap_all stellt Log3 wieder her, leert @logqueue aber nicht.
Messungen
- B::svref_2object(\&Log3)->FILE lieferte im laufenden Prozess ./FHEM/98_freezemon.pm (Original wäre fhem.pl).
- Zählung der lebenden Perl-Werte im Abstand von 130 Minuten, selber Prozess: ARRAY +812.062 (ca. 104 je Sekunde), SCALAR +3.255.164, REF +904.532, Verhältnis 4,0 : 1 : 1,1. Das entspricht einem Datensatz mit vier Werten je Log3-Aufruf. Die langen Zeichenketten darunter sind Log-Texte (auch Stufe 5, obwohl verbose 2).
- malloc_stats(): Arena 0 hatte 3.805.581.312 Byte, davon 3.804.895.728 belegt (0,018 % frei). Es ist also kein zurückgehaltener Speicher, sondern belegter.
- Ich habe freezemon_unwrap_all($defs{fm_NASDS720}) im laufenden Prozess aufgerufen: Log3 war danach wieder fhem.pl, der Zuwachs fiel von 13,4 MB je 5 Minuten auf 0,3 MB und lag danach bei ca. 0 (der bis dahin belegte Speicher bleibt bis zum Neustart).
- Nach dem Entfernen von fm_logFile und einem Neustart: 0,55 bis 1,7 MB/h statt ca. 200 MB/h (gemessen über ca. 17 Stunden).
- Die Konfiguration war seit mindestens 07.09. unverändert; die Rate hing nur davon ab, wie der Prozess gestartet worden war (Start aus der Konfiguration mit disable 1 und fm_logFile = Leck).
Vorschläge (nicht getestet)
- Zeile 890: den Ersatz nur installieren, wenn das Gerät nicht deaktiviert ist, zum Beispiel freezemon_install_log_wrapper($hash) unless ( $hash->{helper}{DISABLED} ); (freezemon_start installiert ihn bei disable 0 ohnehin, Zeile 1046).
- @logqueue zusätzlich begrenzen (Anzahl oder Alter), auch wenn der Timer nicht läuft.
Prüfen, ob man betroffen ist (FHEM-Befehlszeile, ;; wegen des Parsers)
{ join(", ", map { "$_ disable=".AttrVal($_,"disable",0)." fm_logFile=".AttrVal($_,"fm_logFile","-") } devspec2array("TYPE=freezemon")) }Steht dort ein Gerät mit disable=1 und gesetztem fm_logFile, wächst die Liste. Abhilfe: deleteattr <name> fm_logFile oder das Gerät löschen. Sofort ohne Neustart (der Zuwachs endet, der belegte Speicher erst beim Neustart):
{ freezemon_unwrap_all($defs{"<name>"}) }
Details zur Suche in meinem Thread bei Anfängerfragen: https://forum.fhem.de/index.php?topic=145499.0
Mangels tiefergehender Kenntnisse in Perl und FHEM habe ich meine Untersuchungen immer von einer KI prüfen und mir die entsprechenden Befehle für die Tests erstellen lassen. Sie hat mir auch die technischen Details zu diesem Thread geliefert. Ich hoffe, es ist alles verständlich, wie es beschrieben ist.
Gruß Jürgen
nur zur Info: KernSani hat sich leider schon länger von FHEM verabschiedet. Der arme Rudi hat sich mangels Alternative dem Modul angenommen.
Grüße Markus
Danke für die Info. Dann wird er es ja sicher irgendwann lesen.