Fhem sporadisch langsam viele Freese

[e_brandt]

Im Anhang der Freeze Log

[KölnSolar]

Da ist jetzt nur ein "freeze" drin. Wenn Du es länger laufen lässt, sammelt es sich....

Der eine freeze scheint mir kein freeze zu sein, bzw. zeigt nur dass das Lesen der Logs für Deine Anzeige lange dauert.
Die erschwert die Analyse. Kannst Du die Anzeige mal "stilllegen", und dann mal nach nem Stündchen das Log wieder posten...

[e_brandt]

Da ist jetzt nur ein "freeze" drin. Wenn Du es länger laufen lässt, sammelt es sich....

Der eine freeze scheint mir kein freeze zu sein, bzw. zeigt nur dass das Lesen der Logs für Deine Anzeige lange dauert.
Die erschwert die Analyse. Kannst Du die Anzeige mal "stilllegen", und dann mal nach nem Stündchen das Log wieder posten...

Ich glaube der macht für jedes Freeze eine log Datei, kann ich das ändern?
sorry, mir fehlt das Fachwissen 

[KernSani]

Das hängt am Namen des Logfiles (der im Attribut angegeben ist). Nimm da z.B. Sekunden und Minuten raus


Kurz, weil mobil

[viegener]

Auf dem Raspy ist nur das drauf was ich für Fhem und das was ringsum Fhem ist benötige, normal sollte die Leistung vom 3er doch dafür ausreichen oder?
Htop ist doch unauffällig oder? siehe Bild Speicher ist noch frei...

Ich kann nicht sagen ob das zu den Freezes führt, aber ich finde htop nicht so unauffällig - wenn es keine Momentaufnahme ist.
27% mem für FHEM ist ordentlich und 60% der CPU (wenn dauerhaft) heisst für mich der pi ist schon ganz ordentlich unter Dampf

Ausserdem nochmal zu den Monatsplots:

Auf der Grafik erkenne ich 14 verschiedene Kurven - von denen zumindest einige mindestens einmal pro minute einen neuen Wert haben.

Also 60 pro Stunde - oder 4000 pro monat und dann noch mal 14 --> Also >60000 Datenpunkte, die jede Minute gelesen und geplottet werden.
==> WIe schon gesagt, kannst Du das mal zwischenzeitlich abklemmen - dann lässt sich der Rest besser analysieren.

[e_brandt]

Ich kann nicht sagen ob das zu den Freezes führt, aber ich finde htop nicht so unauffällig - wenn es keine Momentaufnahme ist.
27% mem für FHEM ist ordentlich und 60% der CPU (wenn dauerhaft) heisst für mich der pi ist schon ganz ordentlich unter Dampf

Ausserdem nochmal zu den Monatsplots:

Auf der Grafik erkenne ich 14 verschiedene Kurven - von denen zumindest einige mindestens einmal pro minute einen neuen Wert haben.

Also 60 pro Stunde - oder 4000 pro monat und dann noch mal 14 --> Also >60000 Datenpunkte, die jede Minute gelesen und geplottet werden.
==> WIe schon gesagt, kannst Du das mal zwischenzeitlich abklemmen - dann lässt sich der Rest besser analysieren.

Ja das ist nur eien momentaufnahme, CPU geht zwischendurch viel weiter runter bzw zeig garnichts an.

Im Anhang der geänderte Freeze log, ca eine stunde

[KernSani]

Die Erkenntnis, die ich aus dem Freezelog ziehe, ist nicht sehr überraschend. SENSOREN_LOG wird 1mal pro Minute 2mal gelesen und verarbeitet was in Summe um die 5 Sekunden kostet, Outputs_Log ist deutlich schneller (aber auch > 500ms). Wie viegener schon gesagt hat. Ich denke wann man das Ding mal deaktiviert dann rennt der Raspi (oder wir finden noch was anderes .
Normalerweise sollte ein Raspi 3 nur für FHEM nicht über 10% CPU gehen, die meiste Zeit deutlich darunter, wenn ich mich recht erinnere (Bin mittlerweile auf 'nem Pi4)

[mumpitzstuff]

Über folgendes solltest du nachdenken:

Brauche ich die Daten von jedem Plot jede Minute? -> Antwort: Nein

Was ist ein vernünftiger Zeitraum? -> Vielleicht alle 15 oder 30 Minuten?!?

Jetzt gehst du her und und hängst nicht alles in eine Funktion rein, sondern verteilst den Load z.B. mit mehreren at (ich bin mir nicht sicher, ob man hier vielleicht auch das fhem sleep() verwenden könnte), so dass nicht alles zur selben Zeit abgerufen wird. Außerdem könntest du mal plotfork aktivieren. Dadurch sollte das Pinseln deiner SVGs den Hauptprozess nicht mehr blockieren.

https://fhem.de/commandref_DE.html#FHEMWEB

Die Option longpollSVG hast du hoffentlich ausgeschaltet, sonst pinselt dir fhem die Plots jedes Mal neu, wenn du die Oberfläche im Browser geöffnet hast und sich da was ändert.

[e_brandt]

Okay haben die Tipps umgesetzt bzw waren die schon umgesetzt

Wir sind die Logs durchgegangen und haben noch sehr viel gefunden das wir optimieren und sparen konnten.
Wir haben den Sensoren.log auf mehrere log gesplittet zum test und siehe da jetzt ist er wirklich merklich schneller ABER die Freeze sind kaum weniger geworden, im moment bin ich bei 1300, gestern waren es 2060, immerhin

[KernSani]

Solange du das Ding jede Minute auffrischst, dürftest du nicht unter 1440 Freezes in 24h kommen
Was mal interessant wäre, wie oft loggst du denn in Sensoren_Log, also wie viele Datenpunkte kommen da pro Tag zusammen? Hast du mal überlegt mit event-on-change-reading mit threshold zu arbeiten o.ä.?
Wäre es eine Option in eine Datenbank zu loggen(ich glaube mich zu erinnern, dass das bei mir ordentlich was gebracht hat)

[e_brandt]

Solange du das Ding jede Minute auffrischst, dürftest du nicht unter 1440 Freezes in 24h kommen
Was mal interessant wäre, wie oft loggst du denn in Sensoren_Log, also wie viele Datenpunkte kommen da pro Tag zusammen? Hast du mal überlegt mit event-on-change-reading mit threshold zu arbeiten o.ä.?
Wäre es eine Option in eine Datenbank zu loggen(ich glaube mich zu erinnern, dass das bei mir ordentlich was gebracht hat)

event on change reading hab ich drin aber der logt ja die Nachkommastellen mit bei den Pufferspeichern, das ist unnötig, ich weiß aber nicht wie es besser geht...
mit dem Threshold schnall ich auch nicht wie das geht.

[KölnSolar]

eigentlich easy

Code Auswählen Erweitern

attr RPi_OW_WZ event-on-change-reading temperature:1
hilft Dir bei

ja die Nachkommastellen mit bei den Pufferspeichern, das ist unnötig,

ungemein.
Edit: und bei 1W wg. der Auflösung 0,0625

Code Auswählen Erweitern

attr RPi_OW_WZ event-on-change-reading temperature:0.1

[e_brandt]

Tja wir haben jetzt mal den Sensoren log in einzelne Logs separiert und wie schon gesagt jede Menge eingespart. Es ist jetzt auch in den Logs mal 1-2 Minuten ruhe. leider sind die Freese nur geringfügig weniger geworden.
Vieleicht kann ja noch einmal jemand draufschauen.

Eigentlich läuft er jetzt aber ganz gut.

[KernSani]

WWSpeicher_oben_log scheint noch zu bremsen...

[e_brandt]

WWSpeicher_oben_log scheint noch zu bremsen...

da war noch eventmininterval drin aber da kam dann nur alle 5 min ein Wert