FHEM wird über Wochen langsamer: welches Modul benötigt mehr CPU? sysmon/perform

[Raven]

1)   Welches Modul verursacht höhere CPU-Laufzeiten bei längerer FHEM Uptime?
Ich habe perform im Einsatz und nach 2 – 3 Wochen (evtl. auch mehr) bekomme ich regelmäßig den LOG-Hinweis vom Perform Modul "possible freeze...."; die Delays bewegen zwischen >1 und 3sec.
Nach einem Neustart von FHEM verschwinden diese Log-Eintrage wieder; sieht man auch an dem Sysmon-Chart.
M.E. hilft mir das perform Modul hier nur nicht weiter, denn ich wüßte nicht, wie ich erkennen soll welches Modul im Laufe der Zeit eine höhere CPU Zeit beansprucht.

Wie kann ich also herausfinden, welches Modul (hourcounter, VCONTROL, statistics, PROPLANTA usw.) über einen längeren Zeit mehr CPU beansprucht?

2) Wie ein Alerting aufsetzen?
Ich habe schon bereits unter Monitoring und Threshold gesucht, ich bin aber noch nicht fündig geworden.
Wie könnte ich bitte diese langsam ansteigende (avg) User-Last tracken (vorzugsweise mit DOIF)?, um eine entsprechende Benachrichtigung abzusetzen.



Danke vorab.

[isy]

Moin,
Hast du apptime schon mal probiert?
Gruß Helmut

[herrmannj]

M.E. hilft mir das perform Modul hier nur nicht weiter

richtig, perfmon zeigt "das" was schiefgeht. Nicht "was"

"Interessant" ist die langsame und kontinuierliche Zunahme der Verzögerungen. IdR gehen freeze auf das Konto von modulen die beim IO auf die Antwort warten (blockieren).

Dein thema könnte(!) auf eine Thematik im Zusammenhang mit Speicher (Datenstrukturen die über die Zeit im Speicher wachsen) hinweisen. Apptime scheint mir ein sehr guter Rat zu sein. Ich würde Apptime nach einem Neustart für 24h mitlaufen lassen und die Daten sichern. Das gleiche dann noch mal nach 2-3 Wochen. Im Idealfall wird ein modul auffällig.

Ist jedoch leider nicht trivial weil sich Ursache und Wirkung mitunter nicht klar trennen lassen. Fhem arbeitet alles was abläuft nacheinander (und verschachtelt) ab. Dabei können verschiedene Effekte ineinander greifen. Beispiel: Ein modul setzt ein reading. Dadurch werden events ausgelöst auf die innerhalb von notify, log usw reagiert wird. Wenn jetzt eines der notify "langsam" ist (welches innerhalb der funktion "setze das reading" ausgeführt wird) dann kann es so scheinen als ob das setzen des readings "langsam" ist.  Das zum Verständnis um Dir die Interpretation der apptime Daten besser zu ermöglichen ...

vg
joerg

[franky08]

Passt hier vlt. auch hin 

Mir ist aufgefallen das auf meinem Produktivsystem schön zu sehen ist wie der RAM "Verbrauch" nach einem Neustart kontinuierlich ansteigt. Nach einem Neustart von fhem zeigt der Host ca. 3,5% und nach einem halben Jahr sind es ca. 9%, dann mach ich vlt. mal ein update und lande wieder bei ca. 3,5 % und das Spiel fängt von vorn an. Da der Zotac nano genug Reserven hat und mit 8 Gb Ram ausgestattet ist fällt das nicht ins Gewicht aber User die mit weniger Performance unterwegs sind werden dann irgendwann in ein Memory Leak laufen.

VG
Frank

[herrmannj]

passt definitiv

Das Spiel kann in zwei Richtungen laufen. Entweder es ist ein echtes Leck und die Daten "liegen im Niemandsland". Häufige Ursache sind closures oder (zirkulare) self referenzen. Spielart 2 wäre das gültige Strukturen immer weiter anwachsen. (in einen hash werden immer neue Keys geschrieben ohne das was rausgelöscht wird, in ein array wird gepushed). Würde eher auf #2 Tippen weil das auch mit einem anwachsen der CPU Zeit (beim durchsuchen zb) einhergehen würde.

Schwer einzugrenzen und alles nur Hypothesen...

vg
joerg

[Raven]

Vielen vielen Dank für die Rückmeldungen & ausführlichen Erläuterungen!

Apptime hatte ich bereits im Einsatz, aber ich hatte die Ausgangswerte nicht mit späteren Werten verglichen.
Das werde ich jetzt machen.

Auffällig finde ich noch, daß der starke Anstieg innerhalb eines Tages stattfand, aber dann unverändert auf dem höhren Niveau verblieb.
Über die nächsten Wochen werde ich mir alle Auffälligkeiten genauestens notieren.
Ich habe bspw. das SqueezeModul im Einsatz und den dazugehörigen Logitechmediaserver (LMS) spreche ich remote an.
Evtl. hängt der CPU-Anstieg damit zs, falls mal der LMS nicht verfügbar war.