Neues Modul: 98_FREEZEMON Freezes monitoren und Verursacher identifizieren

Begonnen von KernSani, 05 Februar 2018, 23:27:22

Vorheriges Thema - Nächstes Thema

KernSani

'n abend,

irgendwie wird das immer länger, daher kurz:
Deine Datenbank scheint nicht die schnellste zu sein (vielleicht weil du zu viel loggst und sie daher groß ist?), daher meine persönliche Meinung, nur die Devices loggen, die du wirklich brauchst (oder erfreust du dich an einem Chart, wann deine Steckdose an war?) und nur die Events loggen, die du brauchst (event-on-change setzen, oder mit DBLogExclude-Attribut). In history loggen  reicht i.f.R. (ich glaube nur der Plot-Editor schaut in current).
Das Gute an der Meldung, die du heute im Log hattest: Der letzte Fix hat getan, was er soll. Ich habe aber übersehen, das auch im darauf folgenden Schritt abzufangen. Fix kommt morgen im Update.

RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

RoBra81

Hallo,

Ich bin mal wieder auf der Suche nach den Übeltätern, die die vielen Freezes bei mir verursachen. Dabei kann mir die Idee, dass eine (zuschaltbare?) Statistik nicht schlecht wäre, die die einzelnen möglichen Verursacher zählt: pro "possibly caused by"  wird ein reading angelegt, in dem die Häufigkeit gezählt wird. Damit kommt man vielleicht den häufigen Übeltätern leichter auf die Spur? Wäre es möglich und sinnvoll, so etwas einzubauen?

Vielen Dank
Ronny

Gesendet von meinem LYA-L29 mit Tapatalk


Pfriemler

Ich habe mir für diesen Zweck ein quick&dirty in VB6 zusammengebastelt. Die Ergebnisse waren nicht sonderlich erhellend...
Details ggf. per PM.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

KernSani

Zitat von: RoBra81 am 19 Januar 2019, 13:58:10
Ich bin mal wieder auf der Suche nach den Übeltätern, die die vielen Freezes bei mir verursachen. Dabei kann mir die Idee, dass eine (zuschaltbare?) Statistik nicht schlecht wäre, die die einzelnen möglichen Verursacher zählt: pro "possibly caused by"  wird ein reading angelegt, in dem die Häufigkeit gezählt wird. Damit kommt man vielleicht den häufigen Übeltätern leichter auf die Spur? Wäre es möglich und sinnvoll, so etwas einzubauen?
Die Überlegung hatte ich auch schon mal. Möglich ist das bestimmt, sinnvoll? Weiß ich nicht...  Ich persönlich kenne meine Pappenheimer auch so... aber ich schau mal was ich hin bekomme, kann man dann ja evtl. optimieren.
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

KernSani

Anbei mal eine Version zum testen. Wenn Attribut fm_statistics auf 1 gesetzt wird, wird für jedes Device "probably causing a freeze" ein Reading angelegt und gezählt, wie oft es möglicherweise an einem Freeze beteiligt ist.

nach /FHEM kopieren und einen shutdown restart machen.

RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Nestor

I have frequent freezes with the updated Weather module with Dark Sky integration.
Never had any freeze with the previous Yahoo Weather integration.

1 - 2019-01-19 [Log]: s:08:02:41 e:08:02:42 f:1.217 d:tmr-Weather_GetUpdate(Weather_Ganshoren)
1 - 2019-01-19 [Log]: s:10:02:54 e:10:02:55 f:1.01 d:tmr-Weather_GetUpdate(Weather_Ganshoren)
1 - 2019-01-19 [Log]: s:13:03:14 e:13:03:15 f:1.155 d:no bad guy found :-(
1 - 2019-01-19 [Log]: s:21:04:08 e:21:04:09 f:1.249 d:tmr-Weather_GetUpdate(Weather_Ganshoren)
1 - 2019-01-19 [Log]: s:23:46:42 e:23:46:44 f:2.144 d:cmd-set Weather_Ganshoren update (WEB) fn-SetFn(Weather_Ganshoren) fn-ReadFn(WEB_172.16.3...
1 - 2019-01-20 [Log]: s:00:06:46 e:00:06:47 f:1.553 d:tmr-Weather_GetUpdate(Weather_Ganshoren)
1 - 2019-01-20 [Log]: s:00:56:52 e:00:56:53 f:1.035 d:tmr-Weather_GetUpdate(Weather_Ganshoren)
1 - 2019-01-20 [Log]: s:09:07:47 e:09:07:48 f:1.024 d:tmr-Weather_GetUpdate(Weather_Ganshoren)


It seems that DarkSky API is somewhat slower to respond but it doesn't matter since the HTTP requests should be non-blocking (and DNSServer attribute is also set in Global).
I don't know a lot about Fhem internals but it seems the freeze is happening between the publishing of the Weather state and the end of the notify loop.

The freeze of a second is always here (with fm_logFile enabled):
2019.01.20 09:07:46.941 4: Weather_Ganshoren: T: -4 °C H: 87 % W: 5 km/h P: 1016 hPa
--- log skips 1.083 secs.
2019.01.20 09:07:48.023 5: End notify loop for Weather_Ganshoren


KölnSolar

freezemon, such a useful modul.  8)

You better should post your issue in  the appropriate subforum, since the developer of DarkSky API will not read this post.
Regards Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Nestor


KölnSolar

Ah, since the author of freezemon gave that advice, it might be an issue with the freezemon_modul....
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KernSani

@SenH: Could you post the complete fm_log of the freeze? I actually don't think it's an issue with the freezemon or the weather module. In my experience this happens if modules update a lot of readings, which trigger a lot of events etc... so setting appropriate "event-on-.*" attributes might help.
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

KernSani

@SenH: Could you set the fm_Catch.* attributes in freezemon? Additionally I'd recommend to set the fm_logFile to something like ./log/freeze-%Y%m%d-%H%M%S.log. That way you would get a single logfile per freeze.
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Nestor

They are already set, I will update the fm_logfile.
Attributes:
   fm_CatchCmds 1
   fm_CatchFnCalls 1
   fm_forceApptime 1
   fm_logFile ./log/system/freezemon-%Y.log
   fm_whitelistSub ModbusLD_GetUpdate,Modbus_ProcessRequestQueue
   icon       alert-circle
   room       System->Fhem

CoolTux

Bin gespannt was dabei raus kommt.
Alternativ wird es die Tage ein Update geben wo man die Forecastreadings begrenzen kann.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Pfriemler

Andere Baustelle, mit der Bitte um Reaktionen...
Nach der Bereinigung meiner fhem.cfg haben sich meine haufenweise Freezes mittlerweile gemäßigt, ohne aber signifikant abzunehmen. Ich habe ohnehin nur Chancen mich um alles länger als 4 Sekunden zu kümmern. Nach längerer Interpretation bin ich zum Schluss gekommen, dass viele der Alarme Fehlmeldungen sind, weil just in diesem Moment (so etwa zu jeder vollen Stunde) diverse kleine Routinearbeiten abgearbeitet werden und das System damit schlicht am Limit läuft (auf einem 2er Raspi).

Richtig dicke Hunde fabriziere ich aber beim Aufrufen einiger meiner Räume: So dauert der Aufbau der Anzeige meines randvollen "CUL_HM"-Raumes mit gut 100 oder sogar mehr Einträgen inzwischen etwas über 20 Sekunden - und prompt gibt es einen Freeze im Log, eben mal ohne "bad guy", andererseits mit zwei Dutzend möglichen Schuldigen, wobei es sich dabei eigentlich ausschließlich um eben diese routinemäßig sonst unauffälligen Aufgaben handelt. Da bin ich derzeit dabei, die terminlich zu "entballen" durch die Variation der Intervalle in denen sie aufgerufen werden.

Definitiv also ist das Arbeiten an FHEM durch die zähen Aufrufe eine Ursache der Alarme. Nun sollte ich vielleicht daran gehen, die Seiten zu entschlacken. Ein Raum mit diversen Readingsgroups reagiert dabei deutlich flüssiger als eben dieser "CUL_HM" - "Unsorted" geht eigentlich schon gar nicht mehr, da meldet sogar der Browser einen Verbindungsabbruch...

Nun an die Erfahrenen: Was sind in dieser Hinsicht möglicherweise "Performancekiller"
- stateFormats (ich nutze bspw. "[$name:state] ([$name:state:t])" gern um das Alter eines Readings anzuzeigen bei wackliger Kommunikation)
- icon für Geräte/Kanäle
- cmdIcon (zur Aufhübschung der Bedienung)
- ???
also was sind eventuell "Todsünden" des "Designs"?

Mittelfristig braucht's eh einen neuen Rechner - wegen der Einkernigkeit von FHEM vermutlich lieber einen 2,x GHz Dualcore als einen 1,6 GHz Quad ...  (?)

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

rasti

Hallo,

ich habe eine ältere FHEM-Version und eben versucht nur dieses eine Modul per Modulupdate einzubinden.

Ein define myFreezemon freezemon führt dann zu Cannot load module freezemon

Im Log steht :


2019.01.20 12:12:53.365 1: reload: Error:Modul 98_freezemon deactivated:
Global symbol "@intAtA" requires explicit package name at ./FHEM/98_freezemon.pm line 306.
BEGIN not safe after errors--compilation aborted at ./FHEM/98_freezemon.pm line 499.

2019.01.20 12:12:53.366 0: Global symbol "@intAtA" requires explicit package name at ./FHEM/98_freezemon.pm line 306.
BEGIN not safe after errors--compilation aborted at ./FHEM/98_freezemon.pm line 499.
 


Auch wenn das hier wahrscheinlich  keiner hören will, ein Komplettupdate von FHEM wage ich derzeit nicht.  ::)

Weiss jemand, was den Fehler verursacht und wie man ihn behebt ?

Schöne Grüße
Ralf