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

[DS_Starter]

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