Neues Modul: 98_FREEZEMON Freezes monitoren und Verursacher identifizieren

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

Vorheriges Thema - Nächstes Thema

frank

Zitat von: KernSani am 20 Januar 2019, 11:22:37
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...
verstehe ich das richtig?:

alleine die existenz einer genügend grossen "flut" von events  erzeugt bereits freezes.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

CoolTux

Zitat von: rasti am 20 Januar 2019, 12:33:36
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

intAtA wurde vor fast einem Jahr von Hash auf Array umgestellt. Daher bedarf es einem Update von fhem.pl.  Es müssen aber noch andere Module ein Update erhalten. Welche genau weiß ich leider nicht mehr.
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

rasti

Zitat von: CoolTux am 20 Januar 2019, 12:55:26
intAtA wurde vor fast einem Jahr von Hash auf Array umgestellt. Daher bedarf es einem Update von fhem.pl.  Es müssen aber noch andere Module ein Update erhalten. Welche genau weiß ich leider nicht mehr.

OK. Das hört sich leider so an, als ob ich in nächster Zukunft auf freezemon verzichten müsste   :'(

CoolTux

Zitat von: rasti am 20 Januar 2019, 13:06:49
OK. Das hört sich leider so an, als ob ich in nächster Zukunft auf freezemon verzichten müsste   :'(
Du willst also dein ein Jahr altes System nicht updaten?
Nur eine Frage.
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

rasti

Zitat von: CoolTux am 20 Januar 2019, 13:08:35
Du willst also dein ein fast 3 Jahre altes System nicht updaten?
Nur eine Frage.

Genau. Aber bitte deswegen jetzt keine Diskussion lostreten..... ;)

KernSani

Zitat von: CoolTux am 20 Januar 2019, 12:55:26
intAtA wurde vor fast einem Jahr von Hash auf Array umgestellt. Daher bedarf es einem Update von fhem.pl.  Es müssen aber noch andere Module ein Update erhalten. Welche genau weiß ich leider nicht mehr.
Wenn ich mich recht erinnere war nur apptime auch betroffen


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

KernSani

Zitat von: rasti am 20 Januar 2019, 13:06:49
OK. Das hört sich leider so an, als ob ich in nächster Zukunft auf freezemon verzichten müsste   :'(
Im SVN müsste es noch die Version von vor der Umstellung geben. Habe aber keine Ahnung, was da an anderen Problemen auftreten kann...


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

Pfriemler

Zitat von: frank am 20 Januar 2019, 12:47:07
verstehe ich das richtig?:

alleine die existenz einer genügend grossen "flut" von events  erzeugt bereits freezes.

nach meiner bescheidenen Sicht ja, aber indirekt. Events wollen abgearbeitet werden, und jedes Event wirft die globale Notifyschleife erneut an. Kommen diese Events entsprechend so häufig, dass dazwischen kein Platz mehr für anderes bleibt, gibt es Freezes.
Ein besonders erfolgreicher Punkt meiner Aufräumung war tatsächlich die umfassende Einführung von detaillierten "event-on-change-reading". Seither tröpfelt es nur noch im EventMonitor, sehr übersichtlich ...
"Ä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: frank am 20 Januar 2019, 12:47:07
verstehe ich das richtig?:

alleine die existenz einer genügend grossen "flut" von events  erzeugt bereits freezes.
Keine Freezes im eigentlichen Sinne, FHEM ist dann nur so mit der Abarbeitung der Events beschäftigt, vor allem wenn z.B. wahllos geloggt wird, dass andere Commands nicht mehr drankommen (das ist eine empirische Beobachtung, keine technisch validierte Aussage)


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

CoolTux

Zitat von: rasti am 20 Januar 2019, 13:12:16
Genau. Aber bitte deswegen jetzt keine Diskussion lostreten..... ;)

Ich würde niemals über sowas diskutieren. Muss es nur wissen damit ich nicht umsonst meine kostbare Zeit bei Deinen Problemen verschwende. Von daher danke für Deine Ehrlichkeit und Dein Verständnis.
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

rasti

Zitat von: KernSani am 20 Januar 2019, 13:17:13
Im SVN müsste es noch die Version von vor der Umstellung geben. Habe aber keine Ahnung, was da an anderen Problemen auftreten kann...


Das wäre ein Hoffnungsfunke.
In https://svn.fhem.de/trac/log/trunk/fhem/FHEM/98_freezemon.pm habe ich @16276 genommen.
Das führt aber beim Einbinden zu:


Global symbol "%prioQueues" requires explicit package name at ./FHEM/98_freezemon.pm line 571.
Global symbol "%prioQueues" requires explicit package name at ./FHEM/98_freezemon.pm line 573.
Global symbol "%prioQueues" requires explicit package name at ./FHEM/98_freezemon.pm line 574.

KernSani

Zitat von: rasti am 20 Januar 2019, 13:39:13
Das wäre ein Hoffnungsfunke.
In https://svn.fhem.de/trac/log/trunk/fhem/FHEM/98_freezemon.pm habe ich @16276 genommen.
Das führt aber beim Einbinden zu:


Global symbol "%prioQueues" requires explicit package name at ./FHEM/98_freezemon.pm line 571.
Global symbol "%prioQueues" requires explicit package name at ./FHEM/98_freezemon.pm line 573.
Global symbol "%prioQueues" requires explicit package name at ./FHEM/98_freezemon.pm line 574.

Ohje... die Prioqueues sind noch älter.... Vielleicht probierst du es mit PERFMON, damit entdeckst du Freezes, aber ohne viel zusätzliche Info zum Verursacher...


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

KölnSolar

Zitatund jedes Event wirft die globale Notifyschleife erneut an.
Ich hatte kürzlich einen Fall, der dem etwas widerspricht. Nicht die events alleine sind das Problem, sondern nur dann, wenn ein notify matched und (Spekulation) der auszuführende Teil etwas träge ist.
In meinem fast freezefreien System hatte ich plötzlich permanente freezes. Zeitlich leicht für mich zu identifizieren, weil meinem simplen Drahtüberschwemmungssensor ein paar Wassertropfen zu nah gekommen waren. Bedeutet dann permanente events und Alarmierung über Alarmanlagenmodul(notify) mit Sprachausgabe auf dem Dot. (performance von FHEWEB war übelst). Im Rpi-GPIO-Modul gibt es aber leider weder inactive, noch disable, um die event-Flut abzuschalten. Nachdem ich das notify inactive gesetzt hatte war Schluss mit freezes(FHEMWEB blieb träge).
Grüße 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

KernSani

@SenH: I don't know how well you understand German - basically the discussion above was about what happens if a lot of events are fired, Conclusion: if a lot of events are fired (because a lot of readings are updated), FHEM is busy processing all these events, which might cause a freeze. This can be avoided by setting the event-on-.* attributes, so you only get the events you're really interested in (i.e. which are needed to trigger notifies etc... or should be logged).
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

KernSani

Zitat von: KernSani am 20 Januar 2019, 01:02:53
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.
Hatte sich das eigentlich jemand angesehen? Nachdem das Ding bei mir jetzt knapp 24h gelaufen ist, dachte ich, könnte man noch ein bisschen optimieren:
* es gibt ein set freezemon clear statistics
* Devices wie WEB_123.123.12.3_56789 werden jetzt in ein reading fc_WEB zusammengefasst
* Leere Devices werden rausgefiltert

Wenn kein großer Protest kommt, würde ich das wahrscheinlich morgen im SVN einchecken...
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...