Hallo zusammen,
ich habe das (neue) Modul 98_Analyze eingecheckt und ist morgen früh im Update enthalten.
Es gab es bereits schon seit langer Zeit in meinem contrib in einer Alpha-Version. Ich habe es nun komplett erneuert und erweitert.
Dieses Modul gehört zu dem Trio von FHEM System Management Modulen:
- Installer
- MemSaver
- Analyze
Was macht das Modul und wie hilft es:
Analysiert den Speicherverbrauch des FHEM-Prozesses: die Größe von Devices und ihrer Teilstrukturen, von Modul-Hashes und von den Kern-Hashes von FHEM, den Prozessspeicher, Timer, Filedeskriptoren und Kindprozesse. Snapshots können gespeichert und miteinander verglichen werden. Strukturen, die über die Zeit kontinuierlich wachsen, werden als Speicherleck-Kandidaten gemeldet. Das Modul hilft dabei, das Device, das Modul oder die Datenstruktur zu finden, die für einen wachsenden Speicherverbrauch verantwortlich ist.
Analyze ist einer von mehreren Bausteinen für die Systempflege und Analyse: MemSaver hält den RAM von FHEM so weit wie möglich sauber und klein, Analyze zeigt, wo der Speicher verwendet wird und welches Modul, Device oder welche Datenstruktur für sein Wachstum verantwortlich ist, und Installer sorgt für saubere Installationen und Updates der Perl-Pakete, die FHEM-Module benötigen, einschließlich der Voraussetzungen dieses Moduls.
Alle Messungen laufen in einem eigenen Prozess (BlockingCall). FHEM wird nicht blockiert, und ein Absturz von Devel::Size bei einem einzelnen Device reißt FHEM nicht mit.
Grundlagen
- Analyze misst und berichtet nur, es gibt keinen Speicher frei. Um den RAM klein zu halten, dient MemSaver.
- Der eigene Prozess ist eine Kopie von FHEM zum Zeitpunkt des Aufrufs. Alle Größen beschreiben deshalb genau diesen Zeitpunkt.
- Größen werden exklusiv gezählt: Jede Speicheradresse wird nur einmal gezählt, Referenzen auf andere Devices (zum Beispiel IODev) und auf die Kern-Hashes von FHEM werden nicht verfolgt. Anders als bei Devel::Size::total_size wird nichts doppelt gezählt, die Größen der Devices lassen sich also addieren. Die Werte sind Näherungen mit wenigen Prozent Abweichung.
- Die Snapshot-Ablage des Moduls selbst wird nicht mitgemessen, sonst würde das Modul immer als wachsendes Objekt erscheinen.
- Die Summe aller gemessenen Strukturen wird als attributed (zugeordnet) ausgewiesen. Der Rest der Prozessgröße (rss) erscheint als not attributable (nicht zuordenbar). Er besteht aus dem Perl-Interpreter, geladenem Programmcode, Shared Libraries, Speicherfragmentierung und - ohne deepScan - den file-scope Variablen der Module.
- Die Prozessgröße (rss) wächst nach dem Start von FHEM üblicherweise, bis der Perl-Speicher "warmgelaufen" ist, und schrumpft danach selten. Snapshots sollten deshalb nach einigen Stunden Laufzeit erstellt werden.
- private, pss und shared ändern sich immer dann, wenn Kindprozesse (BlockingCall) starten oder enden. Für Trends wird rss verwendet, die anderen Werte sind nur bei gleicher Anzahl Kindprozesse vergleichbar.
Typischer Ablauf zur Analyse:
set <name> snapshot t0
... einige Stunden warten ...
set <name> snapshot t1
get <name> diff t0 t1 - was hat sich zwischen zwei Snapshots verändert
get <name> leakCandidates - ab 3 Snapshots: Objekte, die kontinuierlich wachsen
set <name> xHashDetail $defs{myDevice}{helper} - ein auffälliges Objekt genauer ansehen
Alternativ erstellt attr <name> autoSnapshot 6 automatisch alle 6 Stunden einen Snapshot.
Voraussetzungen:
- Devel::Size - zwingend erforderlich. Ohne dieses Modul kann kein Device angelegt werden.
- Optional: PadWalker - damit erfasst deepScan auch die file-scope my Variablen der Modul-Dateien. Ob es verfügbar ist, zeigt das Internal PADWALKER.
- Die Perl-Module Storable, MIME::Base64, Scalar::Util, Time::HiRes, POSIX und B (alle Bestandteil von Perl) sowie das FHEM-Modul Blocking.
Ich hoffe, dass dieses Modul hilfreich sein wird Module und Strukturen zu finden, die zu einem stetig steigenden Speicherverbrauch beitragen und wie hoch dieser Anteil ist. Manche Module können durch Datensammlung Speicher akkumulieren was in diesen Fällen keinen Fehler darstellt. Die stetigen Anteile sollten allerdings gering sein nachdem FHEM nach dem Systemstart ein Plateau erreicht hat und alle Strukturen für den normalen Betrieb geladen wurden.
Durch regelmäßige Snapshots kann man das Speicherwachstum zu bestimmten Zeiten (z.B. Tageswechsel) analysieren.
Über die Snapshots lässt sich das Speicherwachstum über einen längeren Zeutraum verfolgen.
Im Anhang eine Beispielausgabe von "get ... leakCandidates".
LG,
Heiko
Hallo Heiko,
ich habe mal Dein neues Modul installiert und hier ein Ergebnis.
Würdest Du das schon als Speicher-Leak bezeichnen?
deepScan habe ich aktiviert.
Leak candidates: objects growing in at least 12 of 15 intervals without ever shrinking
Snapshots: auto_20261107_185930, auto_20261107_215809, auto_20261108_005809, auto_20261108_035809, auto_20261108_065809, auto_20261108_095809, auto_20261108_125809, auto_20261108_155809, auto_20261108_185809, auto_20261108_215809, auto_20261109_005809, auto_20261109_035809, auto_20261109_065809, auto_20261109_095809, auto_20261109_125809, auto_20261109_155809 period: 45.0 h
Parts of devices ($defs{device}{key}):
+286.9 kB $defs{FritzOG}{fhem} 74.8 kB -> 93.3 kB -> 111.4 kB -> 127.5 kB -> 141.9 kB -> 164.7 kB -> 178.2 kB -> 193.9 kB -> 211.0 kB -> 229.0 kB -> 247.2 kB -> 279.1 kB -> 298.9 kB -> 319.6 kB -> 341.0 kB -> 361.7 kB (6.4 kB/h)
+279.0 kB $defs{FritzWohnzimmer}{fhem} 108.5 kB -> 132.4 kB -> 149.5 kB -> 165.8 kB -> 189.2 kB -> 203.5 kB -> 218.3 kB -> 234.0 kB -> 250.3 kB -> 265.4 kB -> 298.5 kB -> 314.6 kB -> 333.6 kB -> 351.6 kB -> 369.2 kB -> 387.5 kB (6.2 kB/h)
+35.2 kB $defs{FritzBox}{fhem} 82.9 kB -> 92.1 kB -> 94.7 kB -> 97.2 kB -> 99.2 kB -> 101.3 kB -> 102.9 kB -> 104.7 kB -> 106.4 kB -> 108.0 kB -> 109.9 kB -> 111.3 kB -> 113.0 kB -> 114.7 kB -> 116.4 kB -> 118.1 kB (800 B/h)
+28.9 kB $defs{FritzDach}{fhem} 71.1 kB -> 73.0 kB -> 74.7 kB -> 76.7 kB -> 78.4 kB -> 80.6 kB -> 84.3 kB -> 86.0 kB -> 87.8 kB -> 89.5 kB -> 91.2 kB -> 93.0 kB -> 94.9 kB -> 96.6 kB -> 98.3 kB -> 100.0 kB (657 B/h)
Devices:
+290.8 kB FritzOG 203.1 kB -> 223.4 kB -> 241.5 kB -> 259.2 kB -> 272.5 kB -> 295.8 kB -> 309.9 kB -> 325.5 kB -> 342.1 kB -> 360.1 kB -> 378.8 kB -> 410.8 kB -> 430.5 kB -> 449.5 kB -> 471.0 kB -> 493.9 kB (6.5 kB/h)
+274.5 kB FritzWohnzimmer 242.3 kB -> 263.9 kB -> 281.0 kB -> 295.6 kB -> 319.6 kB -> 335.0 kB -> 348.7 kB -> 365.0 kB -> 381.8 kB -> 396.4 kB -> 429.5 kB -> 445.6 kB -> 465.1 kB -> 480.9 kB -> 498.5 kB -> 516.8 kB (6.1 kB/h)
+29.5 kB FritzDach 173.9 kB -> 175.7 kB -> 177.4 kB -> 180.0 kB -> 181.1 kB -> 183.8 kB -> 187.0 kB -> 188.7 kB -> 191.1 kB -> 192.2 kB -> 194.0 kB -> 195.7 kB -> 198.1 kB -> 199.9 kB -> 201.6 kB -> 203.3 kB (670 B/h)
Device types (sum of devices):
+636.4 kB FritzSmart 1.19 MB -> 1.25 MB -> 1.29 MB -> 1.33 MB -> 1.36 MB -> 1.41 MB -> 1.44 MB -> 1.48 MB -> 1.52 MB -> 1.55 MB -> 1.60 MB -> 1.65 MB -> 1.70 MB -> 1.73 MB -> 1.77 MB -> 1.82 MB (14.2 kB/h)
Interpretation:
part/dev/type : data inside a device grows (readings, helper hashes, queues, caches) -> look at the TYPE and use "set xHashDetail \$defs{device}{key}".
var/pkgvar/file: global or file-scope variables of a module grow (needs deepScan, PadWalker for file-scope variables).
timer/timerdev : timers accumulate -> a module sets timers without removing old ones.
cnt fds/kids : file descriptor or child process leak (e.g. BlockingCall children not ending).
proc unattributed grows but no structure does: memory outside the walked structures (XS/C libraries, fragmentation, file-scope variables without deepScan).
OK
Diff der beiden letzten Snapshots:
count_fds
299
2026-11-09 15:58:15
count_kids
1
2026-11-09 15:58:15
count_timers
230
2026-11-09 15:58:15
crashListCount
0
2026-11-07 18:57:50
proc_private_kB
53540
2026-11-09 15:58:15
proc_pss_kB
166748
2026-11-09 15:58:15
proc_rssPeak_kB
284520
2026-11-09 15:58:27
proc_rssTrend_kBperHour
687.7
2026-11-09 15:58:27
proc_rss_kB
284520
2026-11-09 15:58:27
proc_swap_kB
0
2026-11-09 15:58:15
snapshot_last
auto_20261109_155809
2026-11-09 15:58:15
snapshots
16
2026-11-09 15:58:15
state
done
2026-11-09 15:58:15
unattributed_kB
240991
2026-11-09 15:58:15
myAnalyze
room
System
Attributes
autoSnapshot
3
deleteattr
deepScan
1
deleteattr
maxSnapshots
17
deleteattr
room
System
deleteattr
Help for Analyze Copy for forum.fhem.de Raw definition Select icon Extend devStateIcon Event Monitor (filtered) Delete myAnalyze
Comparison 'auto_20261109_125809' -> 'auto_20261109_155809' period: 3.00 h
Process memory:
rss 279968 kB -> 282268 kB +2300 kB (+767 kB/h)
anon 267732 kB -> 270032 kB +2300 kB (+767 kB/h)
pss 161956 kB -> 166748 kB +4792 kB (+1597 kB/h)
priv 46256 kB -> 53540 kB +7284 kB (+2428 kB/h)
shared 233712 kB -> 228728 kB -4984 kB (-1661 kB/h)
swap 0 kB -> 0 kB +0 kB (+0 kB/h)
attributed +143 kB (attributed to FHEM structures)
unattributed +2157 kB (rest: interpreter, code, fragmentation, file-scope variables)
Counters:
defs 1160 -> 1157 (-3)
fds 302 -> 299 (-3)
kids 1 -> 1 (+0)
ready 0 -> 0 (+0)
select 57 -> 54 (-3)
timers 237 -> 230 (-7)
Timers by function - growth (top 15):
+1 BlockingKill (1 -> 2)
+1 CUL_MAX_SQH (0 -> 1)
Timers by device - growth (top 15):
+1 cm (2 -> 3)
Readings per device - growth (top 15):
+4 FritzOG (80 -> 84)
+1 FritzBox (157 -> 158)
+1 MQTT2_Server_192.168.2.217_14887 (0 -> 1)
+1 MQTT2_Server_192.168.2.217_23695 (0 -> 1)
+1 MQTT2_Server_192.168.2.217_5254 (0 -> 1)
+1 MQTT2_Server_192.168.2.217_5887 (0 -> 1)
+1 telnetPort_127.0.0.1_48906 (0 -> 1)
Parts of devices ($defs{device}{key}) - growth (top 15):
+20.7 kB $defs{FritzOG}{fhem} (341.0 kB -> 361.7 kB)
+18.3 kB $defs{FritzWohnzimmer}{fhem} (369.2 kB -> 387.5 kB)
+2.3 kB $defs{FritzOG}{READINGS} (45.7 kB -> 48.0 kB)
+2.0 kB $defs{cm}{sendQueue} (0 B -> 2.0 kB)
+1.7 kB $defs{FritzDach}{fhem} (98.3 kB -> 100.0 kB)
+1.7 kB $defs{FritzBox}{fhem} (116.4 kB -> 118.1 kB)
+1.4 kB $defs{MQTT2_Server_192.168.2.217_14887}{subscriptions} (0 B -> 1.4 kB)
+1.4 kB $defs{MQTT2_Server_192.168.2.217_23695}{subscriptions} (0 B -> 1.4 kB)
+1.4 kB $defs{MQTT2_Server_192.168.2.217_5254}{subscriptions} (0 B -> 1.4 kB)
+1.4 kB $defs{MQTT2_Server_192.168.2.217_5887}{subscriptions} (0 B -> 1.4 kB)
+1.2 kB $defs{diULANZI}{helper} (3.0 kB -> 4.2 kB)
Devices - growth (top 15):
+23.0 kB FritzOG (471.0 kB -> 493.9 kB)
+18.3 kB FritzWohnzimmer (498.5 kB -> 516.8 kB)
+6.1 kB MQTT2_Server_192.168.2.217_14887 (0 B -> 6.1 kB)
+6.1 kB MQTT2_Server_192.168.2.217_23695 (0 B -> 6.1 kB)
+6.1 kB MQTT2_Server_192.168.2.217_5254 (0 B -> 6.1 kB)
+6.1 kB MQTT2_Server_192.168.2.217_5887 (0 B -> 6.1 kB)
+3.2 kB telnetPort_127.0.0.1_48906 (0 B -> 3.2 kB)
+2.2 kB FritzBox (288.2 kB -> 290.4 kB)
+1.9 kB cm (5.8 kB -> 7.7 kB)
+1.7 kB FritzDach (201.6 kB -> 203.3 kB)
+1.2 kB diULANZI (30.9 kB -> 32.1 kB)
Device types (sum of devices) - growth (top 15):
+44.5 kB FritzSmart (1.77 MB -> 1.82 MB)
+18.6 kB MQTT2_SERVER (713.5 kB -> 732.1 kB)
+1.9 kB CUL_MAX (5.8 kB -> 7.7 kB)
Number of devices per type - growth (top 15):
+3 MQTT2_SERVER (30 -> 33)
File-scope variables of module files (PadWalker) - growth (top 15):
+144.4 kB 01_FHEMWEB.pm %FW_svgData (12.18 MB -> 12.32 MB)
Module files (file-scope variables, PadWalker) - growth (top 15):
+144.1 kB 01_FHEMWEB.pm (13.11 MB -> 13.25 MB)
Hint: for a reliable verdict take at least 3 snapshots some hours apart and use "get leakCandidates".
Einen Screenshot zur Speicherauswertung habe ich mal angehängt.
Dasuntere Diagramm kommt von sysmon.
Ich würde mal sagen, dass es ein Leak gibt. Wobei in 45h der Anstieg mit 636kB in den Perl Strukturen recht übersichtlich ist.
Abhängig vom Zeitpunkt des FHEM Starts kann dieses Wachstum aber auch ein ganz normaler Vorgang bis zu einer Plateau Bildung sein.
Hier kommt es auf eine Langzeitbeobachtung an. Wenn das Wachstum nie aufhört ist der Leak bestätigt.
Es ist natürlich immer die Frage wie störend es ist. Es gibt User die quälen sich mit Wachstumsraten von mehreren MB pro Stunde herum und müssen ihr System recht kurzfristig
immer neu starten. Das sind dann die echten Leak-Kandidaten. ;)
Allerdings sieht dein RSS-Stand recht stark steigend aus, ca. 15MB in dem dargestellten Zeitraum wenn ich es richtig interpretiere. Insbesondere ab 15:10. Vielleicht kommt dann jemand nach Hause?
Das ist schon deutlich, wobei diese Steigung nicht aus den Perl-Strukturen zu kommen scheint sonst würde Analyse andere Werte zeigen. Möglicherweise werden auch Daten in Abhängigkeit von bestimmten Sachverhalten gecacht, ich kenne das Modul nicht. Dann wäre der Anstieg ein Teil der Funktionalität (bei mir ist SolarForecast so ein Modul),
Der diff ist übrigens sehr schwer zu lesen. Ein Screenshot ist bei dem Modul besser geeignet.
In der Summe würde ich sagen, ja ein Leak ist wahrscheinlich. Aber wegen der geringen Datenmenge vermutlich nicht störend.
Eventuell liegt eine Ursache in verwendeten XS/C Modulen. Interessant ist, dass nur Fritz Devices erscheinen. Welche Module nutzt du? -> fheminfo zeigt alles.
Da läuft natürlich noch mehr:
System Info
ConfigType: configFile
SVN rev: 31877
OS: linux
Perl: 5.36.0
uniqueId: 86c...
Modules Model Count
APCUPSD
Back-UPS ES 700G 2
Analyze 1
Astro 1
BRAVIA 1
KD-43XH8505 1
CUL
CUL 2
CUL_MAX 1
CUL_TCM97001
Mebus 2
CUL_WS 1
Calendar 3
DOIF
FHEM 34
DOIFtools 1
ESPEasy 37
EnOcean 2
Eltako_FT55 2
FHEM2FHEM 2
FHEMWEB 3
FS20 15
fs20di 3
fs20s20 1
fs20st 2
fs20st2 1
fs20su 3
FileLog 241
FritzSmart
FRITZ!Box 7590 1
FRITZ!Repeater 2400 2
FRITZ!WLAN Repeater 1750E 2
FRITZ!WLAN Repeater 450E 1
HTTPMOD
clever_tanken_single_station 8
Hideki 6
HourCounter 6
IPCAM 1
IT 22
itremote 6
Installer 1
IrBlaster 1
JsonMod 1
LightScene 1
MAX
HeatingThermostat 7
MQTT2_CLIENT 1
MQTT2_DEVICE 26
SHCB-1 1
SHDW-2 1
SHPLG-S 4
SHPLG2-1 2
SHSW-1 1
eBus_daemon_splitter 1
tasmota_POW 3
tasmota_basic_state_power1 8
zigbee2mqtt_2channel_split 2
zigbee2mqtt_ContactSensor 2
zigbee2mqtt_Light_Intensity_Sensor 1
zigbee2mqtt_Rain_Illuminance_Sensor 1
zigbee2mqtt_TempHumSensor 7
zigbee2mqtt_Water_Leak_Sensor 1
zigbee2mqtt_Wireless_Button 2
zigbee2mqtt_bridge 1
zigbee2mqtt_human_body_movement 3
zigbee2mqtt_plug 4
zigbee2mqtt_plug_w_energy_measuring 7
zigbee2mqtt_scene_controller 1
zigbee2mqtt_smokeDetector 7
MQTT2_SERVER 1
MQTT_GENERIC_BRIDGE 1
MemSaver 1
Modbus 1
ModbusSDM120 1
ModbusSDM72DMV2 1
PID20 4
PRESENCE2
daemon 1
lan-ping 9
SD_RSL 28
SD_WS
SD_WS_107_H 6
SD_WS_27_TH 1
SIGNALduino 3
SVG 188
SYSMON 1
Shelly
generic 1
shelly1 1
shelly1pm 1
shellybulb 1
shellydimmer 1
shellyplug 16
ShellyMonitor 1
TCM
ESP3 1
THRESHOLD 1
TelegramBot 1
WS980 1
WeekdayTimer 11
ZWDongle 1
ZWave
0109-201c-1c03 1
0403-0003-0003 1
Aeotec Limited ZW175 Smart Switch 7 1
Aeotec Limited ZWA021 Thermostatic Valve 1
EUROtronic EUR_SPIRITZ Wall Radiator Thermostat 3
FIBARO System FGWPE/F Wall Plug Gen5 1
HANK Electronics Ltd HKZW-DWS01 Door/Window Sensor 3
Shelly Qubino Wave 1PM 1
Steinel IS140-2 1
at 32
autocreate 1
cmdalias 1
dewpoint 3
dummy 57
eventTypes 1
freezemon 1
holiday 1
logProxy 1
notify 112
readingsGroup 4
readingsWatcher 1
sequence 2
structure 17
telnet 1
watchdog 66
weblink 1
weekprofile 2
Ich habe jetzt mal largeObjectNum auf 10 hochgesetzt.
Noch tut mir der Speicherverbrauch nicht weh. Ist ein Pi4 mit 8 GB und Bookworm.
War mir halt immer mal wieder aufgefallen und da kam mir das Modul gerade recht.
Tatsächlich bin in um den Dreh rum nach Hause gekommen. Allerdings war vor mir schon jemand wieder als anwesend erkannt. Dürfte also soviel nicht ausgemacht haben. Durch die Anwesenheit werden aktuell hauptsächlich die Heizkörper hochgefahren und einige Steckdosen eingeschaltet.
Das sind eine ganze Menge und unterstreicht eigentlich den Anteil von Fritz am Speicherwachstum.
Du kannst dir auch dein am meisten beteiligtes Device nehmen und genauer analysieren:
set ... xHashDetail $defs{FritzOG}
In den Readings (refresh) siehst du die größten Objekte, ganz oben das größte, z.B.:
01_largestObject 1707646, $defs{SolCast}{.tsCache}
Du kannst weiter reingehen:
set ... xHashDetail $defs{SolCast}{.tsCache}
und bekommst wiederum die größte Unterstruktur:
01_largestObject 1165956, $defs{SolCast}{.tsCache}{data}
Das kann man fortführen bis zur letzten Ebene, den eigentlichen Werten. Hier im Beispiel wäre es:
01_largestObject 1535, $defs{SolCast}{.tsCache}{data}{TSO::SolCast::1794178800::10677}
Das ist ein gecachter Wert mit 1,5kB Größe. Die hohe Anzahl der gecachten Werte + der Verwaltungsinformationen macht dann die Größe von $defs{SolCast}{.tsCache}{data} aus.
Vielleicht baue ich noch eine Snapshot Variante ein, mit der man ein spezifisches Objekt über einen längeren Zeitraum snappen und so dessen Entwicklung nachverfolgen kann.
Das kann auch sehr hilfreich sein.
Hallo DS_Starter, hallo Nobbynews,
als Maintainer des Moduls 72_FritzSmart habe ich 8 Devices mit unterschiedlichen Fritz Geräten in meiner Installation laufen. Ich kann keinerlei Speicher "Verbrauch" feststellen.
Für mich wäre List vom Device FritzOG interessant, sofern es nicht ein FBDect Device ist.
Grüße Jörg
Hi Jörg,
das glaube ich dir. Es gibt sicherlich mehr als eine Handvoll Möglichkeiten weshalb bei einem User ein steigender Speicherverbrauch feststellbar ist und bei einem anderen nicht.
Wir suchen ja bereits seit Jahren nach dem Stein der Weisen. ;)
Es können bestimmte Arbeitsmodi sein die Speichermehrverbräuche verursachen oder z.B. bestimmte Versionen der benutzen Perl-Pakete und Version/OS-Kombinationen. Die Perl-Pakete können ihrerseits Speicherprobleme verursachen die wir nicht beeinflussen können. Gerade XS-Pakete mit der engen Verknüpfung zum OS könnten m.M. nach unterschiedliche Verhaltensweisen verursachen.
Insbesondere wenn sie nicht aktuell sind und vllt. Leakprobleme haben die in neueren Versionen behoben wurden.
Deswegen wäre ein Punkt mit dem Installer (get showModuleInfo) zu prüfen, ob neuere Versionen der geladenen Pakete verfügbar sind und sie zu aktualisieren.
LG,
Heiko
@Nobbynews,
hast du PadWalker aktiviert? (Attr deepScan=1)
Wenn ja, schau dir mal die Ausgaben von "get ... report <Snapshot>" an.
Dort sind dann die internen Modulvariablen sichtbar. Damit habe ich soeben ein stark wachsendes Array in einem meiner eigenen Module erkannt. Leicht mit minimalen Aufwand zu lösen wenn man diesen Lunker erstmal entdeckt hat.
Auch ein "get ... diff [ <Label1> [<Label2>] zeigt das Wachstum:
File-scope variables of module files (PadWalker) - growth (top 15):
+2.65 MB 76_SolarForecast.pm @widgetreadings (50.96 MB -> 53.61 MB)
+31.7 kB 98_SVG.pm $SVG_RET (47.1 kB -> 78.8 kB)
+17.1 kB AttrTemplate.pm %cachedUsage (130.8 kB -> 148.0 kB)
+2.0 kB 76_SolarForecast.pm %MCache_Stats (300.0 kB -> 302.0 kB)
LG,
Heiko
Zitat von: JoWiemann am 09 November 2026, 20:18:44Für mich wäre List vom Device FritzOG interessant, sofern es nicht ein FBDect Device ist.
Das ist ein 2400er Repeater.
Allerdings ist das list so groß, dass es nur als Anhang geht.
Auffallend sind die Unmengen an Einträgen landeviceXYXYXY...
Norbert
Zitat von: DS_Starter am 09 November 2026, 22:59:17hast du PadWalker aktiviert? (Attr deepScan=1)
Ja.
Die Ausgabe von report als Screenshots.
Norbert
Moin Norbert,
In den "Largest file-scope variables" ist mit 13.x MB FHEMWEB %FW_svgData beteiligt.
Das würde den RSS Anstieg aus deinem Anfangsbeitrag erklären wenn du bei dir SVG's aufgerufen hast.
Interessant wäre natürlich, ob dieser Wert zwischen den Snaps schwankt, also aufgebaut und wieder abgebaut wird, oder ob der Wert permanent steigt.
Bei mir ist FHEMWEB unauffällig obwohl ich auch viele SVG's aufrufe:
Largest file-scope variables (top 15):
1.27 MB AttrTemplate.pm %templates
951.5 kB 10_CUL_HM.pm $culHmRegDefine
610.9 kB 01_FHEMWEB.pm %FW_icons
448.1 kB 10_ZWave.pm %zwave_img
410.9 kB 10_ZWave.pm %zwave_link
316.2 kB 01_FHEMWEB.pm %FW_rooms
284.6 kB 76_SolarForecast.pm %MCache_Stats
263.5 kB 76_SolarForecast.pm %hfspvh
242.7 kB 10_CUL_HM.pm $culHmModel
211.6 kB 01_FHEMWEB.pm %FW_types
193.1 kB Unit.pm $rtypes
130.7 kB AttrTemplate.pm %cachedUsage
127.4 kB 10_ZWave.pm %zwave_class
113.7 kB 76_SolarForecast.pm %weather_ids
111.1 kB 10_CUL_HM.pm $culHmRegChan
Diese Variable ist es m.M. nach Wert mal weiter betrachtet zu werden wie sie sich über die Zeit verhält.
LG,
Heiko
Zitat von: DS_Starter am 10 November 2026, 09:12:32In den "Largest file-scope variables" ist mit 13.x MB FHEMWEB %FW_svgData beteiligt.
War mir auch aufgefallen, habe aber natürlich auch keine Erklärung dafür.
Die SVGs zum Thema Speicher habe ich mal in einen separaten Raum ausgelagert, um beim Abrufen der Daten da nichts neues zu generieren.
Edit:
Im WEB-Device hatte ich plotfork = 1 gesetzt.
Das habe ich jetzt mal zum Testen auf den Standard plotfork = 0 gesetzt und fhem neu gestartet.
Norbert
Hallo Heiko,
nach einem shutdown restart werden keine alten Snapshots mehr angezeigt.
Das reading snapshots wird zurückgesetzt.
Ist das so gewollt?
Snapshots werden nicht persistiert, also auf der Platte gespeichert.
Steht (ein bisschen versteckt) in der Hilfe unter "Define":
ZitatDie Snapshots liegen im Speicher von FHEM und gehen bei einem Neustart von FHEM verloren.
Zitat von: DS_Starter am 10 November 2026, 13:21:57Snapshots werden nicht persistiert,
Habe ich natürlich nicht gelesen.
Danke für den Hinweis.
Ich habe eine weiterentwickelte Version 0.7.0 eingecheckt. Wer möchte kann sie vorab aus meinem contrib laden.
Es gibt ein neues Attribut trackObjects um eine Liste von verdächtigen Variablen oder Strukturen über eine längere Zeit dediziert beobachten und auswerten zu können.
Es gibt noch ein paar mehr kleinere Dinge, hier das Changelog der V:
11.11.2026 Rev. 31890
- **Neu:**
* Readings, die von einem Snapshot oder der periodischen Messung abhängen, werden nach einem
Neustart von FHEM zurückgesetzt. Das Statefile wird erst nach dem Define eingelesen und stellte
bisher veraltete Werte wieder her (z.B. proc_pss_kB, snapshots, snapshot_last,
proc_rssTrend_kBperHour). Die Bereinigung erfolgt einmalig pro Start im startTimers, danach werden
nur state, crashListCount, snapshots und snapshot_last neu gesetzt.
* Tracking einzelner Variablen/Strukturen über einen längeren Zeitraum.
Attribut trackObjects: Liste von Objekten (Leerzeichen oder Komma getrennt), z.B.
$defs{VictronVRM}{.pvHistCache} -> Hash/Array der FHEM-Hauptebene (Syntax wie xHashDetail)
%FHEM::Modul::cache -> Paketvariable (auch @ und $)
93_DbLog.pm:%cache -> file-scope 'my' Variable (PadWalker)
Größe (Bytes) und Anzahl der Einträge werden mit jedem Snapshot (manuell und autoSnapshot)
aufgezeichnet. Jedes Objekt wird mit eigenem Messkontext gemessen (Größe unabhängig von der
Reihenfolge) und geht nicht in "attributed" ein. deepScan ist nicht erforderlich, bei
file-scope Variablen wird nur die genannte Datei durchsucht.
Attribut trackMaxSamples (default 500): Anzahl der gehaltenen Messwerte je Objekt (Ringpuffer, nur im Speicher).
Neuer Get "track": Übersicht bzw. Verlauf je Objekt mit Differenz und Änderung pro Stunde.
Neue Readings track_<Objekt>_bytes und track_<Objekt>_count (loggbar/plotbar).
Neue Kategorien track/trackn in "get diff", "get leakCandidates" und im Snapshot-Bericht;
nicht auffindbare Objekte werden im Snapshot-Bericht gemeldet. Der Ringpuffer ist von der
Eigenmessung des Moduls ausgenommen.
* Get track: Objekte werden über ihren Pfad aus einer Auswahlliste gewählt
(widgetList: select + Textfeld für die Zeilenzahl, Doppelpunkte als "/" dargestellt, die
Originalschreibweise wird weiter akzeptiert). Spalte "#" in der Übersicht entfernt.
* Erläuternde Texte und Hinweise (Interpretation, Hints, Crash-Meldungen, Fehlermeldungen)
werden entsprechend dem globalen Attribut language ausgegeben (DE deutsch, sonst englisch),
umgesetzt über die Texttabelle %TXT und die Funktion _t(). Tabellenköpfe, Kategorietitel und
Readingnamen bleiben englisch.
- **Fix:**
* _resolvePath in _resolvePath und _descend aufgeteilt (Basis für das Tracking), im Text von
"get leakCandidates" wurde vor $defs ein Backslash angezeigt.
BTW:
Gestern hatte ich mit Hilfe von Analyze in einem meiner eigenen Module ein stark wachsendes Array identifiziert. Diese Situation kam nur in einer ganz bestimmten Situation zustande. Hier konkret bei Verwendung des Attributs graphicHeaderOwnspec in SolarForecast, und auch nur dann wenn der Nutzer Objekte anderer Devices in SF zur Anzeige implementiert hat.
Also eine sehr spezielle Situation, die nicht bei jedem User des Moduls zum Tragen kommt. Das nur als Beispiel wie unterschiedlich sich die Dinge beim Anwender entwickeln können.
Seit der Lösung, die ich nach der Analyse/Erkenntnis leicht einbauen konnte, sieht der RAM-Verlauf wieder sehr stabil aus (Anhang). Der Patch ist inzwischen eingecheckt.
VG,
Heiko
Hallo Heiko,
wie spielt Analyze und MemSaver zusammen?
Muss MemSaver deaktiviert werden, um mit Analyze "richtig" auswerten zu können oder wird der freigegebene Speicher von Analyze berücksichtigt?
Grüße
Bernd
Hallo Bernd,
die beiden Module haben unterschiedliche Aufgaben. MemSaver gibt freie! Perl-Speicherbereiche an das OS zurück. Perl macht das nicht per default. Was es einmal allokiert hat, bleibt allokiert solange der Perl-Prozess lebt.
MemSaver tut dies, aber nur freie Bereiche. Wenn Perl sie noch nutzt, d.h. die Strukturen haben noch Referenzen oder Inhalte, kann MemSaver sie nicht zurückgeben.
Um diese (vllt. wachsenden) Strukturen zu finden und bei der Beseitigung zu helfen (meist der Programmierer oder Maintainer), dient Analyze.
Das betrifft natürlich auch eigenen Code in MyUtils.
Im Klartext, MemSaver laufen lassen und freien Speicher an das OS zurückgeben lassen.
Analyze kümmert sich um die Aufnahme und das Reporting der Größe von vorhandenen Objekten.
LG,
Heiko
Danke Heiko, für die ausführliche Erklärung.
Jetzt ist mir einiges klarer :)
Zitat von: DS_Starter am 10 November 2026, 09:12:32In den "Largest file-scope variables" ist mit 13.x MB FHEMWEB %FW_svgData beteiligt.
Das würde den RSS Anstieg aus deinem Anfangsbeitrag erklären wenn du bei dir SVG's aufgerufen hast.
Nach Umstellung auf plotfork=0 hat sich FHEMWEB wieder eingefangen.
Scheint also, dass plotfork=1 da ein Problem hat.
Norbert
Hallo Jörg,
Zitat von: JoWiemann am 09 November 2026, 20:18:44als Maintainer des Moduls 72_FritzSmart habe ich 8 Devices mit unterschiedlichen Fritz Geräten in meiner Installation laufen. Ich kann keinerlei Speicher "Verbrauch" feststellen.
hier noch mal ein Screenshot zum Speicherverbrauch.
Das List von FritzOG weist halt wieder Unmengen Einträge für landeviceXYXYXY auf.
Norbert
Hallo Norbert,
ZitatNach Umstellung auf plotfork=0 hat sich FHEMWEB wieder eingefangen.
Scheint also, dass plotfork=1 da ein Problem hat.
Wenn sich das Speicherwachstum mit plotfork=1 wieder reproduzieren lässt, wäre es eine Bestätigung und Rudolph könnte sich was dann mal zielgerichtet ansehen.
Zitat von: Nobbynews am 11 November 2026, 14:19:48Das List von FritzOG weist halt wieder Unmengen Einträge für landeviceXYXYXY auf.
Hallo Norbert,
der Hash der landevices ist ziemlich groß. Das schaue ich mir mal an. Ich selber habe das Problem nicht.
Grüße Jörg
Hallo Heiko,
Zitat von: DS_Starter am 11 November 2026, 14:36:56ZitatNach Umstellung auf plotfork=0 hat sich FHEMWEB wieder eingefangen.
Scheint also, dass plotfork=1 da ein Problem hat.
Wenn sich das Speicherwachstum mit plotfork=1 wieder reproduzieren lässt, wäre es eine Bestätigung und Rudolph könnte sich was dann mal zielgerichtet ansehen.
Hier mal die Auswertung vor und nach der Umstellung wieder auf plotfork=1.
Das Ergebnis ist eindeutig.
Speicherverbrauch ist auf über 4MB angewachsen.
Norbert
Hallo Norbert,
das Verhalten ist ungewöhnlich.
landevice203597 PC-00-11-05-FD-40-BA
landevice203626 PC-00-11-05-FD-40-BA
landevice203650 PC-00-11-05-FD-40-BA
landevice203674 PC-00-11-05-FD-40-BA
landevice203694 PC-00-11-05-FD-40-BA
landevice203726 PC-00-11-05-FD-40-BA
landevice203814 PC-00-11-05-FD-40-BA
landevice203864 PC-00-11-05-FD-40-BA
landevice203894 PC-00-11-05-FD-40-BA
landevice203941 PC-00-11-05-FD-40-BA
landevice203977 PC-00-11-05-FD-40-BA
landevice204011 PC-00-11-05-FD-40-BA
landevice204035 PC-00-11-05-FD-40-BA
landevice204055 PC-00-11-05-FD-40-BA
landevice204081 PC-00-11-05-FD-40-BA
landevice204103 PC-00-11-05-FD-40-BA
landevice204125 PC-00-11-05-FD-40-BA
landevice204148 PC-00-11-05-FD-40-BA
landevice204171 PC-00-11-05-FD-40-BA
landevice204196 PC-00-11-05-FD-40-BA
landevice204238 PC-00-11-05-FD-40-BA
landevice204264 PC-00-11-05-FD-40-BA
landevice204348 PC-00-11-05-FD-40-BA
landevice204371 PC-00-11-05-FD-40-BA
landevice204392 PC-00-11-05-FD-40-BA
landevice204425 PC-00-11-05-FD-40-BA
landevice204448 PC-00-11-05-FD-40-BA
landevice204469 PC-00-11-05-FD-40-BA
landevice204505 PC-00-11-05-FD-40-BA
landevice204541 PC-00-11-05-FD-40-BA
landevice204566 PC-00-11-05-FD-40-BA
landevice204607 PC-00-11-05-FD-40-BA
landevice204665 PC-00-11-05-FD-40-BA
landevice204710 PC-00-11-05-FD-40-BA
landevice204785 PC-00-11-05-FD-40-BA
landevice204815 PC-00-11-05-FD-40-BA
landevice204875 PC-00-11-05-FD-40-BA
landevice204902 PC-00-11-05-FD-40-BA
landevice204959 PC-00-11-05-FD-40-BA
landevice205002 PC-00-11-05-FD-40-BA
landevice205021 PC-00-11-05-FD-40-BA
landevice205065 PC-00-11-05-FD-40-BA
landevice205093 PC-00-11-05-FD-40-BA
landevice205151 PC-00-11-05-FD-40-BA
landevice205257 PC-00-11-05-FD-40-BA
landevice205271 PC-00-11-05-FD-40-BA
landevice205306 PC-00-11-05-FD-40-BA
landevice205477 PC-00-11-05-FD-40-BA
landevice205491 PC-00-11-05-FD-40-BA
landevice205508 PC-00-11-05-FD-40-BA
landevice205539 PC-00-11-05-FD-40-BA
landevice205569 PC-00-11-05-FD-40-BA
landevice205608 PC-00-11-05-FD-40-BA
landevice205639 PC-00-11-05-FD-40-BA
landevice205684 PC-00-11-05-FD-40-BA
landevice205727 PC-00-11-05-FD-40-BA
landevice205740 PC-00-11-05-FD-40-BA
landevice205812 PC-00-11-05-FD-40-BA
landevice205854 PC-00-11-05-FD-40-BA
landevice205890 PC-00-11-05-FD-40-BA
landevice205917 PC-00-11-05-FD-40-BA
landevice205962 PC-00-11-05-FD-40-BA
landevice206073 PC-00-11-05-FD-40-BA
landevice206101 PC-00-11-05-FD-40-BA
landevice206131 PC-00-11-05-FD-40-BA
landevice206163 PC-00-11-05-FD-40-BA
landevice206191 PC-00-11-05-FD-40-BA
landevice206233 PC-00-11-05-FD-40-BA
landevice206272 PC-00-11-05-FD-40-BA
landevice206303 PC-00-11-05-FD-40-BA
landevice206340 PC-00-11-05-FD-40-BA
landevice206371 PC-00-11-05-FD-40-BA
landevice206442 PC-00-11-05-FD-40-BA
landevice206493 PC-00-11-05-FD-40-BA
landevice206519 PC-00-11-05-FD-40-BA
landevice206559 PC-00-11-05-FD-40-BA
landevice206601 PC-00-11-05-FD-40-BA
landevice206641 PC-00-11-05-FD-40-BA
landevice206667 PC-00-11-05-FD-40-BA
landevice206685 PC-00-11-05-FD-40-BA
landevice206723 PC-00-11-05-FD-40-BA
landevice206753 PC-00-11-05-FD-40-BA
landevice206761 PC-00-11-05-FD-40-BA
landevice206777 PC-00-11-05-FD-40-BA
landevice206815 PC-00-11-05-FD-40-BA
landevice206880 PC-00-11-05-FD-40-BA
landevice206898 PC-00-11-05-FD-40-BA
landevice206927 PC-00-11-05-FD-40-BA
landevice206952 PC-00-11-05-FD-40-BA
landevice206987 PC-00-11-05-FD-40-BA
landevice207051 PC-00-11-05-FD-40-BA
landevice207078 PC-00-11-05-FD-40-BA
landevice207119 PC-00-11-05-FD-40-BA
landevice207174 PC-00-11-05-FD-40-BA
landevice207183 PC-00-11-05-FD-40-BA
landevice207206 PC-00-11-05-FD-40-BA
landevice207245 PC-00-11-05-FD-40-BA
landevice207254 PC-00-11-05-FD-40-BA
landevice207290 PC-00-11-05-FD-40-BA
landevice207299 PC-00-11-05-FD-40-BA
landevice207316 PC-00-11-05-FD-40-BA
landevice207339 PC-00-11-05-FD-40-BA
landevice207366 PC-00-11-05-FD-40-BA
landevice207404 PC-00-11-05-FD-40-BA
landevice207437 PC-00-11-05-FD-40-BA
landevice207458 PC-00-11-05-FD-40-BA
Hier nur ein Beispiel. Für die selbe MAC vergibt das Fritz Gerät immer wieder ein neues internes landevice mit einer neuen Nummer. Dadurch wächst der Hash kontinuierlich, was natürlich Speicher "frist". Dieses Verhalten habe ich noch nie beobachten können. Wie sieht den Deine Fritz Infrastruktur aus?
Grüße Jörg
Hallo Jörg,
Zitat von: JoWiemann am 11 November 2026, 16:50:50Wie sieht den Deine Fritz Infrastruktur aus?
Zentrale ist eine 7590 mit FritzOS 8.21.
der 2400er Repeater ist über Kabel als Acesspoint angeschlossen. Fritz OS ist 8.25.
Dazwischen hängt natürlich noch ein Switch. Dürfte aber nicht ausschlaggebend sein?
Norbert
Zitat von: Nobbynews am 11 November 2026, 17:34:26Zentrale ist eine 7590 mit FritzOS 8.21.
der 2400er Repeater ist über Kabel als Acesspoint angeschlossen. Fritz OS ist 8.25.
Dazwischen hängt natürlich noch ein Switch. Dürfte aber nicht ausschlaggebend sein?
Spannend.
Anbei eine Version des FritzSmat Moduls zum Testen. Ich bereinige hier vorsichtshalber den Hash. Bitte einmal einspielen und Fhem neu starten.
Du kannst dann ja mal über get <name> list Dir immer wieder mal den Hash landevice ansehen. Vlt. hilft das ja.
Grüße Jörg
Guten Morgen Jörg,
Zitat von: JoWiemann am 11 November 2026, 17:59:44Anbei eine Version des FritzSmat Moduls zum Testen. Ich bereinige hier vorsichtshalber den Hash. Bitte einmal einspielen und Fhem neu starten.
das sieht gut aus.
FritzSmart wird nicht mehr als potentielles leak erkannt (siehe Screenshot).
Norbert
Guten Morgen Heiko,
Zitat von: DS_Starter am 11 November 2026, 14:36:56Wenn sich das Speicherwachstum mit plotfork=1 wieder reproduzieren lässt, wäre es eine Bestätigung und Rudolph könnte sich was dann mal zielgerichtet ansehen.
hier mal das Ergebnis seit dem Neustart gestern Abend für den Test von FritzSmart.
FHEMWEB bläht sich bei plotfork=1 ganz schön auf (siehe Screenshot).
6.41 MB 01_FHEMWEB.pm %FW_svgDataVielleicht kann das mal jemand verifizieren.
Norbert
Zitat von: Nobbynews am 12 November 2026, 06:12:33das sieht gut aus.
FritzSmart wird nicht mehr als potentielles leak erkannt (siehe Screenshot).
Norbert
Hallo Norbert,
vielen Dank für die Rückmeldung. Dann werde ich die Version einchecken. Trotzdem bleibt die Frage nach der immer wieder stattfindenden Neuvergabe der internen landevice ID in der Fritzbox. Ich habe zwar bei den set/get Befehlen schon vor langer Zeit die Möglichkeit geschaffen neben der Device ID auch die MAC anzugeben, allerdings kann das ggf. zu Problemen führen, wenn sich die Device ID ständig ändert und jemand basierend auf der ID eine Automation hinterlegt hat.
Grüße Jörg
Zitat von: Nobbynews am 12 November 2026, 06:16:07Guten Morgen Heiko,
hier mal das Ergebnis seit dem Neustart gestern Abend für den Test von FritzSmart.
FHEMWEB bläht sich bei plotfork=1 ganz schön auf (siehe Screenshot).
6.41 MB 01_FHEMWEB.pm %FW_svgDataVielleicht kann das mal jemand verifizieren.
Norbert
Hallo Norbert,
in der commandRef steht: Achtung: nicht auf Systemen mit wenig Hauptspeicher verwenden. Beobachtest Du ein ständiges Wachstum oder nur einen einmaligen Anstieg?
Grüße Jörg
Hallo Jörg,
das ist ein Pi4 mit 8 GB.
Sollte doch reichen?
Speicherverbrauch wächst kontinuierlich.
Norbert
Morjen,
ich mische mich mal ein.
Ich habe auch plotfork=1, immer auf 2 PCs zig(ca. 15) FHEMWeb-Sessions in MS Edge geöffnet. Weil ich mit PI5/1MB auch "seltsame" Neustarts" nach jeweils gut einer Woche hatte, habe ich eine Aufzeichnung des Speichers über SYSMON. Ich kann grundsätzlich keinen Speicherzuwachs feststellen. Zwischenzeitlich habe ich auch Analyze installiert, bin aber noch nicht tief genug im Verständnis der zahlreichen Funktionen. Das soweit, um evtl. eine ähnliche Konfig. wie bei Norbert zu vergleichen.
Zu meinem Problem: Ich hatte Komplettabstürze des RPi und haderte natürlich damit, dass die Systemlogs standardmäßig nicht persistent sind. :'( Also habe ich nach den ersten Abstürzen erst einmal dort mein Heil probiert und wartete auf den nächsten Absturz. Der kam aber nicht auf Systemebene, sondern überraschend nur bei FHEM. Es war der oom-Killer, der erst einen Systemprozess, dann einen geforkten FHEM-Prozess u. schließlich den FHEM-Hauptprozess gekillt hatte. Ich konnte dann schön erkennen, dass die Problematik über 10 geforkte FHEM-Prozesse entstanden ist.
Ich weiß, dass diese "plötzlichen Restarts" auftreten, wenn ich intensiv meine FHEM-Sessions nutze und mir immer wieder einige aktualisierte SVGs anzeigen lasse. Ich spekuliere, dass das die geforkten -FHEMWEB-Prozesse sind, die durch irgendwas(WLAN-Probleme ?) blockiert werden bis dann mein Speicher zu Ende ist.
Als Erste-Hilfe-Maßnahme habe ich nun erst einmal Global blockingCallMax auf 10 gesetzt. Obs was bringt ?
@Heiko: Irre was Du da wieder geschaffen hast und Danke für Deine Zeit.
Frage des eher System-Laien: Zu den forks sehe ich nichts im Analyze-device bzw. nur im Augenblick des Snapshots Anzahl aktiver kind-Prozesse ?
Grüße Markus
ZitatAls Erste-Hilfe-Maßnahme habe ich nun erst einmal Global blockingCallMax auf 10 gesetzt. Obs was bringt ?
Das könnte was bringen weil die gleichzeitige Anzahl
forks BlockingCalls begrenzt wird. (nicht jeder fork wird durch BlockingCall realisiert) Ich würde sie sogar noch halbieren.
ABER, wenn es um die Anzeige von SVG's geht UND du evtl. DbLog im Einsatz hast, kannst du seit ein paar Wochen gänzlich ohne forks arbeiten. Sieht dir dazu die Attr plotCacheLifetime, plotCacheKeepalive im DbLog an und setze dann in allen FHEMWEB Devices plotfork=0. Dann bist du das Problem an der Stelle los.
ZitatZu den forks sehe ich nichts im Analyze-device bzw. nur im Augenblick des Snapshots Anzahl aktiver kind-Prozesse ?
Ja, das ist richtig. Der Hauptprozess wird zu dem Zeitpunkt analysiert, wobei dieser Vorgang selbst in einem fork per default stattfindet. Im Analyze kann man den eigenen fork mit useFork=0 unterbinden wobei man dann evtl. einen FHEM Stillstand von X Sekunden im System hat. Das will man natürlich nicht, aber im Extremfall kann man das mal so machen.
Zitathier mal das Ergebnis seit dem Neustart gestern Abend für den Test von FritzSmart.
FHEMWEB bläht sich bei plotfork=1 ganz schön auf (siehe Screenshot).
Code Auswählen
6.41 MB 01_FHEMWEB.pm %FW_svgData
Vielleicht kann das mal jemand verifizieren.
Ich versuche es bei mir heute Abend mal nachzustellen und das Ergebnis zu prüfen. Vllt. kann ich auch einen Patch vorschlagen, mal sehen.
Rudi als FHEMWEB Entwickler kann sich das natürlich auch schon mal ansehen. Vermutlich weiß er sofort wo er suchen muß. Das Objekt ist ja mit %FW_svgData schon klar geworden.
ZitatFHEMWEB bläht sich bei plotfork=1 ganz schön auf (siehe Screenshot).
FW_svgData sollte nur waehrend der Berechnung der SVGs Daten enthalten.
Wenn das nicht der Fall sein sollte, dann brauche ich was zum Nachstellen.
Relevant ist FW_svgData wenn plotfork=1 und plotEmbed=0 ist.
Bei Mehrprozessor-Linux Rechner ist die Voreinstellung plotfork=1 und plotEmbed=2.
plotfork=1 erlaubt das Forken (d.h. duplizieren des FHEM Prozesses).
Das kann ein Problem sein, wenn FHEM gross und der Speicher knapp ist.
plotEmbed:
- falls 0, dann werden die Daten in FHEMWEB zusammengestellt, und alles auf einmal zurueckgeliefert. Je nach plotFork wird BlockingCall fuer die Berechnung verwendet.
- falls 1, dann werden die Daten per "embed" HTML Direktive geholt (veraltet)
- falls 2, dann werden die Daten per JS geholt.
plotEmbed 1 oder 2 bedeutet bis zu 5 paralelle Anfragen an FHEMWEB je Browser, d.h je nach plotfork 5 weitere FHEM Prozesse.
Diese werden per fhemFork (nicht BlockingCall) erledigt, und das hat kein Parameter fuer die Begrenzung.
Bin heute und morgen unterwegs, daher nur kurz.
plotEmbed=2 ist gesetzt und wurde nicht geändert.
Norbert
ZitatABER, wenn es um die Anzeige von SVG's geht UND du evtl. DbLog im Einsatz hast,
Nein, habe ich nicht.
ZitatIm Analyze kann man den eigenen fork mit useFork=0 unterbinden wobei man dann evtl. einen FHEM Stillstand von X Sekunden im System hat. Das will man natürlich nicht, aber im Extremfall kann man das mal so machen.
Guter Hinweis. Setze ich. Denn beim letzten mal hantierte ich tatsächlich mit Analyze und Installer. Über den Systemfreeze alle autoSnapshot = 6 Stunden wird mich freezemon über X aufklären und das Ergebnis werde ich in diesem Post per Edit veröffentlichen.
Edit: X=0,6s
Hallo Rudi,
ich konnte durch Tracken des Objekts %FW_svgData die Beobachtung von Nobbynews bestätigen.
Mit dem aktuellen FHEMWEB mit plotfork=1, plotembed=2 habe ich mehrere Snapshots angefertigt und zwischen den Snaps ca. 20mal eine Seite mit etlichen SVG's aufgerufen.
Im Ergebnis wächst %FW_svgData stetig:
Tracked object 01_FHEMWEB.pm:%FW_svgData
time size entries delta size per hour
2026-11-12 20:22:23 4.13 MB 47 - -
2026-11-12 20:23:28 5.45 MB 62 +1.32 MB +72.96 MB/h
2026-11-12 20:25:14 7.64 MB 87 +2.20 MB +74.59 MB/h
Netto-Änderung über 0.0 h: +3.51 MB (+73.97 MB/h), Einträge +40 (+842.1/h)
Mit einem einfachen Patch konnte das Thema beseitigt werden. Es ist nur eine Zeile "delete $FW_svgData{$name};" in der Sub FW_Read:
--- a/01_FHEMWEB.pm
+++ b/01_FHEMWEB.pm
@@ -601,6 +601,7 @@
setpriority(PRIO_PROCESS, $pid, getpriority(PRIO_PROCESS,$pid) + $pf)
if($^O !~ m/Win/);
TcpServer_Disown( $hash );
+ delete $FW_svgData{$name}; # NEU -> FW_Undef is not called here, so clean up
delete($defs{$name});
delete($attr{$name});
FW_Read($hash, 1) if($hash->{BUF});
Mit diesem Patch ist die Struktur in jedem Snapshot leer:
size entries change per hour samples object
176 B 0 -4.13 MB -15.48 MB/h 5 01_FHEMWEB.pm:%FW_svgData
Hinweis: die Werte werden mit jedem Snapshot erfasst (auch automatischen). Details: get analyzeData track <Objekt>
Grundlage für den Patch war folgende KI-Analyse des Problems:
Problem: %FW_svgData wächst bei aktivem Forking (plotfork=1, oder plotEmbed=2 ohne gesetztes plotfork) und SVG-Plots ohne Obergrenze.
Ursache:
1. FW_showRoom legt bei jedem Raumaufruf $FW_svgData{<Verbindungsname>} an. Der Eintrag enthält u. a. das bis dahin gerenderte Seiten-HTML (FW_RET).
2. Bei plotEmbed=2 (und 1) holt der Browser jeden SVG-Plot über einen eigenen Request /SVG_showLog. Dieser Request ist FORKABLE und läuft häufig über dieselbe Keep-Alive-Verbindung wie die Raumseite.
3. In FW_Read forkt der Parent dann, übergibt den Request an das Kind und entfernt die Verbindung per TcpServer_Disown und delete($defs{$name}) aus %defs.
4. Dabei wird FW_Undef nicht aufgerufen, und nur dort (sowie in FW_svgCollect und FW_closeConn) wurde der Eintrag bisher gelöscht. Der Eintrag bleibt im Parent verwaist zurück.
LG,
Heiko
@Markus,
ich habe gerade gelesen, dass du freezemon einsetzt.
Wir hatten unlängst mal ein Thema mit freezemon, das Modul hatte selbst Speicherprobleme verursacht.
Meine aber auch Rudolf hatte einen Patch in freezemon eingebaut und eingecheckt.
Wenn du es mitlaufen lässt, dann sollte es unbedingt ein aktuelles Release sein.
LG,
Heiko
ZitatMit einem einfachen Patch konnte das Thema beseitigt werden. Es ist nur eine Zeile "delete $FW_svgData{$name};" in der Sub FW_Read:
Kannst Du bitte pruefen, ob das Problem mit aendern der Zeile 2213 nach
my $svgDataUsed = 0;auch behoben ist?
Die von der KI vorgeschlagene Loesung finde ich nicht intuitiv, FW_svgData sollte nicht erst da entfernt werden.
Ich konnte das Problem bei mir nicht nachstellen: welchen Browser/OS habt ihr verwendet?
Ich habe "delete $FW_svgData{$name};" wieder entfernt und
my $svgDataUsed = 0;
eingebaut.
Das Ergebnis sieht ebenfalls sehr gut aus:
Tracked object 01_FHEMWEB.pm:%FW_svgData
time size entries delta size per hour
2026-11-12 20:22:23 4.13 MB 47 - -
2026-11-12 20:23:28 5.45 MB 62 +1.32 MB +72.96 MB/h
2026-11-12 20:25:14 7.64 MB 87 +2.20 MB +74.59 MB/h
2026-11-12 20:34:55 176 B 0 -7.64 MB -47.35 MB/h
2026-11-12 20:38:23 176 B 0 0 B 0 B/h
2026-11-12 21:07:13 176 B 0 0 B 0 B/h
2026-11-12 22:06:22 176 B 0 0 B 0 B/h
2026-11-12 22:07:13 176 B 0 0 B 0 B/h
2026-11-12 22:07:41 176 B 0 0 B 0 B/h
2026-11-12 22:08:40 176 B 0 0 B 0 B/h
2026-11-12 22:10:34 176 B 0 0 B 0 B/h
Netto-Änderung über 1.8 h: -4.13 MB (-2.29 MB/h), Einträge -47 (-26.1/h)
Deutlich zu sehen die Unterschiede zu den Tests 20:2x.
Mein FHEM läuft auf Debian GNU/Linux 12 (bookworm).
Browser ist Firefox (Win) 160.0 (64-Bit)
ZitatWir hatten unlängst mal ein Thema mit freezemon, das Modul hatte selbst Speicherprobleme verursacht.
Meine aber auch Rudolf hatte einen Patch in freezemon eingebaut und eingecheckt.
Wenn du es mitlaufen lässt, dann sollte es unbedingt ein aktuelles Release sein.
Ich hatte die Diskussion verfolgt. Problem war aber doch, dass disable = 1 gesetzt war. Und sogar nur entstand, weil es im laufenden Betrieb gesetzt wurde und nicht bereits beim Start. Und gerade dachte ich, bald kommt der nächste snapshot. Blöd von mir. Geht ja auch manuell....
2026.11.12 23:02:36 3: [Freezemon] freezedetect: possible freeze starting at 23:02:36, delay is 0.675 possiblealso X < 1
0,3s davon fürs Auslesen ?
Snapshot 'snap_20261112_230246' from 2026-11-12 23:02:46 (10662 objects walked in 0.3 s)
Naja, kommt auf die Anzahl der Objekte und die Leistungsfähigkeit deines Systems an.
Wenn das so läuft ... perfekt. :)
Zum Vergleich mein letzter Scan:
ZitatSnapshot 'auto_20261112_224934' from 2026-11-12 22:49:34 (1172112 objects walked in 22.3 s, deepScan)
AMD Prozessor 4 Cores.
Auweiah, und ich dachte 5-stellig wäre viel... lol
Das ist mein Produktivsystem. Gibt noch zwei kleinere.