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