DBLog - Historische Werte ausdünnen

stromer-12 · 22 September 2015, 22:23:19

So, habe noch den INDEX angelegt, ich musste mich aber erst einmal mit einer Fehlermeldung beim anlegen des Index auseinandersetzen.
Aber jetzt ist die Abfrage richtig flott geworden.
War vorher noch für eine Abfrage 5 Minuten notwendig sind es jetzt nur noch Bruchteile einer Sekunde.

Code Auswählen

2015.09.22 21:44:47 5: Cmd: >set myDbLog reduceLog 500 average< 
2015.09.22 21:48:43 5: Triggering myDbLog (1 changes) 
2015.09.22 21:48:43 5: Notify loop for myDbLog lastReduceLogResult: Rows processed: 126141, deleted: 106515, updated: 7962

Edit: 20 Tage Berechnet:

Code Auswählen

fhem> set myDbLog reduceLog 450 average
2015.09.22 23:55:48 3: DbLog myDbLog: reduceLog executed. Rows processed: 1022592, deleted: 835458, updated: 40651
2015.09.22 23:55:52 1: Perfmon: possible freeze starting at 23:24:51, delay is 1861.974

stromer-12 · 23 September 2015, 09:24:30

So, habe mal ein

Code Auswählen

fhem>set myDbLog reduceLog 400 average
Da hat er 50 Tage bearbeitet und

Code Auswählen

2015.09.23 07:37:50 3: DbLog myDbLog: reduceLog requested.
2015.09.23 08:50:55 3: DbLog myDbLog: reduceLog executed. Rows processed: 2383469, deleted: 2009049, updated: 99942
2015.09.23 08:51:10 1: Perfmon: possible freeze starting at 07:37:51, delay is 4399.717

Ein wiederholter Aufruf bringt folgende Zeilen

Code Auswählen

2015.09.23 09:08:41 3: DbLog myDbLog: reduceLog requested.
2015.09.23 09:09:38 3: DbLog myDbLog: reduceLog executed. Rows processed: 374410, deleted: 0, updated: 0
2015.09.23 09:09:40 1: Perfmon: possible freeze starting at 09:08:42, delay is 58.779

Bei jedem Aufruf war fhem blockiert.

Ich habe jetzt ca. 105 Tage mit average behandelt und knapp 4000000 Datensätze dabei gelöscht.

rapster · 23 September 2015, 14:04:40

Hallo Stromer,

das war ja mal eine größere Bereinigung

Hast du zufällig den RAM, SWAP, CPU Verbrauch währenddessen beobachtet? (reduceLog liest i.M. die zu verarbeitenden Daten vor Beginn komplett in den RAM ein)

Gruß
Claudiu

stromer-12 · 23 September 2015, 14:23:17

Mysql lauft hier mit einer InnoDb Engine.
CPU lag so bei 110%
Swap stieg von 2MB auf 116MB an.
Wait lag so bei 3%

Gesendet von meinem GT-I9295

th1984 · 23 September 2015, 15:30:58

Hallo Stromer,

da habe ich direkt eine Frage: Ich plage mich auch gerade mit der Fehlermeldung beim Anlegen des Index. Wie hast du es behoben, ich komm da gerade nicht weiter.

Ich bin jedenfalls schon gespannt wie schnell das Teil auf meinem Raspberry mit dem Index dann laufen wird...

Danke und vg

stromer-12 · 23 September 2015, 19:29:05

Der Fehler ist etwas irritierent, da angeblich die Datenbank voll ist.
Es liegt am tmp-Verszeichnis, welches beim Cubie in der RAM liegt und maximal 1GB Platz hat.
Ich habe ein tmp-Verzeichnis mit entsprechenden Berechtigungen auf meiner SSD angelegt und in der my.cnf angepasst.

von

Code Auswählen

tmpdir = /tmp
nach

Code Auswählen

tmpdir = /opt/tmp

Nach dem erstellen des Index habe ich es wieder zurückgeändert.

Bei den 35,5Millionen Datensätzen hat es knapp 39Minuten gedauert.

Code Auswählen

mysql> CREATE INDEX index_reduceLog ON history (TIMESTAMP,DEVICE,EVENT);
Query OK, 0 rows affected, 2 warnings (38 min 34.58 sec)
Records: 0  Duplicates: 0  Warnings: 2

rapster · 23 September 2015, 22:30:39

Hallo Zusammen,

keine Ahnung was mich dazu geritten hat einen eigenen INDEX zu erstellen...

Hab die Funktion nochmals umgebaut damit KEIN zusätzlicher INDEX mehr benötigt wird !
Es wird nun der standard 'Search_Idx' INDEX welcher durch die *.sql Dateien für die DbLog Erstellung erstellt wird verwendet.
Dieser sollte bereits bei jedem vorhanden sein!

Vorsichtshalber kann man kontrollieren ob der 'Search_Idx' INDEX über die Columns (DEVICE, READING, TIMESTAMP) vorhanden ist.

Code Auswählen

sqlite> PRAGMA INDEX_LIST('history');
-----
mysql> SHOW INDEXES FROM history;

Die Verarbeitungszeit sollte hierdurch (wenn überhaupt) nur minimal in Mitleidenschaft gezogen werden, der RAM Ressourcenverbrauch sollte sich allerdings verringert haben.

Für Leute die den 'index_ruduceLog' erstellt haben, dieser kann mit folgendem Befehl wieder gelöscht werden. (Der belegte Speicherplatz wird hierdurch ebenfalls wieder freigegeben.)

Code Auswählen


sqlite> DROP INDEX index_reduceLog;
----
mysql> DROP INDEX index_reduceLog ON history;

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

Werde bei Gelegenheit noch ein weiteres Feature einbauen, welches insbesondere Leuten wie @stromer-12 zugute kommt welche bereits eine relativ große DB haben.
Hierdurch soll dann der Anfangsdelay deutlich verkürzt werden, indem Daten welche bereits verarbeitet wurden nicht erneut geprüft werden.

Gruß
Claudiu

stromer-12 · 23 September 2015, 22:44:11

Habe gerade noch mal nach dem RAM Bedarf meiner Fheminstanz geschaut, der lag jetzt noch 850MB.

rapster · 23 September 2015, 22:52:00

Bevor ich es zitiere

=> http://learn.perl.org/faq/perlfaq3.html#How-can-I-free-an-array-or-hash-so-my-program-shrinks

Kurz gesagt, der durch reduceLog verwendete Speicher wird intern für den Fhem-Prozess wieder freigegeben, für das OS unter umständen allerdings nicht. (erst nach einem Fhem-restart.)

Durch das geplante Feature was ich vorhin erwähnte sollte aber zukünftig zumindest der RAM-Verbrauch der Funktion deutlich reduziert werden, da nurnoch Daten aus der DB gelesen werden, welche noch nicht verarbeitet wurden.

Gruß
Claudiu

Sailor · 24 September 2015, 07:20:01

Hallo Claudiu

Zitat von: rapster am 23 September 2015, 22:30:39
keine Ahnung was mich dazu geritten hat einen eigenen INDEX zu erstellen...

Das habe ich mich auf gefragt!

Zitat von: rapster am 23 September 2015, 22:30:39
Hab die Funktion nochmals umgebaut damit KEIN zusätzlicher INDEX mehr benötigt wird !
Es wird nun der standard 'Search_Idx' INDEX welcher durch die *.sql Dateien für die DbLog Erstellung erstellt wird verwendet.
Dieser sollte bereits bei jedem vorhanden sein!

Na Gott-sei-Dank!

Ich versuche nun schon seit 3 Tagen diesen verdammten Index anzulegen und bin immer wieder gescheitert!

Dann werde ich mal die neuste Version versuchen.

Magst Du nochmal eine kurze Erklärung über alle möglichen Optionen der fhem.cfg Definitionen geben?

Danke
Sailor

rapster · 24 September 2015, 09:33:32

Zitat von: Sailor am 24 September 2015, 07:20:01
Ich versuche nun schon seit 3 Tagen diesen verdammten Index anzulegen und bin immer wieder gescheitert!
...
Magst Du nochmal eine kurze Erklärung über alle möglichen Optionen der fhem.cfg Definitionen geben?

Mensch hättst halt früher was gesagt, hatte das seit der ersten Version "auf die schnelle" so eingebaut und mir erst jetzt als die ersten zwei Leute Probleme beim Einrichten hatten Gedanken darüber gemacht ob das überhaupt so optimal ist...

An der Definition von DbLog selber hat sich nichts geändert, das einzige was dazu gekommen ist, ist das Set-Kommando"reduceLog".
In diesem Post hab ich die verschiedenen reduceLog Parameter (mit Beispielen) erklärt => http://forum.fhem.de/index.php/topic,41089.msg334617.html#msg334617

Ausgeführt werden muss der Befehl immer manuell, oder durch ein at o.ä. getriggert.

Gruß
Claudiu

nesges · 24 September 2015, 11:51:45

Sehr schöne Sache! Vielen Dank für die Umsetzung!

Ich bin grade beim "Großreinemachen". Meine MySQL-Datenbank liegt auf einem schnarchlangsamen Server (ReadyNAS), von daher dauert alles etwas länger. Dazu kommt die relativ hohe Datenmenge, die den Speicherbedarf auf dem fhem-Rechner (Raspi2) offenbar hoch treibt. Ich reduziere daher jetzt in 5-Tages-Blöcken und starte zwischendurch neu. Hier mal ein Logauszug:

Code Auswählen

2015.09.24 11:24:38 3: DbLog DBLOG1: reduceLog deleting 3102 records of day: 2015-06-15
2015.09.24 11:24:55 3: DbLog DBLOG1: reduceLog (hourly-average) updating 56 records of day: 2015-06-15
2015.09.24 11:25:01 3: DbLog DBLOG1: reduceLog deleting 33753 records of day: 2015-06-16
2015.09.24 11:26:32 3: DbLog DBLOG1: reduceLog (hourly-average) updating 661 records of day: 2015-06-16
2015.09.24 11:26:41 3: DbLog DBLOG1: reduceLog deleting 57814 records of day: 2015-06-17
2015.09.24 11:30:39 3: DbLog DBLOG1: reduceLog (hourly-average) updating 1188 records of day: 2015-06-17
2015.09.24 11:30:52 3: DbLog DBLOG1: reduceLog deleting 56771 records of day: 2015-06-18
2015.09.24 11:33:52 3: DbLog DBLOG1: reduceLog (hourly-average) updating 1608 records of day: 2015-06-18
2015.09.24 11:34:20 3: DbLog DBLOG1: reduceLog deleting 56736 records of day: 2015-06-19
2015.09.24 11:36:40 3: DbLog DBLOG1: reduceLog (hourly-average) updating 1158 records of day: 2015-06-19
2015.09.24 11:36:50 3: DbLog DBLOG1: reduceLog deleting 55551 records of day: 2015-06-20
2015.09.24 11:39:09 3: DbLog DBLOG1: reduceLog (hourly-average) updating 1108 records of day: 2015-06-20
2015.09.24 11:39:16 3: DbLog DBLOG1: reduceLog executed. Rows processed: 1043911, deleted: 263727, updated: 5779
[..]
2015.09.24 11:39:25 1: Cannot fork: Nicht genügend Hauptspeicher verfügbar

Sailor · 24 September 2015, 12:13:08

Hallo Claudiu

Zitat von: rapster am 24 September 2015, 09:33:32
An der Definition von DbLog selber hat sich nichts geändert, das einzige was dazu gekommen ist, ist das Set-Kommando"reduceLog".
In diesem Post hab ich die verschiedenen reduceLog Parameter (mit Beispielen) erklärt => http://forum.fhem.de/index.php/topic,41089.msg334617.html#msg334617

Habe vorhin mal den Befehl

Code Auswählen

set myDbLog reduceLog 30 average
eingegeben und schwupps war mein fhem abgestürzt...

Ich mache mich heute Abend mal auf die Suche da im Augenblick keine Zeit für die Fehlersuche...

Gruß
Sailor

rapster · 24 September 2015, 12:17:57

@nesges: Denke wenn dann erstmal eine gewisse Grundreinigung durch ist, und du es evtl. täglich startest sollte das auch unproblematischer sein

Allerdings werden i.M. auch bereits bearbeitete Daten in den RAM gelesen, das will ich noch ändern...

@Sailor: Abgestürzt oder blockiert? Das Fhem während der ausführung blockiert ist, ist normal. Falls wirklich abgestürzt, was tauchte zuletzt im Log auf?

Gruß
Claudiu

Sailor · 24 September 2015, 14:46:57

Hallo Claudiu

Zitat von: rapster am 24 September 2015, 12:17:57
@Sailor: Abgestürzt oder blockiert? Das Fhem während der ausführung blockiert ist, ist normal. Falls wirklich abgestürzt, was tauchte zuletzt im Log auf?

OK Habe

Code Auswählen

set myDbLog reduceLog 360 average

gestartet...

CPU auf 100%
RAM nach 10s auf 100%

Code Auswählen


pi@DeekeHomeServer /opt/fhem $ htop

  CPU[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]     Tasks: 28, 5 thr; 2 running
  Mem[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||70/434MB]     Load average: 0.96 0.61 0.36
  Swp[|||||                                                                             4/99MB]     Uptime: 7 days, 18:01:46

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
 3323 fhem       20   0 59892 53552  7440 R 93.0 12.0 17:23.73 perl fhem.pl fhem.cfg
 7467 pi         20   0  5432  2944  1964 R  4.0  0.7  0:08.92 htop

Schau mer mal... Ich harre noch der Dinge.

Die fhem.db ist immerhin 3,8GB gross!

Gruss
Sailor