DBLog - Historische Werte ausdünnen

Begonnen von C0mmanda, 14 September 2015, 18:38:21

Vorheriges Thema - Nächstes Thema

rapster

Hmm, da laufen auf jedenfall immer noch reichlich MB in den Perl-Prozess rein, sowohl bei SQLITE als auch bei Mysql.
Den Mysql Dienst selber scheint das ganze allerdings nicht weiter zu stören...

Könnte also immer noch sein dass eine große Bereinigung bei Systemen mit (zu) wenig RAM & SWAP die Stabilität beeinflussen kann.

Das einzige was mir dazu einfällt ist die Verarbeitung in kleinere Häppchen aufzuteilen, damit es jenige die es betrifft mit einem zusätzlichen Argument "separate=<days>" steuern können.
Mir fällt gerade nichts weiter ein wie ich ansonsten ram schonender vorgehen soll :-\

Werde mir mal Gedanken drüber machen.
Bitte bescheid geben falls bei jemanden mit der aktuellen Version der fhem-prozess sterben sollte.

Gruß
  Claudiu


Sailor

#106
Zitat von: rapster am 26 September 2015, 16:11:52
super, dann hat das geklappt!
Müsste denke ich jetzt auch bei @Sailor funktionieren :)

Leider nein...  :(

Habe seit dem 2015-02-09 13:29:49 insgesammt 3,28GB an Daten gesammelt.

Ich denke das wird nix mehr auf meinem kleinen RasPi... So wie es aussieht werde ich wohl einen Schnitt mit einer neuen Tabelle machen müssen und ab dann regelmaessig zum Monatsende einen ReduceLog fahren müssen.  :(

Vielleicht auch einen Gelegenheit auf den RasPi2 mit 1GB RAM umzusteigen...  ;D

Es sein denn ihr habt noch Ideen...

Zur Info: Ich habe 13 Raum-Thermostate, 15 Heizungsventile, einen Gaszähler, einen Stromzaehler und einen km200.
Die schreiben alle 2,5 Minuten eifrig Daten.

Gruss
    Sailor
******************************
Man wird immer besser...

rapster

#107
Hast du es probiert mit wenigen Tagen auf einmal, Sailor?

Du könntest das auch einmal mit einer Schleife erledingen, die z.b. immer nur 2 Tage auf einmal durchführt:

for (my $i = 500 ; $i > 31; $i = $i-2) {
    fhem("set <dblog> reduceLog $i average");
}


Gruß
  Claudiu

Sailor

#108
Zitat von: rapster am 28 September 2015, 12:55:37
Hast du es probiert mit wenigen Tagen auf einmal, Sailor?

Du könntest das auch einmal mit einer Schleife erledingen, die z.b. immer nur 2 Tage auf einmal durchführt:

for (my $i = 500 ; $i > 31; $i = $i-2) {
    fhem("set <dblog> reduceLog $i average");
}


Gruß
  Claudiu

Hallo Claudiu

Die Syntax stimmte in deinem Beispiel für das Kommandozeilenfenster nicht ganz...

Ich habe es mit

{for (my $i = 500 ;; $i > 31;; $i = $i-2) {fhem("set myDbLog reduceLog $i average exclude=.*_Window,.*_Door");;};;}

probiert.

Das Ergebnis im Log-File:


2015.09.28 14:06:11 3: DbLog myDbLog: reduceLog requested with DAYS=500, AVERAGE=HOUR
2015.09.28 14:22:47 3: DbLog myDbLog: reduceLog executed. Rows processed: 0, deleted: 0, updated: 0, time: 996.00sec
2015.09.28 14:22:48 3: set myDbLog reduceLog 500 average exclude=.*_Window,.*_Door : reduceLog executed. Rows processed: 0, deleted: 0, updated: 0, time: 996.00sec
2015.09.28 14:22:48 3: DbLog myDbLog: reduceLog requested with DAYS=498, AVERAGE=HOUR
2015.09.28 14:39:54 3: DbLog myDbLog: reduceLog executed. Rows processed: 0, deleted: 0, updated: 0, time: 1026.00sec
2015.09.28 14:39:55 3: set myDbLog reduceLog 498 average exclude=.*_Window,.*_Door : reduceLog executed. Rows processed: 0, deleted: 0, updated: 0, time: 1026.00sec
2015.09.28 14:39:55 3: DbLog myDbLog: reduceLog requested with DAYS=496, AVERAGE=HOUR



Na das kann dauern... Wird Zeit fürn Kaffee  ::)

Gruß
    Sailor
******************************
Man wird immer besser...

stromer-12

Bei deiner Zeit scheint kein Index zu greifen.
Bei meinen CT kommt aktuell:
fhem> set myDbLog reduceLog 500 average
reduceLog executed. Rows processed: 0, deleted: 0, updated: 0, time: 0.00sec
FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

nesges

Zitat von: rapster am 26 September 2015, 01:56:52
@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?

Ich würde gerne Staffeln: Die letzten 24 Stunden volle Auflösung; die letzten 31 Tage minütlicher Durchschnitt; älter stündlicher Durchschnitt

Die "volle Auflösung" heisst bei einigen meiner Devices, dass 30-50 Werte pro Minute geloggt werden. Ich möchte das nicht unterbinden, da ich die sekundengenaue Liveanzeige behalten möchte, aber in den Plots  ist diese Genauigkeit einfach nicht notwendig, von daher können die Werte raus. Ich erhoffe mir durch die Ausdünnung einen kleinen Performancegewinn, sehe das Feature aber auch nur als "nice to have" - bin auch ohne schon sehr zufrieden :-)

PS: Vielleicht kann der Thread auch mal in ein passenderes Subforum verschoben werden

Sailor

Zitat von: stromer-12 am 28 September 2015, 14:33:17
Bei deiner Zeit scheint kein Index zu greifen.
Bei meinen CT kommt aktuell:
fhem> set myDbLog reduceLog 500 average
reduceLog executed. Rows processed: 0, deleted: 0, updated: 0, time: 0.00sec


Ja, war mein Fehler... Wie ich oben bereits schrieb fängt meine fhem.db erst im Februar diesen Jahres an...

Das heisst, das dauert noch bis der an die 180 Tage kommt.  ???

Gruss
    Sailor
******************************
Man wird immer besser...

stromer-12

Meine fhem.db fängt am 30. April letzten Jahres an.

Gesendet von meinem GT-I9295

FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

frank

Zitat von: nesges am 28 September 2015, 14:38:53
Ich würde gerne Staffeln: Die letzten 24 Stunden volle Auflösung; die letzten 31 Tage minütlicher Durchschnitt; älter stündlicher Durchschnitt

Die "volle Auflösung" heisst bei einigen meiner Devices, dass 30-50 Werte pro Minute geloggt werden. Ich möchte das nicht unterbinden, da ich die sekundengenaue Liveanzeige behalten möchte, aber in den Plots  ist diese Genauigkeit einfach nicht notwendig, von daher können die Werte raus. Ich erhoffe mir durch die Ausdünnung einen kleinen Performancegewinn, sehe das Feature aber auch nur als "nice to have" - bin auch ohne schon sehr zufrieden :-)

PS: Vielleicht kann der Thread auch mal in ein passenderes Subforum verschoben werden
da hätte ich mir zum loggen schon mal ein extra userreading angelegt, dass dann entsprechend weniger events erzeugt (event-aggregator)
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

rapster

#114
Zitat von: Sailor am 28 September 2015, 14:50:52
Ja, war mein Fehler... Wie ich oben bereits schrieb fängt meine fhem.db erst im Februar diesen Jahres an...

Das heisst, das dauert noch bis der an die 180 Tage kommt.  ???
Oha ja, die "500" waren einfach mal Beispielhaft, am besten nochmal abbrechen mit mit ~180 nochmals starten

Gruß
  Claudiu

EDIT:
Allerdings hat stromer recht, diese Abfrage dauert schon verdammt lange dafür das 0 Zeilen zurückgeliefert werden... Hmm.... Kommt evtl. von der Gesamtgröße der DB von ~4GB ?

rapster

Zitat von: nesges am 28 September 2015, 14:38:53
Die "volle Auflösung" heisst bei einigen meiner Devices, dass 30-50 Werte pro Minute geloggt werden. Ich möchte das nicht unterbinden, da ich die sekundengenaue Liveanzeige behalten möchte, aber in den Plots  ist diese Genauigkeit einfach nicht notwendig, von daher können die Werte raus.

Benötigst du dann in DbLog überhaupt die volle Auflösung, oder benötigst du nur so häufig Fhem-Events?

Falls du nur auf die häufigen Events aus bist, würde ich das Reading mit DbLogExclude erstmal komplett herausnehmen, und manuell mit einem at das Reading loggen.
Zum manuellen Loggen von Readings hatte ich mal hier einen Lösungsvorschlag gepostet: http://forum.fhem.de/index.php/topic,38685.msg312484.html#msg312484

Gruß
  Claudiu

mattt

Hallo,

ein Vorschlag: wie wäre es wenn es bei deleteOldDays eine Sicherheitsabfrage oder ähnlich gäbe, um unabsichtliches Löschen zu verhindern?

z.B. deleteOldDays 30 yes

Ihr dürft raten was mir passiert ist...
Grüße

rapster

Wie wäre es,
1. wenn du nicht irgendeinen Thread kapern würdest
2. selber etwas Sorgfalt walten lässt (das impliziert auch das erstellen eines Backups)
?
Das erinnert mich an meinen 1. Lehrjahrs Azubi vor einigen Jahren, "Ups, 'rm -rf /' löscht ja tatsächlich alles..."

Gruß
  Claudiu

Sailor

Ein herzerfirschendes "Moin" vom "Hintern-Deich" vorweg!

Also ich habe jetzt mal den Schnitt gemacht

set myDbLog deleteOldDays 120

ergibt bei folgender Abfrage

set myDbLog userCommand select min(timestamp) from history;

folgenden Output:
Vorher:   2015-02-09 13:29:49
Nachher: 2015-06-02 04:31:27

Die Datenbankgroesse ist unveraendert auf 3,8 GB!

Wie geht das denn?  :o

Muss ich die db noch "purgen"?  ???

Gruss
    Sailor
******************************
Man wird immer besser...

rapster

Moin Sailor ;)

Was hast du denn für eine Datenbank, SQLITE?

Bei SQLITE zumindest musst du, falls du eine kleinere Datei willst, noch manuell VACUUM; ausführen.

Gruß
  Claudiu