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 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.
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 (https://forum.fhem.de/index.php?topic=145498.0)).
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
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
hast du zufällig configdb laufen? bei mir sind die beiden fhem Prozesse auch recht groß:
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.
Hallo bmwfan,
mir ging es genauso, darum bin ich so ähnlich vorgegangen wie es Jörg beschrieben hat.
Ich habe immer 5 Module rausgeschmissen und kontrolliert, ob es noch einen Speicherzuwachs gibt - dann die nächsten 5 - usw. (zeitaufwendig).
Zu guter Letzt blieben bei mir dann SolarForecast, freezemon, speedtest, Installer und DWD_OpenData übrig.
Nachdem ich diese Module nicht wirklich benötige (damals zum Ausprobieren installiert), habe ich auch nicht geprüft welches für den Speicherzuwachs verantworlich war.
Oder vielleicht war es sogar einfach eine Kombination aus einigen Modulen.
Zum Prüfen des Speicherzuwachses habe ich folgendes im Einsatz:
defmod memUsage dummy
attr memUsage devStateIcon {\
"<pre>".ReadingsVal( $name,'check','-' )."</pre>"\
}
attr memUsage event-on-change-reading Data_Stack,RSS,Shared,Text,VSZ
attr memUsage event-on-update-reading wert
attr memUsage group RaspberryPi
attr memUsage icon RPi
attr memUsage readingList wert
attr memUsage room system
attr memUsage setList wert
attr memUsage sortby 02_01
attr memUsage userReadings check:wert:\scheck$ {\
use Memory::Usage;;\
my $result = "initialized... (".TimeNow().")";;\
\
# Read result and keep it\
if( defined( $hash->{helper}{mu} ) ) {\
$hash->{helper}{mu}->record();;\
my $state_ref = $hash->{helper}{mu}->state;;\
\
if( scalar( @$state_ref ) == 2 ) {\
my ($timestamp1, $message1, $vsz1, $rss1, $shared1, $text1, $data_stack1) = @{$state_ref->[0]};;\
my ($timestamp2, $message2, $vsz2, $rss2, $shared2, $text2, $data_stack2) = @{$state_ref->[1]};;\
\
my $timestamp_d = $timestamp2 - $timestamp1;; # time in seconds between records\
my $vsz_d = $vsz2 - $vsz1;; # virtual memory size\
my $rss_d = $rss2 - $rss1;; # resident set size\
my $shared_d = $shared2 - $shared1;; # shared memory size\
my $text_d = $text2 - $text1;; # text (aka code or exe) size\
my $data_stack_d = $data_stack2 - $data_stack1;; # data and stack size\
my $mem_vh = sprintf( "%.2f", 100 / 3887992 * $data_stack2 );;\
my $time1 = substr( FmtDateTime( $timestamp2 ),11,8 );;\
my $time2 = sprintf( "%02d:%02d:%02d", int( $timestamp_d / 3600 ), int( ( $timestamp_d % 3600 ) / 60 ), $timestamp_d % 60 );;\
# my $time2 = strftime( '%T', gmtime( $timestamp_d ) );; # if seconds > 1 day (86.400), hours starts with 0\
\
$result = sprintf( "Total: Timestamp: %8s, VSZ: %7d, RSS: %7d, Shared: %5d, Text: %5d, Data_Stack: %7d (%6.2f %%)\n",\
$time1, $vsz2, $rss2, $shared2, $text2, $data_stack2, $mem_vh );;\
$result .= sprintf( "Diffs: Timestamp: %8s, VSZ: %7d, RSS: %7d, Shared: %5d, Text: %5d, Data_Stack: %7d (%6.2f %%)",\
$time2, $vsz_d, $rss_d, $shared_d, $text_d, $data_stack_d, ReadingsNum( 'sysmon','ram_used_vH',0 ) );;\
\
readingsBulkUpdate( $hash, "timestamp", $timestamp2 );;\
readingsBulkUpdate( $hash, "VSZ", $vsz2 );;\
readingsBulkUpdate( $hash, "RSS", $rss2 );;\
readingsBulkUpdate( $hash, "Shared", $shared2 );;\
readingsBulkUpdate( $hash, "Text", $text2 );;\
readingsBulkUpdate( $hash, "Data_Stack", $data_stack2 );;\
\
readingsBulkUpdate( $hash, "timestamp_diff", $timestamp_d );;\
readingsBulkUpdate( $hash, "VSZ_diff", $vsz_d );;\
readingsBulkUpdate( $hash, "RSS_diff", $rss_d );;\
readingsBulkUpdate( $hash, "Shared_diff", $shared_d );;\
readingsBulkUpdate( $hash, "Text_diff", $text_d );;\
readingsBulkUpdate( $hash, "Data_Stack_diff", $data_stack_d );;\
\
readingsBulkUpdate( $hash, "MEM_vH", $mem_vh );;\
}\
}\
\
#initiate profiling (again)\
$hash->{helper}{mu} = Memory::Usage->new();;\
$hash->{helper}{mu}->record();;\
\
return $result;;\
}
attr memUsage webCmd wert check
Vielleicht hilft es ja.
Gruß, Robert
Hallo und besten Dank für die Informationen und Hilfe,
mein System ist monatelang ohne jegliches Problem gelaufen und ich habe alle paar Wochen ein Update von FHEM gemacht. Da das Problem erst durch den Ausfall von FHEM wegen des Speichermangels aufgetreten ist, kann ich die ursächliche Änderung nicht mehr eindeutig reproduzieren.
Ich weis noch, dass ich, nachdem ich gelesen habe dass es ein Nachfolgemodul von 72_Fritzbox gibt, meine Abfragen der Smartphones auf 72_FritzSmart umgestellt und an den lan-ping etwas geändert habe. Dann war es für mich gut, bis der Speichermangel auftrat und ich mit der KI einen stündlichen Zuwachs von ca. 200 MB ermittelt hatte. Nach einem erneuten Update von FHEM habe ich den Container-Manager und das Container-image (fhem-Main) upgedated. Zwischenzeitlich war der Speicherzuwachs auf ca. 18 MB/h abgesunken und ich dachte, das Problem wäre gelöst ohne wirklich die Ursache gefunden zu haben aber am nächsten oder übernächsten Tag war das NAS wieder im Speicherlimit.
@Heiko: Mit welchen Befehlen forschst Du nach dem Speicherleck? Ich verwende Putty per SSH und könnte es mal so versuchen.
@ Jörg: Das wäre meine letzte Rettung, da ich 444 Device im System habe.
@Guybrush: Nutze ich nicht
@Robert: SolarForecast und DWD nutze ich auch, sind aber monatelang ohne Problem gelaufen wobei es, meine ich, auch bei SolarForecast ein Update gab.
Wenn das Problem tatsächlich je nach Neustart mal auftritt und mal nicht, müsste es ja ein Timing-Problem beim Hochfahren sein und damit wäre es eine Lotterie, ob es mal klappt oder nicht. Schöner Mist aber ich forsche mal weiter. Spiele jetzt Schritt für Schritt die alte Konfiguration, also zuerst FritzSmart zurück auf Fritzbox etc. ein. Mal sehen, ob ich so weiterkomme.
Falls noch jemand Ideen und Ansätze einfallen bitte melden.
Grüße Jürgen
Zitat@Heiko: Mit welchen Befehlen forschst Du nach dem Speicherleck?
Ich benutze eine Ganzheitsmethode. Ich stelle der KI das komplette Modul zur Verfügung und "beauftrage" sie den gesamten Code nach potentiellen Speicherleaks zu untersuchen und Fundstellen zu reporten. Die bewerte ich dann manuell denn oftmals werden auch Dinge gespielt, die in der Realität kaum oder keinen Impact haben werden. Sonst wäre diese Aufgabe schier unmöglich zu bewältigen.
Wenn ich kann, erstelle ich einen Patch, der helfen kann das Leakproblem zu lösen.
Manche Leaks kommen nur bei ganz bestimmten Situationen oder Kommunikationsformen im System zum Tragen. Deswegen kann es bei einem Nutzer zu Problemen führen, bei anderen nicht.
Und dann darf man nicht vergessen, dass man ja auch über die myUtils oder Perl-Schnittstellen in Modulen (DOIF, SolarForecast,...) eigenen Code zur Ausführung bringen kann. Auch dort kann man sich unter Umständen problematischen Code selbst einbauen.
Der Königsweg ist leider noch nicht gefunden und es gibt bereits einige Threads im Forum die sich damit beschäftigen. Und Tools, die das Speicherwachstum messen, sind manchmal selbst das Problem. ;)
Grüße,
Heiko
da es mehrere betrifft... vielleicht hat einer ja Lust und Zeit sich mit Devel::Size zu beschäftigen. Ich hab das bei mir gestern mal gemacht:
sudo apt install libdevel-size-perl
dann in der fhem konsole:
{ \
require Devel::Size;;\
my @x=();;\
for my $n (keys %defs) { \
next if ref($defs{$n}{READINGS}) ne "HASH";;\
my $s=Devel::Size::total_size($defs{$n}{READINGS});;\
push @x,[$s,$n];;\
} \
@x=sort {$b->[0]<=>$a->[0]} @x;;\
splice(@x,100) if @x>100;;\
join("\n",map { sprintf("%8.3f MB | %s",$_->[0]/1048576,$_->[1]) } @x) ;;\
}
das war bei mir unauffällig. helper erstmal auch:
{ \
require Devel::Size;; \
my @x = ();; \
for my $n (keys %defs) { \
my $h = $defs{$n}{helper};; \
next if ref($h) ne "HASH";; \
push @x, [ Devel::Size::size($h), scalar(keys %$h), $n ];; \
} \
@x = sort { $b->[0] <=> $a->[0] } @x;; \
splice(@x, 100) if @x > 100;; \
join("\n", map { sprintf("%9.1f KB %6d Einträge %s", $_->[0] / 1024, $_->[1], $_->[2] ) } @x) \
}
da sind allerdings nicht die verschachtelten Einträge drin. ein query direkt auf helper führt zum Absturz bei mir. Ich vermute gerade, dass das memory leak von apptime kommen kann, was ich bei mir grad ständig am laufen hab. aber da bin ich noch nicht weit gekommen:
{ \
my @x = ();; \
for my $n (keys %defs) { \
my $bm = $defs{$n}{helper}{bm};; \
next if ref($bm) ne "HASH";; \
push @x, [ scalar(keys %$bm), $n ];; \
} \
@x = sort { $b->[0] <=> $a->[0] } @x;; \
join("\n", map { sprintf("%8d bm-Einträge %s", $_->[0], $_->[1]) } @x) \
}
vielleicht hat jemand anders Zeit/Lust sich damit weiter zu beschäftigen...
Zitat von: bmwfan am 22 September 2026, 20:50:22Freezemon (aktuell disable=1)
Gab es da nicht auch mit freezemon selbst ein Problem, dass es sich nicht richtig deaktivieren lässt und weiterhin selbst Speicher verbraucht? Ich habe da von früheren Speicherproblemen und Untersuchungen was im Kopf. Und tatsächlich habe ich ein freezemon Gerät in meiner fhem.cfg, aber nicht einfach disable=1 sondern ausgesternt (falls ich es mal wieder brauche).
Danke für den Hinweis! Habe es durch die KI (meine Kenntnisse reichen nicht soweit) nachprüfen lassen, ohne es selber verifizieren zu können. Seht es als Hinweis, falls jemand ähnliche Probleme hat.
----------------
Bei mir ist disable=1 von Anfang an in der fhem.cfg gesetzt (nicht erst nachträglich per set). In dem Fall ruft freezemon_Define() die Funktion, die CallFn/Log3/AnalyzeCommand/HttpUtils_NonblockingGet umhüllt, gar nicht erst auf. Die "Unwrapping ..."-Zeilen, die bei jedem Neustart im Log erscheinen, kommen aus dem Attr()-Callback (wird für jede Attribut-Zeile beim Config-Laden aufgerufen) und sind reine Log-Kosmetik ohne Wirkung, weil intern per if defined(...) geprüft wird, ob überhaupt etwas gewickelt wurde – bei mir eben nie.
Bei mir also entwarnt, mein Wachstum lief bei aktiv laufendem Test (Handy-Presence deaktiviert, HMCCU delayedinit) unverändert weiter. Könnte aber bei jemandem relevant sein, der Freezemon per set ... inactive zur Laufzeit aus- statt von Anfang an per Attribut disabled hat – da wird tatsächlich real gewickelt/entwickelt, und ob das beim Zurücksetzen sauber ist, habe ich (die KI) nicht geprüft.
-------------------
So, Schluß für heute. Anbei ein Zwischenstadn,w as alles getestet wurde (falls jemand auf dieselben Probleme stößt. Wieder durch die KI erstellt.
----------------
Zwischenstand zum Speicherleck-Thread
Kurzes Update, da sich seit meinem letzten Beitrag einiges an Ausschlussdiagnostik ergeben hat.
Code-Review statt weiterer Vermutungen: Ich habe 72_FritzSmart.pm über zwei Versionssprünge hinweg (07.09.→11.09.→aktuell 26.09.15) komplett diffed. Keine neuen BlockingCall-Aufrufe, keine wachsenden globalen Strukturen, ein neuer Watchdog-Mechanismus für hängende Kindprozesse ist sauber implementiert (delete() an allen Ausstiegspunkten).
Funktionstest statt Theorie: Eine eigene Utility-Funktion (checkAllFritzMACpresent, fragt FritzSmart-Readings für PRESENCE2 ab) über den einzigen erkennbaren Aufrufpfad 2,5 Stunden komplett deaktiviert (Aufrufzähler nachweislich auf 0 während dieser Zeit) — Wachstumsrate blieb bei den üblichen ~180 MiB/h. Widerlegt.
Devel::Size-Analyse aller Devices: Größte READINGS-Struktur 1,57 MB, größte helper-Struktur 2,5 KB. Bei einem Prozess, der inzwischen mehrere GB groß ist, ist das irrelevant. %defs-Strukturen damit für mich vom Tisch.
HMCCU-Start-Timing getestet: delayedinit=60 gesetzt, RPC-Start technisch nachweislich um ca. 90s statt 5-13s verzögert — Rate danach unverändert bei ~183 MiB/h. Die Boot-Race-Condition-Hypothese (danke an dieser Stelle für den Denkanstoß dazu) trägt bei mir nicht.
Systematischer Gruppentest (Module/DOIF-Gruppen je 1-1,5h deaktiviert, Sicherheitsfunktionen wie Wasserleck-Sensoren dabei außen vor): SolarForecast, alle 3 SSCam-Kameras und 24 Diagnose-/Statistik-DOIFs einzeln durchgetestet — alle drei ohne jeden messbaren Effekt (durchgehend 176-185 MiB/h).
Ein Nebenbefund aus dem SSCam-Test war es wert: Die von mir zuvor beobachteten periodischen Fork-Häufungen (kurzlebige Kindprozesse mit fast identischer Größe zum Hauptprozess) sind eindeutig SSCam zuzuordnen — mit SSCam deaktiviert traten während der gesamten Testdauer keine zusätzlichen Prozesse mehr auf. Das ist aber ein separates Phänomen, nicht die Ursache des linearen Grundwachstums.
Gescheitert: Devel::MAT/pmat-leakreport für einen Heap-Dump-Vergleich. Drei Versuche (bis zu 30 Minuten Laufzeit mit ~99% CPU), keiner lieferte auch nur eine Ausgabezeile. Auf meiner Hardware (Celeron J4125) für einen Heap dieser Größe offenbar nicht praktikabel.
Aktuell laufend: Weiterer Gruppentest, als nächstes die komplette Lichtsteuerung (16 DOIFs, vorab per DEF-Inhalt statt nur Namen verifiziert). Beschattung, Lüftung und HMCCU selbst bewusst für zuletzt aufgehoben.
-----------------
Falls jemand eine Idee hat, wo ich noch nicht gesucht habe, gerne posten.
Kurzer Zwischenstand, was bisher erfolgt ist:
1: Neuer Container mit aktuellen Versionsständen der Images angelegt und FHEM-Installation darauf laufen lassen. Keine Änderung. Im Schnitt 200 MB/h Speicherzuwachs.
2: MALLOC_ARENA_MAX=2 eingestellt. Keine Änderung. Wieder auf Standard gestellt.
3: Gruppenweise die Device disabled. Keine Änderung.
4: Zur Nachverfolgung nach altem Thread "Speicherlecks gefunden" (2020, Rudolf König) FHEM-TIMER-TABELLE (%main::intAt) und DOIF-Timer-Trigger in Monitoring aufgenommen. Ergebnis: IntAt-Anzahl (291) und DOIF_TimerTrigger (218) bleiben über drei Messungen (30 Min. Abstand) gleich - der Timer-Tabellen-Befund vom Vormittag (stabil, kein Wachstum) bestaetigt sich weiterhin, auch nach mehreren Neustarts in Folge.
5: Script eingerichtet, so dass FHEM neu startet wenn der Speicher zu 83% voll ist, da ich das nicht immer beobachten und manuell eingreifen kann.
Ergo: Immer noch keinen Verursacher gefunden und nur eine Notlösung gebastelt. Sehr unbefriedigend anch stundenlanger Arbeit. :-(
Grüße Jürgen
Falls du den SF‑Thread nicht aktiv verfolgst: Dort bin ich mittlerweile ziemlich tief eingestiegen und konnte mehrere potenzielle Speicherleaks identifizieren und beheben -> https://forum.fhem.de/index.php?msg=1369510.
Ein kontinuierlicher Speicherzuwachs von rund 200 MB pro Stunde ist meiner Meinung nach sehr ungewöhnlich. Ich würde dringend empfehlen, Speicheranalysetools wie freezemon nur bei einem konkreten Verdacht einzusetzen und nicht dauerhaft mitlaufen zu lassen — insbesondere dann, wenn bereits ein auffälliges Verhalten vorliegt. Dauerhaftes Monitoring kann selbst zusätzliche Effekte erzeugen oder Messwerte verfälschen.
Inzwischen habe ich auch ein verstärktes Augenmerk auf Perl‑XS‑Module gelegt, da dort subtilere Speicherprobleme auftreten können, die im reinen Perl‑Layer nicht sichtbar sind. Vertreter dieser Perl-Module sind z.B. JSON::XS, XML::Parser, Digest::SHA / Digest::MD5 - die Liste ist sicher lang.
Zur Beobachtung/Messung der RAM-Entwicklung verwende ich diesen Code in 99_MyUtils.pm:
############################################################################################################
# RAM Verbrauch von Perl ermitteln und mit "<DbLog-Device>" speichern
# Aufruf mit: { psize("<DbLog-Device>") }
############################################################################################################
sub psize {
my ($dblog_dev) = @_;
my $ts = FmtDateTime(time);
my $ret = "$ts|psize|manual|manual|size|";
my $v = `awk '/VmRSS/{print \$2}' /proc/$$/status`;
$ret .= sprintf("%.2f", (rtrim($v) / 1024));
$ret .= "|MB";
fhem("set $dblog_dev addCacheLine $ret") if $dblog_dev;
psize_full ($dblog_dev);
return;
}
sub psize_full {
my ($dblog_dev) = @_;
my $ts = FmtDateTime(time);
my $ret = "$ts|psize|auto|auto|memfull|";
my %m;
# /proc/$$/status – schnelle Werte
open my $fh1, "<", "/proc/$$/status" or return;
while (<$fh1>) {
$m{VmRSS} = $1 if /^VmRSS:\s+(\d+)/;
$m{VmHWM} = $1 if /^VmHWM:\s+(\d+)/;
$m{VmSize} = $1 if /^VmSize:\s+(\d+)/;
}
close $fh1;
# /proc/$$/smaps_rollup – präzise Werte
if (open my $fh2, "<", "/proc/$$/smaps_rollup") {
while (<$fh2>) {
$m{Rss} = $1 if /^Rss:\s+(\d+)/;
$m{Pss} = $1 if /^Pss:\s+(\d+)/;
$m{Shared_Clean} = $1 if /^Shared_Clean:\s+(\d+)/;
$m{Shared_Dirty} = $1 if /^Shared_Dirty:\s+(\d+)/;
$m{Private_Clean} = $1 if /^Private_Clean:\s+(\d+)/;
$m{Private_Dirty} = $1 if /^Private_Dirty:\s+(\d+)/;
$m{Swap} = $1 if /^Swap:\s+(\d+)/;
}
close $fh2;
}
# Ausgabe in MB
my $fmt = sub { sprintf("%.2f", $_[0] / 1024) };
my $ram .= join ", ",
"RSS=".$fmt->($m{VmRSS}), # Tatsächlich belegter RAM
"HWM=".$fmt->($m{VmHWM}), # Peak‑RAM seit Start (super für Leak‑Analyse)
"PSS=".$fmt->($m{Pss}), # Proportionaler Speicherverbrauch (Shared wird anteilig gerechnet)
"Priv=".$fmt->($m{Private_Clean} + $m{Private_Dirty}), # Speicher, der nur dein Prozess nutzt
"Shared=".$fmt->($m{Shared_Clean} + $m{Shared_Dirty}), # Speicher, der mit anderen Prozessen geteilt wird
"Swap=".$fmt->($m{Swap}), # Ausgelagerte Pages
"VSize=".$fmt->($m{VmSize}); # Virtueller Adressraum (meist uninteressant)
$ret .= $ram."|MB";
Log3 ('global', 1, "global - RAM psize_full: " .$ram);
fhem("set $dblog_dev addCacheLine $ret") if $dblog_dev;
}
Wenn man die Werte nur in das Logfile schrieben möchte und kein DbLog nutzen will, kann man den Funktionsaufruf mit einem at so ausführen:
define AT.pSize at +*00:01 { psize () }
@DS_Starter:
Danke für die ausführliche Rückmeldung und den Verweis auf den SF-Thread!
Habe deine dortigen Funde geprüft (Array-Kopie-Leck in _calcDataEveryFullHour, AI::FANN-Storable-Fixes). Größenordnung passt bei mir leider nicht zusammen: Dein Sprung liegt bei ~3 MB/Stundenwechsel, meiner bei durchgehend 176–220 MiB/Stunde. Zudem habe ich SolarForecast bereits komplett deaktiviert getestet (6,7 h, disable=1) – keinerlei Effekt auf die Rate. SolarForecast ist bei mir also sauber ausgeschlossen, unabhängig von deinen Fixes dort.
Zu Freezemon: läuft bei mir seit Tagen mit disable=1 von Anfang an gesetzt (nicht nachträglich per set inactive). Code-Review von 98_FREEZEMON.pm bestätigt: In dem Fall wird beim Define gar nicht erst gewrappt (CallFn/Log3/etc. bleiben unberührt), Notify bricht sofort ab. Insofern sollte hier kein Störfaktor vorliegen.
Dein psize/psize_full-Code ist eine sehr gute Ergänzung – baue ich mir gleich ein, insbesondere die Aufschlüsselung Private/Shared/Swap könnte uns eine Ebene zeigen, die ps aux nicht hergibt.
Zum XS-Modul-Hinweis: Das deckt sich mit einem eigenen, noch offenen Verdacht (hatte IO::Async/Net::Async::Ping als XS-Module näher angeschaut, aber ungenutzt vorgefunden). Werde XML::Hash::XS (aktiv von FritzSmart genutzt) und die XML-RPC-Ebene von HMCCU/HMCCURPCPROC als nächstes ins Visier nehmen, sobald die genauere psize_full-Messung zeigt, in welche Richtung es geht.
Falls du eine Idee hast, warum die Rate bei mir völlig unabhängig von Tageszeit und 9 bereits einzeln ausgeschlossenen Modul-/DOIF-Gruppen konstant bei ~180-220 MiB/h bleibt (Details siehe Thread) – jeder Hinweis ist willkommen, du kennst dich in den Kern-Modulen deutlich besser aus als ich.
Hallo Jürgen,
ZitatFalls du eine Idee hast, warum die Rate bei mir völlig unabhängig von Tageszeit und 9 bereits einzeln ausgeschlossenen Modul-/DOIF-Gruppen konstant bei ~180-220 MiB/h bleibt (Details siehe Thread)
Das ist wirklich äußerst hoch und die Ursache liegt vermutlich tiefer in der Speicherallokation bzw. dem Verfahren wie Perl Speicher anfordert. Möglicherweise ein Problem der Perl-Version die an der Version deines Linux auf dem Synology Docker Image hängt. Hast du die Probleme nur dort?
Denn nach meinem Kenntnisstand isoliert Docker Perl-Version und DSM-Version im Docker, dennoch können XS‑Module, malloc‑Strategien und glibc‑Versionen durchaus Speicherleaks, Fragmentierung oder Memory‑Wachstum verursachen.
Die Abhängigkeit liegt aber nicht zwischen DSM und Perl, sondern zwischen:
* Perl-Version ↔ glibc-Version im Docker-Image
* XS‑Module ↔ Perl‑ABI ↔ glibc‑Allocator
* Kernel‑Features ↔ XS‑Module, die low-level arbeiten
Ich teste gerade bei mir einen Ansatz der direkt an der Speicherallokation wirkt.
Im Anhang ist ein Auszug aus meinem Wiki. Du kannst es mal ausprobieren ob du damit bei dir eine Änderung erreichst.
Hallo DS_Starter,
danke für den Hinweis und den Wiki-Auszug. Ich habe ihn heute getestet:
- MALLOC_MMAP_THRESHOLD_=65536 und MALLOC_TRIM_THRESHOLD_=65536 per Container-Neuerstellung (docker-compose) gesetzt und im FHEM-Prozess per %ENV bestätigt.
- Messung mit psize_full (RSS/Data/Swap), 12:10–12:35: Zuwachs je 5 min 17,5 / 17,7 / 16,8 / 16,9 / 16,3 MB, Mittel 17,0 MB (≈ 204 MB/h). Referenz ohne die Variablen am Vortag: 16,7 MB je 5 min. Swap=0.
- Ergebnis: kein Effekt. Das Wachstum liegt vollständig im Datensegment, der Schwellwert-Mechanismus scheidet bei mir damit als Ursache aus.
Zu deinen Fragen:
- Perl/glibc: Der Wechsel von fhem/fhem:latest (Perl 5.38.5) auf ghcr.io/fhem/fhem-docker:5-bookworm (Perl 5.40.5) am 26.09. hat die Rate nicht verändert (ca. 193 MB/h). Beide Images basieren auf Debian Bookworm, die glibc-Version habe ich nicht variiert. Kernel und Hardware (Synology DS720+, Docker) blieben gleich.
Weitere Fakten, falls sie dir helfen:
- Die Rate ist linear und unabhängig von der Tageszeit (185–205 MB/h). Neun Modul-/DOIF-Gruppen (u. a. SolarForecast, SSCam, FritzSmart komplett) wurden einzeln deaktiviert, ohne Effekt. apptime und Freezemon sind ausgeschlossen.
- Fork-Kinder sind COW-Kopien und für das Wachstum nicht verantwortlich.
Nächste Schritte bei mir: Diff von Konfiguration und Modulen zwischen guter Phase (Backup 21.09.) und schlechter Phase (28.09.), danach ein Rollback der am 22.09. aktualisierten Dateien. Falls du zuerst bestimmte Kernpfade (z. B. MQTT2_SERVER, FHEMWEB, XS-Module) isolieren würdest, wäre ich für einen Hinweis dankbar.
So langsam gehen mir (und der KI) die Ideen aus, an was es noch liegen und wie man das testen kann. Ich fürchte langsam wirklich, und das wäre wegen der umfangreichen Installation der Horror für mich, dass ich FHEM von Grund auf neu aufsetzen muss.
Hallo bmwfan,
ich habe damals, als ich ein Speicherproblem hatte, die Module nicht deaktiviert sondern gelöscht (natürlich vorher gesichert).
Wer sagt denn, dass ein "disable", "ignore", "inactive" vom jeweiligen Entwickler richtig umgesetzt wurde?
Einen Versuch ist es wert!
Gruß, Robert
Ich weiß nicht, ob es hier (auch) das Problem ist aber seit bzw. vor einer Woche habe ich einen Drucker ersetzt (HP).
Von dem (also dem alten Drucker) wurden Statistik- und Verbrauchsdaten mit HTTP-MOD abgefragt (attr-Template).
Seit der neue Drucker, ebenfalls HP (selbe IP), im Netz hängt, hat fhem auch "Sägezahn" bzgl. Speicher.
Nicht so krasse 200MB/h aber alle 2 Tage booten.
Das mit dem Drucker war nur mein Verdacht, da es eben losging, wo ich den Drucker getauscht hatte...
Habe die beiden HTTP-MOD deaktiviert, seither ist Ruhe...
Also die HTTP-MODs liefen nicht ins leere, IP war ja da aber der neue Drucker leifert(e) halt nichts (mehr).
Wie geschrieben, mag hier nicht passen/helfen, wollte es nur loswerden...
Gruß, Joachim
Bei HTTPMOD hatte ich kürzlich auch Strukturen für potenzielles Speicherwachstum entdeckt und bei mir gepatcht.
Da die Änderungen bei mir noch im Test laufen, habe ich sie noch nicht kommuniziert.
Möglicherweise helfen die angepassten Module im vorliegenden Fall, was gleichzeitig die Wirksamkeit der Änderungen bestätigen würde.
Weiterhin wäre mein Hinweis auch mal den eigenen Code in der 99_MyUtils anzuschauen. Möglicherweise hast du dir dort ein Problem eingebaut was jetzt zum Tragen kommt. Wenn du magst, kannst du die Datei auch mal bereitstellen zum Check.
Hallo Heiko,
danke für die Module und den Hinweis auf die 99_myUtils.pm. Bei mir wäre der Effekt ohnehin begrenzt, ich habe nur ein HTTPMOD-Gerät mit einem Abruf alle 12 Stunden.
Meine 99_myUtils.pm habe ich durchgesehen: keine dateiweiten Daten, die wachsen, movingAverage begrenzt auf 25 Einträge, die Funktion für die Anwesenheit liest nur Readings. Wenn du sie dir trotzdem anschauen möchtest, hänge ich sie gern an.
Zum Stand, in Kurzform:
Zeitlinie: Aus den SYSMON-Daten (RAM im Minutentakt) beginnt die hohe Rate (ca. 200 MB/h) am 09.09. um 18:10 mit einem Neustart, endet am 14.09. um 21:53 mit einem Neustart (danach 8 Tage nur ca. 15 MB/h) und kommt am 22.09. um 09:40 mit einem Neustart zurück. Konfiguration und Module waren an den letzten beiden Starts identisch. Die Rate wird also offenbar beim Prozessstart festgelegt.
Ausgeschlossen: Docker-Image und Perl-Version (5.38 → 5.40), MALLOC_MMAP_THRESHOLD_/MALLOC_TRIM_THRESHOLD_ (Rate unverändert, 17 MB je 5 Minuten), neun DOIF-Gruppen, SolarForecast und ein Start ganz ohne FritzSmart-Gerät. Ein Test mit längerem Abfrageintervall der Shelly-Geräte senkte das Wachstum nur um etwa 8 %.
Beobachtung: Das Wachstum liegt vollständig im Datensegment (kein Swap), ca. 1,5 Ereignisse und ca. 1 ausgehende Verbindung pro Sekunde.
Meine Frage: Gibt es Fälle, in denen der Zustand beim Start (Reihenfolge der Initialisierung, Timer, Verbindungen) die Wachstumsrate eines FHEM-Prozesses festlegt? Und kennt jemand Werkzeuge, um den Speicher einer laufenden Instanz nach Perl-Strukturen aufzuschlüsseln, ohne die ganze Instanz zu stoppen? Devel::MAT ging bei mir an der Größe des Dumps (3,9 GB) vorbei.
Gruß, Jürgen
Vllt. von Interesse -> https://forum.fhem.de/index.php?msg=1369762
Hallo Heiko,
habe Deine Anregung aufgegriffen und malloc_trim(0) bei mir getestet.
Auf dem fhem-docker-Image (Perl 5.40.5 unter /usr/local/bin/perl) lässt sich FFI::Platypus nicht über apt einbinden, weil das Image sein eigenes Perl mitbringt. Bei mir ging es mit cpanm -L /usr/src/app/3rdparty FFI::Platypus (Compiler vorübergehend nachinstalliert).
Ergebnis bei einem FHEM-Prozess mit 3,8 GB RSS: rc=1, RSS 3817,8 → 3817,9 MB, also kein Effekt, und kein Hänger. Bei mir ist das Wachstum demnach kein freier, zurückgehaltener Heap-Speicher.
Zusätzlich malloc_stats() bei 3,8 GB RSS: In Arena 0 sind von 3.805.581.312 Bytes nur 685.584 frei (0,018 %). Bei mir ist der Heap also praktisch vollständig belegt, nicht fragmentiert.
Danke für die Idee. Da hilft nur: Weiter suchen.
Ich bleib dabei, wenn der thread hier im Anfänger Bereich liegt, sieht den Rudi nur wenn ihn drauf aufmerksam macht.
@DasQ: Ich hatte keinen anderen Bereich gefunden, wo ich meinte das Thema gehört dorthin. Deswegen hier. Wie mache ich denn Rudi darauf aufmerksam? Eine PM oder wie wird das sonst gemacht?
Ne lass das mal mit dem Anschreiben.
Ich war auch schon auf der Suche nach dem forumsbereich ,,Bug Report"
Aber den gibt es ganz einfach nicht. ::)
@bmwfan, wieviel RAM hat dein FHEM eigentlich zur Verfügung? Du schreibst ein sehr umfangreiches System zu betreiben. Es wäre einen Test wert im global Device das Attr blockingCallMax auf einen sehr kleinen Wert, z.B. 2/3, zu setzen und zu schauen was passiert. Mich irritieren immer noch deine außergewöhnlich hohen Steugerungsraten.
Mein NAS hat 10GB und der FHEM-Container ist auf 6 GB "begrenzt" was bedeutet, dass FHEM dann zu einem Neustart gezwungen wird. Erst wird der RPC-Server OFF geschalten und mit Verzögerung dann FHEM neu gestartet..
Die Ursache könnte gefunden sein. Es scheint ein Zusammenspiel von Freezemon, disable 1 und fm_logfile zu sein. Ich lasse jetzt noch einen 24h-Test laufen und wenn es das war, stelle ich die ausführliche Erklärung vor.
Bin nach der tagelangen Suche und vielen Tests mal vorsichtig optimistisch.
ZitatMein NAS hat 10GB und der FHEM-Container ist auf 6 GB "begrenzt"
Auch wenn es viel ist, könnte es bei steigenden RAM Footprint + vielen forks (Blockingcalls) dennoch eng werden.
Deswegen ist der Test durchaus mal wert. Auch viele SVG-Plots mit FHEMWEB Einstellung plotfork=1 führen zu forks mit entsprechenden temp. Speicherbedarf. Mit dem neuen DbLog SVG-Management ist plotfork=0 die richtige Einstellung zzgl. der richtigen Einstellung im DbLog (plotCacheLifetime/plotCacheKeepalive). Dann entstehen kein forks in diesem Kontext.
Und freut mich dass du eine Spur hast. Wenn das passt, können die oben erwähnten Dinge bei weiteren Optimierungen helfen.
Vielleicht ein paar Anmerkungen:
- Es gibt einen (sehr langen) "Haupthread" zum Thema "Hauptspeicher wird verbraucht": Cannot fork: Cannot allocate memory | BlockingInformParent (https://forum.fhem.de/index.php?topic=84372.0). Vermutlich ist der dem TE bekannt, zumindest scheint einiges vor dem Posten gemacht worden zu sein, was auch dort thematisiert worden ist.
- "Anfängerfragen" ist m.E. keine besonders glückliche Wahl, was den Forenbereich angeht. Soweit mir bekannt, liest Rudi hier nur sporadisch mit, meine Empfehlung wäre, zu fhem.pl (help zeigt dazu an: Module: fhem.pl Maintainer: rudolfkoenig Forum: Sonstiges) einen neuen Post (Verschieben bekommt Rudi in der Regel nicht mit) zu starten und kurz hierher zu verlinken, wenn man Rudi gezielt dazu einladen möchte, sich damit zu befassen.
@DS_Starter hat jüngst (heute?) ein neues Modul "MemSaver" (https://forum.fhem.de/index.php?topic=137058.msg1369810#msg1369810) vorgestellt, mit dem man ggf. auch versuchen kann, solche Probleme einzugrenzen.
[Teil-OT an @DS_STarter]
Danke für die vielen "Kleinigkeiten", die du jüngst aufgespürt hast!
Mir ist in dem Zusammenhang noch ein etwas älterer Optimierungsvorschlag in Erinnerung geblieben: EPOLL von @jw2013: https://forum.fhem.de/index.php?msg=1300805. HAt zwar nichts mit Speicherverbruach zu tun, aber vielleicht sollte man sich mit dem dortigen Thema auch nochmal auseinandersetzen, mir fehlen dazu sowohl die vertieften Kenntnisse wie auch Zeit...?
@Beta-User,
Danke für den Hinweis. Aktuell läuft noch ein 24h-Test, der aber sehr gut aussieht. Fast kein Speicherwachstum mehr. Sobald der abgeschlossen ist, stelle ich eine Zusammenfassung herein und werde Deinen Vorschlag, einen Thread in fhem.pl zu eröffnen (nur Problem und dann die Lösung), aufnehmen. Der Fehler war wirklich nur äußerst aufwendig und mit den Hinweisen aus dem Forum zu entdecken, wurde aber meines Wissens nach (zumindest haben weder die KI noch ich etwas dazu gefunden) bisher noch nicht beschrieben. Ich kann mir durchaus vorstellen, dass daraus tatsächlich Änderungen im Code (aber wo, da nicht nur freezemon beteiligt ist) notwendig sind und dass es den einen oder anderen Nutzer auch interessiert oder sogar betrifft.
Das neue Modul von DS_Starter habe ich schon mitgeteilt bekommen, werde es aber erst nach dem Test (keine Änderung im laufenden Test!) einspielen.
Den genannten Hauptthread habe ich in der Tat vorher nicht gesehen. Bin mit Unterstützung (für die ganzen Befehle) einer KI so vorgegangen, wie ich zu Beginn meiner Berufslaufbahn eigene Programmierfehler gesucht habe. ;)
Hallo zusammen,
die Ursache ist gefunden, und danke an alle, die Hinweise gegeben haben (bertl, MadMax, DS_Starter, Beta-User und weitere)
Kurzfassung
Das Modul Freezemon ersetzt Log3 und legt jeden Aufruf in einer Liste ab, die bei deaktiviertem Gerät nie geleert wird. Bei mir war das Gerät disable 1 mit gesetztem fm_logFile. In der fhem.cfg steht disable alphabetisch vor fm_logFile: Beim Einlesen räumt disable 1 zuerst auf (noch ist nichts gewickelt), danach installiert fm_logFile den Ersatz, und niemand räumt mehr auf. Ergebnis: ca. 100 Datensätze je Sekunde, ca. 200 MB/h, bis zum Neustart.
Da ich mir darunter nichts vorstellen konnte, habe ich die KI um eine Analogie gebeten. Die habe ich dann verstanden :D
Stell dir eine Poststelle vor. Freezemon stellt einen Kopierer neben den Briefkasten, der von jedem Brief eine Kopie in eine Kiste legt (Wickeln). Ein Mitarbeiter leert die Kiste jede Sekunde (der Timer). Beim normalen Betrieb bleibt die Kiste klein.
Bei dir kam es so:
Zuerst die Anweisung "Kopierer entfernen" (disable 1). Es steht aber noch keiner da, also passiert nichts. Der Mitarbeiter wird gar nicht erst eingestellt (kein Timer, weil das Gerät deaktiviert ist).
Danach die Anweisung "Kopierer aufstellen" (fm_logFile). Der steht jetzt da und kopiert alles aber niemand leert die Kiste und niemand entfernt den Kopierer, denn die Anweisung "entfernen" kommt nur einmal, und zwar schon vorher.
Behoben mit deleteattr <name> fm_logFile, save, Neustart. Danach 0,55 bis 1,7 MB/h (Stand [WERT: Datum, Uhrzeit, RSS und Zuwachs seit Start]; 04.10. 02:01 bis 09:01: 334,9 → 338,8 MB).
Wie es sich zeigte (Zeitlinie aus Minutenwerten)
- bis 09.09. 18:10: 13-18 MB/h
- ab Neustart 09.09. 18:10: ca. 205 MB/h
- 14.09. 21:53 bis 22.09. 09:38: 15-28 MB/h (Freezemon war vermutlich kurz aktiv und wurde dann zur Laufzeit deaktiviert, was den Ersatz entfernt; Schlussfolgerung aus dem Freeze-Log)
- ab Neustart 22.09. 09:40: ca. 190-207 MB/h bis 03.10.
Die Konfiguration war in allen Sicherungen ab 07.09. gleich. Nicht bestätigt: was am 09.09. gegen 18:00 den Zustand des Prozesses geändert hat.
Was es nicht war (jeweils gemessen)
- Image/Perl-Version, einzelne Module (DOIF-Gruppen, SolarForecast, FritzSmart, Shelly-Abfragen), Start ganz ohne Fritz-Gerät: keine oder kaum Wirkung. Sie waren nur Quellen vieler Log3-Aufrufe.
- Allokator: MALLOC_TRIM_THRESHOLD_, malloc_trim(0) (RSS 3817,8 → 3817,9 MB) und malloc_stats() (Arena zu 99,98 % belegt) zeigen: kein zurückgehaltener Speicher, sondern belegter.
Prüfen, ob man betroffen ist
{ join(", ", map { "$_ disable=".AttrVal($_,"disable",0)." fm_logFile=".AttrVal($_,"fm_logFile","-") } devspec2array("TYPE=freezemon")) }Ein Freezemon mit disable=1 und gesetztem fm_logFile ist die Konstellation. Allgemein zeigt { require B;; my $cv=B::svref_2object(\&Log3);; $cv->FILE } (und entsprechend für CallFn, AnalyzeCommand, HttpUtils_NonblockingGet), ob eine Kernfunktion ersetzt wurde (Original: fhem.pl).
Nebenbefunde, die anderen helfen können
- Docker: docker restart ohne Zeitlimit wartet nur 10 Sekunden. FHEM wartet selbst bis 10 Sekunden (Server shutdown delayed ... max 10 sec), HMCCU weitere 8: FHEM wurde bei mir mitten im Herunterfahren beendet, fhem.save wurde nicht geschrieben, Zustände gingen verloren (Teile der Hausautomatisierung waren verstellt). Abhilfe: docker restart -t 60 bzw. stop_grace_period: 60s in der Compose-Datei.
- FFI::Platypus im fhem-docker-Image: Das Image nutzt /usr/local/bin/perl. Die apt-Anleitung für das System-Perl passt dort vermutlich nicht (Nicht bestätigt, nicht probiert). Bei mir ging es mit nachinstalliertem Compiler und cpanm -L /usr/src/app/3rdparty FFI::Platypus (die README des Images empfiehlt CPAN statt apt).
- Warnung: Ein Skript, das alle Hashes und Arrays über Devel::Gladiator::walk_arena durchlief, und Devel::Size haben bei mir FHEM abstürzen lassen (Segfault in libperl.so bzw. Size.so). Die reine Zählung von Typen und Zeichenketten lief mehrfach ohne Absturz, hält aber Speicher dauerhaft belegt.
Noch offen: Rückmeldung des Freezemon-Maintainers, den ich in einem neuen Thread detaillierter informiert habe. Ich habe den Fehler natürlich nur auf meinem System gesehen.
Gruß Jürgen
P.S.: Wie kann ich den Thread im Betreff als gelöst benennen?
Zitat von: bmwfan am 04 Oktober 2026, 18:22:42P.S.: Wie kann ich den Thread im Betreff als gelöst benennen?
in deinem ersten Post das Topic editieren
@Wzut:
Das wollte ich, finde aber keinen Button o.ä. dafür und ein Doppelklick auf die Betreffzeile geht auch nicht. Ich habe Buttons für Drucken, Ungelesen markieren, e-mail, aber nichts zum editieren.
Habs gefunden. Muss den ersten Post bearbeiten, dann komme ich an den Betreff