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