FHEM-Hauptprozess wächst linear ~200 MB/h, Ursache trotz Diagnose nicht gefunde

[bmwfan]

Hallo zusammen,
aufgrund des komplexen Fehlers leider ein längerer Post.

Ich habe seit kurzem wiederholt ein Speicherproblem, dessen Ursache ich trotz intensiver Eigendiagnose nicht finde. Das Problem trat bereits vor ca. 3 Wochen auf, verschwand nach einer Konfigurationsänderung (vermutlich, aber nicht sicher belegt – siehe unten), und ist seit einem Modul-Update heute wieder exakt im gleichen Muster zurück. Ich vermute daher eine tieferliegende, wiederkehrende Ursache, die durch verschiedene Änderungen nur zeitweise maskiert wird.

Umgebung
•   Synology DS720+, FHEM in Docker (Image fhem/fhem:latest, Basis Debian, Perl 5.038005)
•   fhem.pl Build: 2026-09-20 (heute per update aktualisiert von Build 2026-08-29)
•   Featurelevel 6.4
•   Aktive Hauptmodule: HMCCU/HMCCURPCPROC (Version 2024-12, 4 RPC-Interfaces: BidCos-RF, BidCos-Wired, HmIP-RF, VirtualDevices), PRESENCE2 (01.05, mehrere Devices + Daemon), FritzSmart (26.09.15), 113× DOIF, ROOMMATE/RESIDENTS, SolarForecast, DbLog (heute aktualisiert, neue SVG-Subprozess-Architektur), SSCam (3 Kameras), Freezemon (aktuell disable=1)
•   Versionen Module: Siehe Datei

Symptom
Der Hauptprozess (perl fhem.pl fhem.cfg) wächst linear und sehr gleichmäßig um ca. 200–210 MB/h, ohne erkennbares Plateau. Gemessen über 8,5 Stunden nach einem Neustart, RSS aus ps:
Zeit seit Neustart   RSS Hauptprozess   Zuwachs/30 min
0:15 h   388.664 kB   –
0:45 h   491.020 kB   +102.356 kB
1:15 h   595.344 kB   +104.324 kB
1:45 h   696.244 kB   +100.900 kB
2:15 h   800.112 kB   +103.868 kB
...   ...   konstant im selben Bereich
8:45 h   2.135.340 kB   +104.844 kB

Die Schwankung zwischen den Intervallen liegt bei nur ±5 %. Es handelt sich nicht um einen praktisch konstanten Zuwachs pro Zeiteinheit – das spricht für einen regelmäßig laufenden internen Vorgang (Timer/Notify-Zyklus), der bei jedem Durchlauf eine ungefähr gleich große Speichermenge bindet, ohne sie wieder freizugeben. Unbehandelt führt das nach 20–24 h zu vollständiger Speichererschöpfung des Hosts (Cannot fork: Cannot allocate memory).

Was ich bereits ausgeschlossen habe (mit Belegen)
•   apptime/Freezemon (helper->{bm}): Struktur wuchs zwar durch aktive apptime-Nutzung, aber nach apptime pause/clear blieb bm bei 0 – die Hauptprozess-Wachstumsrate änderte sich dadurch nicht merklich.
•   HMCCURPCPROC: Die vier RPC-Kindprozesse wachsen mit ca. 1,7–2 MiB/h/Prozess – deutlich, aber konstant über mehrere Messreihen (auch vor dem heutigen Update) und in einer völlig anderen Größenordnung als der Hauptprozess. Modul-Dateidatum unverändert seit 08.01.2025.
•   DbLog-Subprozess (PID separat gemessen): RSS blieb über die gesamten 8,5 h bei exakt 81.812 kB – der neue SVG-Subprozess-Mechanismus selbst wächst nicht.
•   FritzSmart: helper- und fhem-Hash-Keys des Devices blieben über den gesamten Zeitraum konstant (16 bzw. 30 Keys).
•   PRESENCE2/DOIF-Timer-Anzahl (@intAtA): schwankt im Bereich 250–280, kein Aufwärtstrend.

Der Zuwachs sitzt also, wie ich vermute, im Hauptprozess selbst, ohne dass eine der von mir beobachtbaren Perl-Datenstrukturen (%defs-Helper-Hashes der genannten Devices) dafür sichtbar verantwortlich ist.

Historie (die mich verwirrt):
Vor ca. 3 Wochen bin ich von 72_FRITZBOX.pm auf 72_FritzSmart.pm umgestiegen (Vorgängermodul lief jahrelang unauffällig, ohne erkennbares Speicherproblem). Meiner Erinnerung nach trat das Speicherwachstum (ca. 190–220 MB/h, linear) erst im Zusammenhang mit dieser Umstellung auf – ich bin mir aber nicht zu 100 % sicher, ob es tatsächlich erst danach begann oder ob es zufällig zeitlich zusammenfiel. Behoben schien es dann durch eine Erhöhung der Ping-Parameter für die lan-ping-Presence-Checks für Android-Smartphones von Default auf -c 3 -w 5. Ich frage die Android-Smartphones über lan-ping und über checkAllFritzMACpresent ab und fasse es über eine structure zusammen. Auch hier kann ich nicht ausschließen, dass stattdessen ein zwischenzeitlicher Neustart die Ursache war. Danach lag das Wachstum bei ca. 8–11 MB/h (deutlich niedriger, aber nicht null).

Heute habe ich ein reguläres update durchgeführt (12 Dateien: fhem.pl, 01_FHEMWEB.pm, 14_SD_RSL.pm, 60_Watches.pm, 72_FritzSmart.pm, 76_SolarForecast.pm, 93_DbLog.pm, 93_DbRep.pm, 98_CDCOpenData.pm, SetExtensions.pm, lib/FHEM/Core/Weather.pm, CHANGED), gefolgt von shutdown restart – und ab der ersten Messung nach dem Neustart war die hohe Rate sofort wieder da.

Meine Frage an euch
1.   Ist ein derartiges lineares Hauptprozess-Wachstum (nicht in RPC-Kindprozessen, nicht in bekannten Helper-Strukturen sichtbar) ein bekanntes Muster, z. B. im Zusammenhang mit fhem.pl-Kernänderungen, FHEMWEB, oder der neuen DbLog-SVG-Subprozess-Architektur?
2.   Gibt es ein empfohlenes Werkzeug/Vorgehen, um Perl-Speicherwachstum im Hauptprozess zu identifizieren, das nicht über %defs-Helper-Hashes sichtbar ist (z. B. Closures, zyklische Referenzen, die vom GC nicht aufgelöst werden)?
3.   Hat jemand mit einer ähnlichen Modulkombination (HMCCU/HMCCURPCPROC + PRESENCE2 + FritzSmart + DOIF in größerer Zahl) etwas Vergleichbares beobachtet?

Für jeden Hinweis bin ich sehr dankbar – auch für Vorschläge, wie ich das systematischer eingrenzen kann als bisher.

[DS_Starter]

Hallo bmwfan,

ich kann deine Beobachtung zum Teil bestätigen wobei 200MB/h wirklich außerordentlich sind. Jedenfalls kann ich sagen, dass es nicht dieses oder jenes eine Modul ist.
Bei mir auf dem Proxmox Cluster laufen einige FHEM Instanzen, jeweils mit mehreren bis vielen Devices von SSCam, DbLog, DbRep, SolarForecast nur um meine eigenen bzw. betreuten zu nennen. Daneben natürlich auch SVG, notify, at, MQTT2 ... und weitere. Ein ganzer Zoo.
Manche Instanzen zeigen Wachstum, andere nicht. Ich habe bis jetzt noch nicht DEN "Schuldigen" identifizieren können. Das Verhalten scheint sich auch manchmal bei einem Neustart zu verändern, sowohl negativ als auch positiv.
Aktuell lasse ich nach und nach alle bei mir eingesetzten Module mit KI-Unterstützung auf Speicherleaks hin untersuchen. Eventuelle Funde bewerte ich nochmal manuell und gebe sie den Maintainern bekannt (zum Beispiel hier).
Möglicherweise lassen sich mit dieser Vorgehensweise diese Probleme finden und reduzieren. Aber es ist ein mühseliges Geschäft ... Ergebnis/Erfolg ungewiß.

LG,
Heiko

[JoWiemann]

Hallo bmwfan,

ich würde mal mit einer frischen Fhem Installation, ohne jegliche Devices, beginnen. Läuft diese unauffällig, dann Device für Device hinzunehmen.

Ich selber habe eine umfangreiche Fhem Installation, u.a. mit FritzSmart und Presence2 laufen. Ein entsprechendes Verhalten zeigt sich bei mir nicht.
Allerdings hatte ich das immer mal wieder sporadisch mit dem RPi 3b+ und konnte auch dort die Ursache nicht finden. Ich habe dann auf einen RPi4 gewechselt und alles ist seid dem gut.

Grüße Jörg

[Guybrush]

hast du zufällig configdb laufen? bei mir sind die beiden fhem Prozesse auch recht groß:

Code Auswählen Erweitern

ps -eo pid,user,%mem,rss,command --sort=-rss | awk 'NR==1 {printf "%-10s %-10s %-6s %-10s %s\n", $1, $2, $3, "RSS(MB)", $5} NR>1 {printf "%-10s %-10s %-6s %-10.2f %s\n", $1, $2, $3, $4/1024, $5}' | head -n 3
PID        USER       %MEM   RSS(MB)    COMMAND
***        fhem       26.8   2167.81    /usr/bin/perl
***        fhem       20.3   1638.27    /usr/bin/perl
***        mysql      14.0   1135.72    /usr/sbin/mariadbd

mag Zufall sein, aber ich meine, dass fhem deutlich genügsamer war bevor ich auf configdb umstellte. Mag sich aber auch zeitlich überschnitten haben.