98_Analyze - Modul zur Systemanalyse (RAM-Verbrauch, Leaks, und mehr)

[JoWiemann]

Guten 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).

Code Auswählen Erweitern

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

[Nobbynews]

Hallo Jörg,

das ist ein Pi4 mit 8 GB.
Sollte doch reichen?
Speicherverbrauch wächst kontinuierlich.

Norbert

[KölnSolar]

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 

[DS_Starter]

Als 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.

Zu 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.

[DS_Starter]

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).
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.

[rudolfkoenig]

FHEMWEB 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.

[Nobbynews]

Bin heute und morgen unterwegs, daher nur kurz.

plotEmbed=2 ist gesetzt und wurde nicht geändert.

Norbert

[KölnSolar]

ABER, wenn es um die Anzeige von SVG's geht UND du evtl. DbLog im Einsatz hast,

Nein, habe ich nicht.

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.

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

[DS_Starter]

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

--- 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:

Code Auswählen Erweitern

        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

[DS_Starter]

@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

[rudolfkoenig]

Mit 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

Code Auswählen Erweitern

  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?

[DS_Starter]

Ich habe "delete $FW_svgData{$name};" wieder entfernt und

Code Auswählen Erweitern

my $svgDataUsed = 0;

eingebaut.
Das Ergebnis sieht ebenfalls sehr gut aus:

Code Auswählen Erweitern

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)

[KölnSolar]

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.

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....

Code Auswählen Erweitern

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 ?

Code Auswählen Erweitern

Snapshot 'snap_20261112_230246' from 2026-11-12 23:02:46  (10662 objects walked in 0.3 s)

[DS_Starter]

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:

Snapshot 'auto_20261112_224934' from 2026-11-12 22:49:34  (1172112 objects walked in 22.3 s, deepScan)

AMD Prozessor 4 Cores.