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

[DS_Starter]

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:

Code Auswählen Erweitern

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

[frober]

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

[DS_Starter]

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

[frober]

Danke Heiko, für die ausführliche Erklärung.
Jetzt ist mir einiges klarer 

[Nobbynews]

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.

Nach Umstellung auf plotfork=0 hat sich FHEMWEB wieder eingefangen.
Scheint also, dass plotfork=1 da ein Problem hat.

Norbert

[Nobbynews]

Hallo Jörg,

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.

hier noch mal ein Screenshot zum Speicherverbrauch.
Das List von FritzOG weist halt wieder Unmengen Einträge für landeviceXYXYXY auf.

Norbert

[DS_Starter]

Hallo Norbert,

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

[JoWiemann]

Das 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

[Nobbynews]

Hallo Heiko,

Nach 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

[JoWiemann]

Hallo Norbert,

das Verhalten ist ungewöhnlich.

Code Auswählen Erweitern

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