DBLog - Historische Werte ausdünnen

[rapster]

Hallo Sailor,

100% CPU  ist auf jedenfall OK,  500MB RAM ist zwar etwas wenig, sollte aber hoffe ich trotzdem alles gut gehen

Mach mal ein  "tail -f /opt/fhem/fhem.log" auf den Commandline und schau mal was er gerade tut....

Gruß
  Claudiu

[Sailor]

100% CPU  ist auf jedenfall OK,  500MB RAM ist zwar etwas wenig, sollte aber hoffe ich trotzdem alles gut gehen

Mach mal ein  "tail -f /opt/fhem/fhem.log" auf den Commandline und schau mal was er gerade tut....

Schau mer mal...

Code Auswählen Erweitern

2015.09.24 14:41:09 3: DbLog myDbLog: reduceLog requested.

Da muss auf alle Faelle 'ne Forke her! 

Gruss
   Sailor

[Sailor]

100% CPU  ist auf jedenfall OK,  500MB RAM ist zwar etwas wenig, sollte aber hoffe ich trotzdem alles gut gehen

Mach mal ein  "tail -f /opt/fhem/fhem.log" auf den Commandline und schau mal was er gerade tut....

Schau mer mal...

Code Auswählen Erweitern


2015.09.24 14:41:09 3: DbLog myDbLog: reduceLog requested.
2015.09.24 14:57:08 3: DbLog myDbLog: reduceLog executed. Rows processed: 0, deleted: 0, updated: 0


Naechster Versuch:

Code Auswählen Erweitern

set myDbLog  reduceLog  150 average

Da muss auf alle Faelle 'ne Forke her! 

Gruss
   Sailor

[rapster]

Oha, ja bei dir ist er immer noch mit dem Einlesen der DB beschäftigt.
reduceLog liest i.M. die kompletten zu verarbeitenden Tage zuvor in den RAM ein,  allerdings ist bei dir grad nicht viel RAM verfügbar... 

Wieviel Tage umfasst deine DB?

Du kannst es nur mal mit mehr <days> versuchen, damit nicht so viel auf einmal eingelesen werden muss.
Oder mal warten... Bin gespannt!

Das auslagern in einen eigenen Prozess ist schwierig, da SQLITE bei vielen Usern keine mehrfachen Verbindungen unterstützt.

Gruß
  Claudiu

EDIT:
sehe gerade bei 360 kam kein Ergebniss zurück, anscheinend hat die DB noch nicht soviele Tage gespeichert, und die dauer ist auf die select-Abfrage zurückzuführen.
Was kam bei 150 raus?

[Sailor]

Oha, ja bei dir ist er immer noch mit dem Einlesen der DB beschäftigt.
reduceLog liest i.M. die kompletten zu verarbeitenden Tage zuvor in den RAM ein,  allerdings ist bei dir grad nicht viel RAM verfügbar... 

Wieviel Tage umfasst deine DB?

Du kannst es nur mal mit mehr <days> versuchen, damit nicht so viel auf einmal eingelesen werden muss.
Oder mal warten... Bin gespannt!

Ist halt nur ein RasPI-B und der fhem-Prozess ist wieder abgeschmiert.

Code Auswählen Erweitern


set myDbLog  reduceLog  360 average
2015.09.24 14:41:09 3: DbLog myDbLog: reduceLog requested.
2015.09.24 14:57:08 3: DbLog myDbLog: reduceLog executed. Rows processed: 0, deleted: 0, updated: 0


Code Auswählen Erweitern


set myDbLog  reduceLog  150 average
2015.09.24 15:01:07 3: DbLog myDbLog: reduceLog requested.

Absturz
Vorher war sogar das SWAP-file randvoll...

Hmmm

Wie bekomme ich nochmal die Anzahl der gespeicherten Tage raus?

Gruss
    Sailor

[rapster]

Vorher war sogar das SWAP-file randvoll...

Das ist auch das Problem, reduceLog versucht die Daten in den RAM einzulesen, falls der nicht ausreicht wird das SWAP-File herangezogen, dieses hat allerdings auf deinem System nur bescheidene 100 MB

Den ältestens Eintrag in der DB bekommst du mit diesem SQL Command:

Code Auswählen Erweitern

select * from history ORDER BY TIMESTAMP ASC LIMIT 1;

Gruß
  Claudiu

[nesges]

Wie bekomme ich nochmal die Anzahl der gespeicherten Tage raus?

Code Auswählen Erweitern

select count(distinct(date_format(timestamp,"%Y-%m-%d"))) from history;

Wenn du nur den ersten gelogten Timestamp wissen möchtest:

Code Auswählen Erweitern

select min(timestamp) from history;

[th1984]

Ich habe mal eine generelle Frage zu diesem Projekt: Werden hier einfach alle geloggten Werte auf einen in der Stunde gekürzt? Das wäre für mein Vorhaben etwas unpassend. Zwar habe ich auch Daten die ich ausdünnen möchte, eben diese Temperaturverläufe usw, allerdings habe ich auch Daten die ich komplett speichern möchte. In meinem Fall die Ein und Aus Werte der Brunnenpumpe. Oder aber auch der Fenster.

[Sailor]

Ich habe mal eine generelle Frage zu diesem Projekt: Werden hier einfach alle geloggten Werte auf einen in der Stunde gekürzt? Das wäre für mein Vorhaben etwas unpassend. Zwar habe ich auch Daten die ich ausdünnen möchte, eben diese Temperaturverläufe usw, allerdings habe ich auch Daten die ich komplett speichern möchte. In meinem Fall die Ein und Aus Werte der Brunnenpumpe. Oder aber auch der Fenster.

Stimmt, daran habe ich auch noch nicht nachgedacht.
Wenn ich das Fenster einmal am Tag geöffnet habe, kann der Average nicht "Halb geöffnet" sein. 

Gruss
   Sailor

[rapster]

Ich habe mal eine generelle Frage zu diesem Projekt: Werden hier einfach alle geloggten Werte auf einen in der Stunde gekürzt? Das wäre für mein Vorhaben etwas unpassend. Zwar habe ich auch Daten die ich ausdünnen möchte, eben diese Temperaturverläufe usw, allerdings habe ich auch Daten die ich komplett speichern möchte. In meinem Fall die Ein und Aus Werte der Brunnenpumpe. Oder aber auch der Fenster.

Ja, daran hab ich zwar auch am Anfang schon gedacht.
Alphanumerische Zeichen werden i.M. immer auf den ersten Eintrag pro Stunde reduziert (auch bei average=day).
Bei mir hat es dadurch z.B. die Fensterzustände, oder on/off Werte anderer Aktoren in den Plots zwar etwas ungenauer gemacht, aber empfand es jetzt als ganz O.K.

Ich könnte noch einen FILTER einbauen, um z.B. komplett alphanumerisch auszlassen, oder um device/reading kombinationen auszuschließen, würde das helfen?

Gruß
  Claudiu

[th1984]

Hallo Claudiu,

Ich könnte noch einen FILTER einbauen, um z.B. komplett alphanumerisch auszlassen, oder um device/reading kombinationen auszuschließen, würde das helfen?

Das wäre super wenn man ein Opt-Out machen könnte. Ich denke das wäre auch die Variante die besser ist, als wenn man alphanumerische Zeichen komplett auslässt. Ein anderer möchte womöglich genau diese reduziert.

[Pyromane]

Ich könnte noch einen FILTER einbauen, um z.B. komplett alphanumerisch auszlassen, oder um device/reading kombinationen auszuschließen, würde das helfen?

Evtl. ein Attribute ähnlich dem "DbLogExclude" mit dem man Ausnahmen von deiner Erweiterung festlegen kann.

[nesges]

Für mich würde auch eine Option average=min zur Reduzierung auf minütlichen Durchschnittswert Sinn ergeben. Da ich insbesondere dewpoint nicht verbieten möchte im Sekundentakt Events zu erzeugen (da ich  eine sekundengenaue Anzeige behalten möchte), die Vielzahl der Werte aber später in den Plots gar nicht mehr benötige - bzw. sogar störend finde, da sie die Plots ausbremsen. Die Detailstufe average=hour ist mir für die tagesaktuellen Werte dann aber auch wieder zu grob.

[rapster]

Hallo Zusammen,

als letztes Argument kann nun "EXCLUDE=deviceRegExp1:readingRegExp1,deviceRegExp2:readingRegExp2,...." angegeben werden um device:reading Kombinationen (mehrere durch Komma getrennt) von reduceLog auszuschließen.
z.B. "set <dblog> reduceLog <days> average exclude=haustuer:state,katzenkl.*:.*,.*:sabotageError"

Die einzelnen RegEx Pattern müssen immer aufs gesamte device und reading matchen, nicht nur teile davon!

@nesges
average reicht dir hier nicht? Damit hast du dann 24 Werte pro Tag...
Verstehe ehrlich gesagt nicht für was du in den Plots bei historischen Werten was genaueres benötigst als einen Wert pro Stunde?

@Sailor
Habe die Funktion nochmal bzql. der Datenverarbeitung umgebaut.
Der RAM-Verbrauch sollte nun (hoffe ich) nicht mehr auffallen.
Kannst du das bitte mal testen und bescheid geben ob dein FHEM nun bei einer größeren Abfrage durchhält?


Die Aktualisierte Version ist wieder in Post #28 zu finden => http://forum.fhem.de/index.php/topic,41089.msg334617.html#msg334617

Gruß
  Claudiu

[Sunny]

Moin Claudiu,

durch Deine Version von Heute morgen hat mein BPi es erstmals geschafft, eine Test DB mit 596 MB (625.651.712 Bytes) ohne das FHEM "weggeschossen" wird, in einem "Rutsch" zu verarbeiten. 

Code Auswählen Erweitern


2015.09.26 03:44:17.051 3: DbLog myDbLog: reduceLog requested.

2015.09.26 04:01:01.385 3: DbLog myDbLog: reduceLog deleting 162415 records of day: 2015-09-02
2015.09.26 04:05:33.640 3: DbLog myDbLog: reduceLog executed. Rows processed: 3096278, deleted: 2653331

2015.09.26 04:28:22.534 3: DbLog myDbLog: reduceLog requested.
2015.09.26 04:28:36.617 3: DbLog myDbLog: reduceLog (daily-average) updating 25, deleting 328 records of day: 2015-05-30
2015.09.26 04:28:36.859 3: DbLog myDbLog: reduceLog (daily-average) updating 25, deleting 547 records of day: 2015-05-31
2015.09.26 04:28:37.186 3: DbLog myDbLog: reduceLog (daily-average) updating 55, deleting 510 records of day: 2015-06-01
2015.09.26 04:28:37.718 3: DbLog myDbLog: reduceLog (daily-average) updating 68, deleting 1072 records of day: 2015-06-02

2015.09.26 04:31:06.732 3: DbLog myDbLog: reduceLog (hourly-average) updating 18 records of day: 2015-09-02
2015.09.26 04:31:11.586 3: DbLog myDbLog: reduceLog executed. Rows processed: 432965, deleted: 287404, updated: 20187

Schade, das Du nicht den Sinn siehst, für z.B. Temperatur-Daten die Möglichkeit für 1 Minute, 5 Minuten oder 15 Minuten Intervalle "ein zubauen".   

( Ich weiß, allerdings auch nicht, wie viel Arbeit dahinter steckt, bzw. ob dies überhaupt Möglich ist.. )

Ich würde mich sehr darüber freuen...

Aber wenn es nicht geht, ist es auch so Klasse, was Du da "gebaut" hast. Und andere daran Teilhaben lässt! ( sehr  )

Vielen Dank & viele Grüße
Sunny