DBLog - Historische Werte ausdünnen

[rapster]

Die Funktion ist IMHO ohne non-blocking in Produktivsystemen sinnlos.

Sehe ich nicht so, zumindest nicht völlig sinnlos, reduceLog läuft bei mir jede Nacht mit DAYS=21 und AVERAGE=Hour:

Code Auswählen Erweitern

2016.07.01 04:01:00.000 3: DbLog dbLog: reduceLog requested with DAYS=21, AVERAGE=HOUR
2016.07.01 04:01:22.307 3: DbLog dbLog: reduceLog deleting 89596 records of day: 2016-06-09
2016.07.01 04:01:23.701 3: DbLog dbLog: reduceLog (hourly-average) updating 2602 records of day: 2016-06-09
2016.07.01 04:01:23.984 3: DbLog dbLog: reduceLog deleting 9087 records of day: 2016-06-10
2016.07.01 04:01:24.392 3: DbLog dbLog: reduceLog (hourly-average) updating 252 records of day: 2016-06-10
2016.07.01 04:01:24.416 3: DbLog dbLog: reduceLog executed. Rows processed: 1428754, deleted: 98683, updated: 2854, time: 24.42sec


Das blockiert mein fhem um die 25 Sekunden jede Nacht, nehme ich lieber in Kauf als alle meine alten Daten komplett wegschmeißen zu müssen.

Edit: Log aus leerem dbLog gepostet

[marvin78]

Alles über eine Sekunde ist in einem Produktivsystem zu viel. Es ist ja nicht so, als könnte man die Datenbank nicht auf andere Weise ausdünnen. Warum so eine Funktion nicht non-blocking einzubauen ist, verstehe ich nicht ganz, ich gebe aber zu, dass ich mich auch nicht im Detail mit DBLog beschäftigt habe. Das soll keine Kritik sein, nur eine Feststellung.

[chris1284]

tja, die 28 sekunden stillstand können schon ärgerlich sein (fensteroffenmeldung, wassermeldung, regenmeldung ), in der zeit kann nichts geschaltet oder gelogged werden (gut wenn man weis sum 4 uhr nachts muss ich nichts schalten, bricht niemand ein oder wird kein feuer ausbrechen  sollte es nicht tragisch sein


was ich sagen will: ich finde es auch einfach unschön dass fhem blockiert wird durch sowas. ich glaube zwar auch nicht das es in einem produktivsystem wenn nur 20 sekunden sind was ausmacht


EDIT bei mir sinds 10 sek bei 30 tagen

reduceLog executed. Rows processed: 76568, deleted: 61060, time: 11.00sec

[rapster]

Die Frage die sich mir stellt ist nicht warum fhem es nicht kann, sondern wie sich die dahinter liegende DB verhält wenn es auf nonblocking umgebaut werden würde.

Was macht so eine SQLite DB z.B. wenn reduceLog nonblocking eine zweite Verbindung zur DB aufbaut, und am anderen Ende DbLog fleißig weiter Temperaturwerte usw. loggt?
Wie verhält sich da Postgres, MySql, Oracle usw...

Wenn man einfach eine zweite Fhem-Instanz mit der gleichen DbLog.conf startet, und hier reduceLog aufruft, sollte es doch genau das tun, nonBlocking reduceLog ausführen.
Müsste ich mal probieren ob es mir dann meine SQLite zerreisst

[KernSani]

Ich habe gestern über die sqlite Konsole Daten gelöscht während FHEM lief... Hat funktioniert, ich weiß aber nicht, ob einzelne Daten verloren gingen und FHEM war währenddessen kaum bedienbar.

[justme1968]

sqlite ist explizit nicht multithreaded und sollte auch nicht von mehr als einem prozess schreibend verwendet werden. du kannst dir die komplette db zerschießen.

die anderen 'richtigen' datenbanken können natürlich mehr als eine verbindung aber je nach db und sql anweisung wird bei einem delete automatisch mehr oder weniger der db gelockt (zeilen, tabellen oder doch alles) und die anderen prozesse warten mehr oder weniger lange. je besser die db um so granularer ist das locking und desto weniger muss gewartet werden.

das reine löschen ist auch nur ein teil der aufräumarbeit. der platz muss auch zur wiederverwendung freigegeben/bereitgestellt werden. dazu dienen regelmäßige (automatische) vacum läufe. auch diese blockieren die db mehr oder weniger lange.

je nach anwendung ist es besser öfter kleine häppchen löschen und zu reorganisieren als seltener und dafür mehr.

schnellere platten und die richtige db struktur helfen auch.

noch besser als aufräumen ist erst garnicht loggen.

gruss
  andre

[KernSani]

Hi Andre,

VACUUM ist der nächste Schritt, dann aber ohne laufenden FHEM;-) Habe kürzlich DBLog von exlude auf include umgestellt und irgenwie muss ich jetzt den alten Schotter loswerden ReduceLog in 5-Tages-Häppchen macht nicht wirklich Spaß;-)

[chris1284]

vaccum + laufendes fhem geht problemlos (hat mir noch nichts zerschossen) da sqlite die optimierung nicht in der original database macht, sondenr in einer temporären kopie (auf die greift fhem garnicht zu ) und dann nur kurz das alte file durch das neu ersetzt. es könnte ein problem geben wenn fhem gerade eine transaction durchführt (dann würde vacuum nicht starten). währen vacuum läuft kann fhem eh nicht in die db schreiben weil das modul fhem (und so das speichern von readings ) blockiert (bitte korrigireren wenn falsche annahme!!!!).

https://www.sqlite.org/lang_vacuum.html

[DerFrickler]

kann man den Vacuum Befehl auch von FHEM automatisch absetzen? oder geht das nur direkt über die shell?

[Pyromane]

kann man den Vacuum Befehl auch von FHEM automatisch absetzen? oder geht das nur direkt über die shell?

Damit sollte sich Vacuum aus FHEM aufrufen lassen:

Code Auswählen Erweitern

set <name> userCommand "VACUUM history"

Und das ganze jetzt noch per AT:

Code Auswählen Erweitern

define DBvacuum at *02:00:00 set <name> userCommand "VACUUM history"
Und schon sollte das jeden Tag um 2 Uhr ausgeführt werden.

[amithlon]

Hallo,

noch besser als aufräumen ist erst garnicht loggen.

dem kann ich nur 100% zustimmen, hat mich auch etwas Überlegung und Zeit gekostet, jetzt wird aber nur noch geloggt, was ich haben will, in sinnvollen Zeitabständen für einen Plot usw. und ich überlege mir jedes neue Logging 3x ob und wofür ich es wirklich brauche.

Gruß aus Berlin
Michael

[rapster]

Ich finde mehrere Loginstanzen oftmals praktisch.

Eine DB in der einfach alles geloggt wird, allerdings nur für wenige Tage verbleibt.
Dadurch lässt sich einfacher etwas neues Entwickeln, oder auf Ereignisse reagieren, da man zumindest von den letzten Tage einfach zu allen Werten Logdaten vorliegen hat.

Eine zweite DB in der nur geloggt wird was auch benötigt/geplottet usw. wird.

[DerFrickler]

Das mit zwei Datenbanken macht durchaus Sinn... die meisten Daten können nach 30 Tagen verworfen werden, aber z.B. Zählerstände würde ich gerne zu Vergleichszwecken 2 Jahre aufbewahren. Nur wie verteile ich dann die jeweiligen Readings auf die DBs? Bisher habe ich alles über DbLogInclude geregelt. Die Einträge für die DB mit Zählerstände kann man ja durch

/opt/fhem/DBlog.conf .*:(meterReading_kWh|meterReading_m3|energy_kWh).*

eingrenzen. Nur gibt es eine Möglichkeit die Werte aus der allgemeinen DB herauszuhalten?

[amithlon]

Hallo,

Du wirfst eine interessante Frage auf.
Ich filtere in define logdb DbLog ./db.conf (RFM12.*|BME280.*|E3k.*|PIR_S_.:.*|Tierpark:.*unnamed.*) nur die Device-Gruppen, die ich überhaupt haben will.
Die exludes der uninteressanten Werte erfolgt dann bei jedem Device über das Attribut:
DbLogExclude .*state.*|.*consumption.*|.*powerMax.*

DbLogInclude gibt es ja auch noch, allerdings müte man dann wohl im define von DbLog erstmal alles verbieten?

Und jetzt kommt Deine Frage, die auch meine sein könnte: kann ich einem z.B. Device per DbLogInclude sagen, was er wohin loggen soll?
Das wäre dann eine praktische Lösung um z.B. getrennte Tabellen mit ausgewählten Readings zu füllen.

Gruß aus Berlin
Michael

[KernSani]

DbLogInclude gibt es ja auch noch, allerdings müte man dann wohl im define von DbLog erstmal alles verbieten?

Die Frage kann ich beantworten: Nein. Wenn in der DEF des DBLogs, DbLogSelectionMode auf Include steht, wird nur geloggt, wenn das device ein DBLogInclude-Attribut hat (in dem dann die zu loggenden readings definiert wird).
Ich habe allerdings nur ein DBLog und keine Ahnung, ob ich irgendwie in ein anderes loggen könnte... rein logisch sollte es aber möglich sein, ein Log mit DbLogSelectionMode = Include und eines mit Exclude zu definieren and dann gezielt die readings in eines zu includen und aus dem anderen zu excluden... was aber viel Pflegeaufwand erfordert....

Grüße,

Oli