Autor Thema: FHEM wird über Wochen langsamer: welches Modul benötigt mehr CPU? sysmon/perform  (Gelesen 443 mal)

Online Raven

  • Full Member
  • ***
  • Beiträge: 241
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.
Cubietruck-Prod: HM-LAN, Heizung, Rolläden, Schalter, Viessmann (optolink)
Cubietruck-DEV:
Fritzbox 7490

Offline dl4fb

  • Full Member
  • ***
  • Beiträge: 281
Moin,
Hast du apptime schon mal probiert?
Gruß Helmut

Online herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 3975
Zitat
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
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline franky08

  • Hero Member
  • *****
  • Beiträge: 3959
  • jetzt DBLog befreit
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
Debian Wheezy auf ZBOX nano (240GB SSD) FHEM2FHEM an 2xRaspiB
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu ,fhem5.8, WH1080 fowsr an 2.RaspiB
Raspi B mit COC für ESA 2000 und CO2-Sensor
ECMD an AVR-NET-IO mit DAC u. ADC an Junkers Stetigregelung, Siemens LOGO!8

Online herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 3975
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
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Online Raven

  • Full Member
  • ***
  • Beiträge: 241
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.
Cubietruck-Prod: HM-LAN, Heizung, Rolläden, Schalter, Viessmann (optolink)
Cubietruck-DEV:
Fritzbox 7490