DBLog - Historische Werte ausdünnen

[C0mmanda]

Mahlzeit,

ich habe DBLog am laufen und soweit ist alles top.

Wenn ich mir nun aber die Plots zu den Temperatur-Daten so anschaue kommen da extrem viele Datenpunkte zusammen die spät. nach einer Woche nicht mehr gebraucht werden, da nur noch für Plots verwendet. Plots mit sovielen Daten schauen spät. im Jahreslog auch nicht wirklich gut aus.

Frage: Wie kann ich z.B. alle Temperaturdaten welche älter als 1 Woche sind auf wenige Werte pro Tag ausdünnen? z.b. 12 Werte/Tag. (Alle 2 Stunden). oder min/max pro Tag etc.

set <dblog> deleteOldDays [n] würde ja alle Werte löschen was ich aber nicht will.

event-min-interval und event-on-change-reading sind bekannt und werden eingesetzt. (min-interval 600 und change-reading 0.2, dennoch sind es recht viele Daten)

Gibt es dazu ein Tool oder einen Lösungsansatz?
Habe das Forum rauf und runter durchsucht aber nicht so wirklich das gefunden was ich suche....

Vielen Dank!

[rapster]

Hallo C0mmanda,

die Idee finde ich Spitze, historische Daten nurnoch in Stundenintervallen aufzubewahren!

Fertig gibts da meiner Kenntnis nach allerdings nichts.

Ich habe mal auf die schnelle das DbLog Modul im Anhang Erweitert damit es diese Funktionalität bereitstellt.

"set <dbLogDevice> reduceLog <days>"
Dadurch sollten alle Einträge älter als <days> auf einen Eintrag pro Stunde (den ersten) je device & reading reduziert werden.

Bitte beachten: Das ganze ist sehr Ressourcenintensiv, sowie wird Fhem nach absetzen des Befehls bis zur Fertigstellung blockiert!

Du kannst es ja mal testen ob es deinen Ansprüchen genügt, und bescheid geben ob alles so funktioniert wie es soll.
Wenn ich mal Zeit habe, oder auch jemand anderst, dann kann das evtl. noch nicht blockierend implementiert werden.

Wenn du sehen möchtest was der Befehl gerade tut (löscht) kannst du die Zeile 1318 auskommentieren, dann taucht es im Log auf.

Gruß
Claudiu

EDIT: Datei entfernt, aktuelle Verison in Post #4

[C0mmanda]

Hallo rapster,

Vielen Dank für die schnelle Reaktion.

Ich habe das ganze jetzt mal ausgeführt, das Ergebnis ist ziemlich genau das was ich gesucht habe!

Ich hatte zu Beginn 337.800 Datensätze in der Datenbank. (aus ca. 7 Wochen!!).
Nach dem ausführen von reduceLogs sind es jetzt nur noch 91.054 Datensätze, in den Plots ist kein Unterschied zu sehen mit der Ausnahme dass diese etwas "glatter" sind und sich noch schneller aufbauen was auch das Ziel war.

Einzig die Jahresplots sind noch recht unleserlich, da hierfür noch immer zu viele Datenpunkte vorhanden sind, aber hier gibt es eventuell eine Lösung in den Plots selbst, anstatt "noch mehr" Daten zu löschen.
Denn mit noch weniger Datenpunkten wären dann die historischen Monats- und Wochenplots eventuell zu ungenau und unleserlich?!

Zu der "technischen" Seite:

- Ich betreibe fhem und auch die mySQL-Datenbank auf einem Intel NUC DN2820, Rechenpower ist also da (Im Vergleich zu FritzBox oder RasPi).

- reduceLogs hat jetzt ziemlich genau 25std. benötigt um 240.000 Datensätze zu löschen. Ich habe die Sache recht genau beobachtet, es    werden ca. 2-4 Datensätze pro Sekunde gelöscht.
Damit sollte für andere User in etwa auszurechnen sein wie lange ihr fhem blockiert ist.

Meine Erwartungen sind soweit erfüllt, ich werde reduceLogs nun regelmäßig laufen lassen, dann sollte sich die Zeit in der fhem blockiert ist stark reduzieren.

Sollte es möglich sein reduceLog im Hintergrund laufen zu lassen ohne das fhem blockiert wäre das natürlich eine super Sache, für mich ist es aktuell aber auch in Ordnung. Dauert ja nur einmal so lang, wenn man es regelmäßig macht wird es schneller gehen. Wenn fhem dann Nachts mal eine halbe Stunde blockiert kann man sicher damit leben. Ich zumindest kann es.

Wenn noch Fragen zu dem Test offen sind immer raus damit.

Ich jedenfalls bedanke mich für die schnelle Reaktion und Hilfe. Top!

[Pyromane]

Sollte es möglich sein reduceLog im Hintergrund laufen zu lassen ohne das fhem blockiert wäre das natürlich eine super Sache, für mich ist es aktuell aber auch in Ordnung. Dauert ja nur einmal so lang, wenn man es regelmäßig macht wird es schneller gehen. Wenn fhem dann Nachts mal eine halbe Stunde blockiert kann man sicher damit leben. Ich zumindest kann es.

Eine alternative wäre noch das ganze in einem Cronjob unabhängig von FHEM abarbeiten zu lassen.
Dazu müsste die "reduceLog" Funktion in einem Shellskript abgebildet werden.

[rapster]

super, freut mich dass bei dir auch alles geklappt hat! 

Hab die reduceLog Funktion nochmal etwas überarbeitet,
is zwar noch nicht Non-Blocking, allerdings nun um ein vielfaches schneller!

Es wird jetzt nicht mehr für jeden Datensatz eine eigene Transaktion durchgeführt sondern pro Tag.
Die Commandref wurde desweiteren um diesen Befehl erweitert.

Mit dieser Version werden auf meinem System (sqlite) etwa 1.800 Datensätze pro Minute aus der Datenbank entfernt,
Davon ausgehend, dein System ist genauso schnell wie meins, sollte es bei dieser Datenmenge nicht mehr 25std. sondern nurnoch etwas über 2std. dauern.

Im Anhang die aktuelle Version, sowie ein Patch für tobiasfaust um das ganze ins FHEM-Update einzuchecken.

Gruß
  Claudiu

EDIT: Datei entfernt, aktuelle Version in Post #28 => http://forum.fhem.de/index.php/topic,41089.msg334617.html#msg334617

[C0mmanda]

Wow, das geht ja Schlag auf Schlag
Großartig!

Bei nun 1800 Datensätze pro Minute sollte der Job, wenn er jede Nacht läuft, ja nur wenige Minuten (wenn überhaupt) benötigen, das reicht mir schon völlig.

Kann dann morgen nochmal berichten wie schnell es aktuell durchläuft wenn die DB schon bereinigt ist und nur 1 Tag bereinigt wird.

Bis dahin kann ich mich nur für die Superschnelle Lösung bedanken!

grtz
C0mmanda

[rapster]

Ja das wär super, bin gespannt wie lange das Bereinigen von einem Tag mit der aktuellen Version bei dir dauert.
Evtl. kannst du noch prüfen wieviel Records betroffen waren.

Das löschen von einem Tag (20.07.) an welchem von 23762, 21017 Records gelöscht wurden dauerte bei mir knappe 14 Minuten (~1.500/min) mit dieser Hardware:
VM mit 1 Core i5 @ 2.4 Ghz, 3GB RAM, SSD Samsung 512GB 840 Pro, SQLITE Datenbank

Das löschen von einem Tag (22.07.) an welchem von 24782, 22009 Records gelöscht wurden dauerte bei mir knappe 6,5 Minuten (~3300/min) mit dieser Hardware:
VM mit 2 Core i5 @ 2.4 Ghz, 3GB RAM, SSD Samsung 512GB 840 Pro, SQLITE Datenbank

Die benötigte Zeit hängt also sehr von den zur Verfügung stehenden CPU-Ressourcen ab.

BTW, hab die zuletzt gepostete Version nochmals bearbeitet,
mit "attr verbose 5" werden alle gelöschten Zeilen protokolliert,
mit "attr verbose 3" lässt sich wie im folgenden Beispiel loggen/beobachten welcher Tag gerade verarbeitet wird, ohne das ganze log zuzumüllen.

Code Auswählen Erweitern


2015.09.16 18:04:55.413 3: DbLog dbLog: reduceLog requested.
2015.09.16 18:05:00.028 3: DbLog dbLog: reduceLog processing day: 2015-07-20
2015.09.16 18:18:59.499 3: ....
2015.09.16 18:21:58.196 3: DbLog dbLog: reduceLog requested.
2015.09.16 18:22:00.959 3: DbLog dbLog: reduceLog processing day: 2015-07-21
2015.09.16 18:28:19.784 3: DbLog dbLog: reduceLog processing day: 2015-07-22
2015.09.16 18:34:47.237 3: DbLog dbLog: reduceLog processing day: 2015-07-23
...

EDIT: Zu beachten gilt, die Änderungen werden erst in der DB sichtbar wenn der gerade zu bearbeitende Tag abgeschlossen ist!

Gruß
  Claudiu

[C0mmanda]

Wie versprochen hier die Infos zum bereinigen von 1 Tag:

Benutzt wurde deine zweite Version die du gepostet hast, habe noch kein fhem-update gemacht.

- Hardware: Intel NUC DN2820 (2,4GHz Dual-Core, Celeron), 2GB RAM, 60GB SSD (SanDisk), MySQL Datenbank

- Datensätze vor Bereinigung: 96.917
- Datensätze nach Bereinigung: 71.164
- Bereinigte Datensätze: 25.753
- Dauer der Bereinigung: 80 Min. was dann 320 Datensätze die Minute entspricht.

Also deutlich langsamer als deine 1500 Datensätze!
Da du jedoch einen i5 hast (wenn auch nur 1 Core eingesetzt bei den 1500) und ich "nur" einen Celeron wird es wohl daran liegen.

Was ich jedoch merkwürdig finde:

Ich habe set DBlog reduceLog 7 eingegeben.
Gelöscht würden jedoch "nur" folgende Tage:

Code Auswählen Erweitern

2015.09.17 08:52:20 3: DbLog logdb: reduceLog requested.
2015.09.17 08:52:21 3: DbLog logdb: reduceLog processing day: 2015-09-07
2015.09.17 09:33:19 3: DbLog logdb: reduceLog processing day: 2015-09-08



Da wir heute den 17.09. haben hätte er meiner Meinung nach aber zumindest auch die Werte vom 09.09. löschen sollen. (Weil der 17. Tag ja noch nicht abgeschlossen ist).

[rapster]

Oha, ja das ist echt deutlich langsamer, mich würde mal ein Test von einem Raspi User interessieren, ob das auf so einer Platform überhaupt noch vertretbar ist...
Ich denke nicht dass es bei dir an MySQL liegt, vom Bauchgefühl her würde ich sogar behaupten das sollte schneller sein als meine SQLITE?

Da hast du allerdings recht, die Tagesangabe liegt um einen Tag daneben.

Habe in dem Beitrag http://forum.fhem.de/index.php/topic,41089.msg333552.html#msg333552 eine aktualisierte Version (und aktualisiertes Patch-File) angehangen wo dieses Problem nicht mehr auftritt.
Desweiteren wird nun nach Fertigstellung von reduceLog nochmal ein weiterer Logeintrag generiert damit man beim letzten Tag nicht raten muss

Gruß
  Claudiu

[C0mmanda]

Die aktualisierte Version werde ich dann morgen nochmal testen 
Ist das schon soweit dass ich die aktuellste Version durch ein fhem-Update bekomme oder muss ich die 93_DBlog.pm noch manuell aktualisieren?

Ich denke auch nicht dass es an MySQL liegt, eher am NUC.
Laut Munin lag der Load bei max. 1,1, für einen Dual-Core eig. noch OK.
Frage mich gerade ob der NUC evtl. nur 1 Kern genutzt hat ?!
Müsste ich mal recherchieren wie ich das herausbekomme. Munin erweckt irgendwie den Verdacht....


Sollte sich keiner finden der das auf dem Raspi mal testen möchte kann ich das mal machen, brauche aber ein paar Tage dafür.

Ich bin erst vor kurzem vom Raspi 1 auf den Intel NUC umgestiegen und habe somit auf dem Raspi noch die komplette lauffähige fhem-Installation. Müsste nur ebend auf DBLog umstellen.
Auf meinem TV-Server läuft auch eine MySQL-Datenbank die ich dafür nutzen könnte. Ein altes Backup mit massig Datensätzen habe ich auch noch.

Da mir das aber Zeit kostet und auch etwas Aufwand bereitet wäre es toll wenn jemand anderes den Test machen könnte.
Meldet sich keiner in den nächsten 2-3 Tagen gehe ich die Sache an und melde mich dann.

[rapster]

i.M. ist die Verison noch nicht im Fhem-Update, habe Tobias (den Modul-Maintainer) angeschrieben, da stehen soweit ich weiss noch ein paar weitere commits für das Modul aus, er wird sich bestimmt hierzu melden sobald er dazu kommt

Denke da wird sich bestimmt jemand mit Raspi+DbLog finden der das auch nützlich findet und testet, da musst du nicht extra zurückrudern und das Basteln anfangen.
Grundsätzlich funktioniert es ja auf jeder Platform, hat mich nur interessiert ob dem Raspi bei sowas komplett die Puste ausgeht 

Gruß
  Claudiu

[Sunny]

Moin Claudiu,

Danke für Deine Erweiterung! 

Test von Gestern Abend, aber nicht sehr aussagekräftig.
Vorher: countHistory 30188
set myDbLog reduceLog 1 ca. 23:26 gestartet
countHistory 9953 2015-09-16 23:29:12

Nur Leider würde bei verbose=3, bei mir nix geloggt... daher das ca.
Version aus Antwort #4 ( von gestern Zeit ca. 23:20 Uhr )

Leider ohne Anzahl:

Code Auswählen Erweitern

2015.09.17 01:29:40 3: Connecting to database SQLite:dbname=/opt/fhem/fhem.db with user
bis
2015.09.17 02:09:25 3: Connection to db SQLite:dbname=/opt/fhem/fhem.db established for pid 24780

Nutze SQLite, RPi2 mit USB-HDD als root.

Viele Grüße & Danke für Dein Knowhow
Sunny

PS: Werde gleich mal die neue Version kopieren und dann wird kurz nach 00:00 Uhr getestet.. Versuche diesmal die genauen Zeiten zu protokollieren.

[rapster]

Hi Sunny,

das bei dir nichts auf loglevel 3 geloggt wurde ist komisch...

Noch viel seltsamer ist deine Logausgabe welche du gepostet hast.
Die Verbindung zur Datenbank sollte direkt beim Fhem-Start von DbLog hergestellt und gecached werden,
reduceLog baut selber keine neue Verbindung auf, sondern nutzt nur das bestehende Datenbank-Handle.
Kann mir grad nicht erklären warum der Verbindungsaufbau bei dir fast eine Stunde gedauert hat? Das sind allerdings keine Logausgaben von reduceLog...
Hast du Fhem nach einspielen des Moduls neugestartet?

BTW, bei mir hat sich das bereinigen auf jedenfall gelohnt, konnte die DB um über 100 MB pro Monat verkleinern (vacuum).

Gruß
  Claudiu

[Sunny]

Moin Claudiu,

Ja, ich hatte den RPi komplett neugestartet nach "rüber kopieren" der 93_DbLog.pm.
In der Zeit mit den Aufrufen hatte ein at reduceLog gestartet.

Code Auswählen Erweitern

DEF *01:30 set myDbLog reduceLog 1
mit anschliesendem zweitem at rereadcfg.

Code Auswählen Erweitern

DEF *02:00 set myDbLog rereadcfg
Sehe aber gerade, das es wohl eher ein Zufall war.   

Viele Grüße
Sunny

[rapster]

Hab das Modul und den Patch aus Post #4 nochmal um etwas zusätzliches Logging erweitert:

Code Auswählen Erweitern


2015.09.17 19:00:41.359 3: DbLog dbLog: reduceLog requested.
2015.09.17 19:00:42.137 3: DbLog dbLog: reduceLog deleting 9264 records of day: 2015-08-20
2015.09.17 19:01:45.694 3: DbLog dbLog: reduceLog deleting 13551 records of day: 2015-08-21
2015.09.17 19:03:45.070 3: DbLog dbLog: reduceLog executed. Rows processed: 129797, deleted: 22815

Desweiteren wird nach Ausführung das neue Reading "lastReduceLogResult" aktualisiert (siehe Anhang).

@Sunny,
für was das rereadcfg? Das haut natürlich erstmal alles durcheinander Der Befehl ist meiner Meinung nach sowieso nicht so optimal, und möglichst zu vermeiden.

Gruß
  Claudiu