Hi,
ich habe hier im Logfile einen Hinweis erhalten, dass reduceLogNbl nicht mehr verwendet werden sollte, sondern dafür DbRep eingesetzt werden sollte:
DbLog DbLog - WARNING - "reduceLogNbl" is outdated. Please consider use of DbRep "set reduceLog" instead.
DbLog DbLog: reduceLogNbl requested with DAYS=90, AVERAGE=HOUR
Ich habe bisher ein at-Device mit folgendem Befehl:
set DbLog reduceLogNbl 90 average
Wie muss ich das jetzt ändern, wenn ich DbRep set reduceLog einsetzen will?
Insbesondere verstehe ich nicht, wie man set ReduceLog so konfiguriert, dass er AVERAGE=HOUR macht. Ich kann das in meiner bisherigen Lösung auch so nicht nachvollziehen. Weder im DBLog noch im at-Device finde ich etwas wie AVERAGE=HOUR
Wäre für einen Tipp dankbar
LG
Guten Abend,
Zitat
Wie muss ich das jetzt ändern, wenn ich DbRep set reduceLog einsetzen will?
Du definierst dir zuerst ein DbRep-Device wie in der commandref beschrieben.
In dem Device gibt es den reduceLog -Befehl. Dessen Syntax ist der Syntax im DbLog sehr ähnlich, aber nicht identisch.
Es gibt mehr Möglichkeiten und Aufrufvarianten.
Deinen Befehl kannst aber fast identisch auf DbRep übertragen:
set <DbRep> reduceLog 90 average
In der commandref sind die weiteren Möglichkeiten detailliert beschrieben.
Zitat
Insbesondere verstehe ich nicht, wie man set ReduceLog so konfiguriert, dass er AVERAGE=HOUR macht. Ich kann das in meiner bisherigen Lösung auch so nicht nachvollziehen. Weder im DBLog noch im at-Device finde ich etwas wie AVERAGE=HOUR
Das Schlüsselwort "average" impliziert "average=hour". Man könnte genauso
set <DbRep> reduceLog 90 average=hour
schreiben.
Du solltest auf jeden Fall das neueste DbRep benutzen weil ich erst vor kurzer Zeit die reduceLog Funktion stark überarbeitet und ergänzt habe.
LG
Hallo,
habe gerade ein Update gemacht und gesehen, dass da auch DbRep aktualisiert wurde. Das Commando im at-Device habe ich jetzt entsprechend geändert.
Vielen Dank. Das hat sehr geholfen.
LG
Habe leider gerade im Log gesehen, dass der Prozess "gestorben" ist
2022.09.16 22:00:51 1: DbRep Rep.DbLog - BlockingCall DbRep_reduceLog pid:DEAD:31763 Process died prematurely
2022.09.16 22:00:51 2: DbRep Rep.DbLog - Database reduceLog aborted: "Process died prematurely"
Was kann da los sein?
LG
Die Ursache dafür geht aus der Meldung nicht hervor.
Oftmals ist die Ursache wenn der verfügbare Hauptspeicher zur Neige geht oder ein Datenbankfehler passiert.
Der reduceLog Fortschritt wird mit verbose 3 protokolliert. Man sieht dann in etwa wo der Abbruch passiert. verbose 4 gibt noch die abgearbeiteten SQL Statements aus und man sieht das letzte Statements vor dem Abbruch.
Auch den Zeitraum einzugrenzen kann nützlich sein, also z.B. aufrufen:
set <DbRep> reduceLog 90:120 average
LG
OK. Damit komme ich schon mal weiter. Offenbar habe ich hier wirklich ein Memory-Problem.
Ich müsste daher entweder:
- ein USB-Stick als Swap-Device einrichten vorzugsweise so : https://www.derpade.de/raspberry-pi-swap-auf-externen-usb-stick-auslagern/
(nicht so cool)
- oder es irgendwie schaffen, dass vor dem reduceLog ein paar services gestoppt und danach wieder gestartet werden (z.B. sudo systemctl stop grafana.service)
(bevorzugt)
Bei letzterem bräuchte ich einen Hinweis, wie ich das sinnvollerweise machen kann. Die services dürfen ja erst wieder starten, wenn das reduceLog erledigt ist. Wie bekomme ich das mit?
LG
Zitat
Die services dürfen ja erst wieder starten, wenn das reduceLog erledigt ist. Wie bekomme ich das mit?
Entweder auf "done" triggern (state), oder das Attr executeAfterProc nutzen.
Hier kannst du einen Befehl oder Code absetzen. Was in executeAfterProc steht wird abgearbeitet wenn DbRep mit seiner Aufgabe fertig ist.
Es gibt auch executeBeforeProc um etwas auszuführen bevor DbRep beginnt.
Zum Verwalten von Diensten kannst du dir das Modul http://fhem.de/commandref_DE.html#serviced anschauen
LG
Was mir eben gerade aber aufgefallen ist: Nachdem ich mir mit Verbose=4 den Ablauf angesehen habe, habe ich mal die RAM-Auslastung beobachtet. Diese steigt stetig an, obwohl für einen Tag die Delete und Update (und anschließendes commit) durch sind. Das kann ich nicht ganz nachvollziehen. Ich habe jetzt schon 600MB verbraucht und obwohl ich jetzt sämtliche Services, die ich gerade nicht benötige gestoppt habe, bin ich wieder kurz vor der RAM-Grenze. Der Prozess ist daher auch gerade wieder gestorben
Das ist mir (selbst mit eingeschalteten Services) im DbLog reduceLog nicht passiert.
So wie ich das sehe, wird erst mal alles selektiert, was in den gewissen Zeitraum für ReduceLog fällt mit order by timestamp asc. Dann werden die Datensätze gelöscht und danach mittels update die average-Werte in die History geschrieben und dann committed. Zumal ich auch nicht ganz verstehe, warum dabei der RAM-Bedarf immer größer wird?
Könnte man da nicht noch etwas optimieren?
LG
ZitatDas ist mir (selbst mit eingeschalteten Services) im DbLog reduceLog nicht passiert.
DbLog reduceLog arbeitet blockierend ohne einen parallelen Prozess. DbRep benötigt durch die nichtblockierende Arbeitsweise mehr Speicher durch einen parallelen Arbeitsprozeß wenn reduceLog läuft.
ZitatKönnte man da nicht noch etwas optimieren?
Ich habe etwas verändert.
Test mal die V aus meinem contrib ob sich der Speicherverbrauch verändert.
Zum Download in der FHEMWEB Kommandozeile inklusive der Anführungszeichen angeben und danach FHEM restarten:
"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"
LG
Ich probiere ob ich das heute noch schaffe. Ansonsten kann ich Dir leider erst morgen eine Rückmeldung geben. Aber erstmal Danke, dass Du da dran bist.
LG
Kein Stress. Ich mache auch erstmal bisschen Urlaub.
LG
Habe die Version gerade mal runtergeladen und fhem restarted. Wenn ich nun das DRep Device öffnen will passiert auf der Oberfläche nichts außer
"Fhem loading"...
Aber nach ein paar Minuten tut sich doch noch was.
Version ist 93_DbRep.pm:v8.50.3-s26413/2022-09-17
LastCmd ist: initial database connect stopped due to attribute 'fastStart'
reduceLog 90:120 average braucht jetzt nur noch etwa 50MB (anstatt 700) und ist nach etwa 1 Minute fertig (anstatt 1,5 Stunden und dann "died") Insofern schonmal Top.
Vielen Dank.
Liest sich gut. Kannst du mir sagen welche DbRep Version du vorher hattest ?
Denn die Meldung
LastCmd ist: initial database connect stopped due to attribute 'fastStart'
habe ich schon ziemlich lange als Standard eingebaut. Wenn du es noch nie gesehen hast, war deine DbRep Version schon ziemlich alt.
Habe die neue Version eingecheckt. Ist morgen früh im Update enthalten.
LG
Habe gerade das Update gemacht, aber jetzt ist das Verhalten aber fast wieder so, wie vor der Version 93_DbRep.pm:v8.50.3-s26413/2022-09-17
Aktuell habe ich die Version 93_DbRep.pm:v8.50.3-s26429/2022-09-19
RAM geht hoch von 600 auf 880 MB
Das ist leider wieder zuviel für meinen rPi3 B+
Kann man da nicht noch etwas machen?
LG
Dann liegt es aber nicht am Modul, denn die Versionen Trst und check in sind identisch.
Von 600 auf 880 sind gerade mal 220 und mit einem parallelen Prozess nicht als zuviel zu bewerten.
Da kann man nur die in einem Vorgang zu bearbeitenden Daten reduzieren durch ensprechende Parameter im Aufruf oder bei der blockierenden DbLog Variante bleiben wenn man damit leben kann. Sie bleibt ja erhalten, wird nur nicht mehr gepflegt.
LG
OK. Ich habe jetzt mal beobachtet und es funktioniert doch alles so, wie gewohnt. 3 Minuten Nachts um 3:00 Uhr und wenn das jeden Tag läuft, dann gibt es mit dem RAM auch keine Probleme. Ich schließe das Thema dann.
Vielen Dank für Deine Unterstützung.
LG