Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)

[Girgl]

Hallo,

habe Probleme mit "delDoublets". Sowohl bei adviceDelete als auch bei delete habe ich folgende Fehlermeldung:

Code Auswählen Erweitern

2019-03-03 21:29:41 DbRep DbWolfStarts running
2019.03.03 21:29:41 4 : DbRep DbWolfStarts - -------- New selection ---------
2019.03.03 21:29:41 4 : DbRep DbWolfStarts - Command: delDoublets adviceDelete
2019.03.03 21:29:41 5 : DbRep DbWolfStarts - Timestamp begin epocheseconds: 1551640791
2019.03.03 21:29:41 4 : DbRep DbWolfStarts - Timestamp begin human readable: 2019-03-03 20:19:51
2019.03.03 21:29:41 5 : DbRep DbWolfStarts - Timestamp end epocheseconds: 1551644981
2019.03.03 21:29:41 4 : DbRep DbWolfStarts - Timestamp end human readable: 2019-03-03 21:29:41
2019.03.03 21:29:41 5 : DbRep DbWolfStarts - weekday of start for selection: So -> wdadd: 86400
2019.03.03 21:29:41 5 : DbRep DbWolfStarts - Daylight savings changed: 0 (on Mon Mar 4 20:19:51 2019)
2019.03.03 21:29:41 5 : DbRep DbWolfStarts - runtime_string: 2019-03-03, runtime_string_first: 2019-03-03 20:19:51, runtime_string_next: 2019-03-03 21:29:41
2019.03.03 21:29:41 4 : DbRep DbWolfStarts - Aggregation: day
2019.03.03 21:31:02 1 : DbRep DbWolfStarts -> BlockingCall deldoublets_DoParse pid:DEAD:970 Process died prematurely
2019-03-03 21:31:02 DbRep DbWolfStarts Process died prematurely

"delSeqDoublets" arbeitet einwandfrei. Ebenso alle anderen Befehle. Ich habe mittlerweile eine neue Datenbank angelegt und die geforderten Module überprüft. Keine Besserung.

Meine Datenbank:

Code Auswählen Erweitern

define DbLog DbLog ./db.conf .*:(temperature|humidity|Rain|gustSpeed|wind|Super|Diesel|Wolf|Wb_).*
setuuid DbLog 5c62fc7d-f33f-bf9c-5b32-c9c6bcfc41cb2980
attr DbLog DbLogExclude state
attr DbLog DbLogSelectionMode Exclude
attr DbLog DbLogType Current/History
attr DbLog asyncMode 1
attr DbLog disable 0
attr DbLog room logs
attr DbLog syncInterval 180

DbRep:

Code Auswählen Erweitern

define DbWolfStarts DbRep DbLog
setuuid DbWolfStarts 5c673196-f33f-bf9c-1e09-481a8a7e44d80705
attr DbWolfStarts allowDeletion 1
attr DbWolfStarts device Wolf_betrd
attr DbWolfStarts room logs
attr DbWolfStarts showproctime 1
attr DbWolfStarts verbose 5

Habs auch schon mit Zeitangaben oder definiertem reading getestet. Immer das gleiche Ergebnis! Ebenso mit reopenDatabase-Parametern.

Weiss jemand Rat?

[DS_Starter]

Hallo Girgl,

der Fehler hat eher etwas mit deiner Hardware zu tun. Typischerweise passiert es wenn dein RAM/SWAP knapp wird.
Oder vllt. Platte voll ?
Schau mal an diesen Stellen nach oder schreib mal was dazu.

Edit: Es könnte dir helfen das Attribut "aggregation = hour" zu setzen !

Grüße
Heiko

[Girgl]

Fhem läuft auf dem Raspberry 3b+, raspbian stretch frisch aufgesetzt. Abfragen der Speicher ergibt nichts aussergewöhnliches. Momentan kümmert sich der RPi nur um fhem, mpd, einen cul und ein freigegebenes DVD-Laufwerk. Ein RPi-Zero, der sich um die Heizung (ebus/1-wire) ist via fhem2fhem verbunden. Die Datenbank hat kaum Einträge.

Code Auswählen Erweitern

pi@rpi-3b:~ $ df -h
Dateisystem                                                          Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root                                                              13G    6,3G  5,6G   53% /
devtmpfs                                                              460M       0  460M    0% /dev
tmpfs                                                                 464M       0  464M    0% /dev/shm
tmpfs                                                                 464M     13M  452M    3% /run
tmpfs                                                                 5,0M    4,0K  5,0M    1% /run/lock
tmpfs                                                                 464M       0  464M    0% /sys/fs/cgroup
/dev/mmcblk0p6                                                         68M     23M   46M   33% /boot
tmpfs                                                                  93M       0   93M    0% /run/user/1000
/dev/mmcblk0p5                                                         30M    398K   28M    2% /media/pi/SETTINGS

pi@rpi-3b:~ $ cat /proc/swaps
Filename Type Size Used Priority
/var/swap                               file 102396 0 -2

[Girgl]

Ach ja, der Ram:

Code Auswählen Erweitern

pi@rpi-3b:~ $ free
              total        used        free      shared  buff/cache   available
Mem:         949448      161380      513812       18488      274256      717868
Swap:        102396           0      102396
pi@rpi-3b:~ $


Ich werde DbRep mal auf dem Laptop(Ubuntu) testen.

Danke erstmal und schöne Grüsse
Girgl

[DS_Starter]

Wenn kaum Einträge vorhanden sind ist es wirklich ein merkwürdiges verhalten.
Habe es sicherheitshalber bei gerade ausprobert -> no Problem. DbRep-Version ist aktuell nehme ich an.
Versuche noch bitte mit aggregation = hour, wird aber wegen der wenigen Einträge wohl nichts bringen.

Ich weiß nicht ob du Gelegenheit hast den Speicherverbrauch während des Laufs zu beobachten, oder ob der Abbruch sehr schnell kommt.
Heute ist es schon spät geworden ...ich schaue morgen auch nochmal nach Hinweisen.

Grüße
Heiko

[Girgl]

Hab jetzt nochmal rumprobiert und im Log folgenden Hinweis gefunden:

db prepare_cached failed: near "ASC": syntax error at ./FHEM/93_DbRep.pm line 4857

Code Auswählen Erweitern

2019.03.03 23:49:25 2: AttrTemplates: got 55 entries
2019.03.03 23:49:50 4: DbRep DbWolfStarts - -------- New selection ---------
2019.03.03 23:49:50 4: DbRep DbWolfStarts - Command: delDoublets adviceDelete
2019.03.03 23:49:50 5: DbRep DbWolfStarts - Timestamp begin epocheseconds: 1551640791
2019.03.03 23:49:50 4: DbRep DbWolfStarts - Timestamp begin human readable: 2019-03-03 20:19:51
2019.03.03 23:49:50 5: DbRep DbWolfStarts - Timestamp end epocheseconds: 1551653390
2019.03.03 23:49:50 4: DbRep DbWolfStarts - Timestamp end human readable: 2019-03-03 23:49:50
2019.03.03 23:49:50 5: DbRep DbWolfStarts - weekday of start for selection: So  ->  wdadd: 86400
2019.03.03 23:49:50 5: DbRep DbWolfStarts - Daylight savings changed: 0 (on Sun Mar  3 21:19:51 2019)
2019.03.03 23:49:50 5: DbRep DbWolfStarts - Daylight savings changed: 0 (on Sun Mar  3 22:19:51 2019)
2019.03.03 23:49:50 5: DbRep DbWolfStarts - Daylight savings changed: 0 (on Sun Mar  3 23:19:51 2019)
2019.03.03 23:49:50 5: DbRep DbWolfStarts - Daylight savings changed: 0 (on Mon Mar  4 00:19:51 2019)
2019.03.03 23:49:50 4: DbRep DbWolfStarts - Aggregation: hour
2019.03.03 23:49:50 5: DbRep DbWolfStarts - Timestamp-Array:
2019-03-03_20#2019-03-03 20:19:51#2019-03-03 21 2019-03-03_21#2019-03-03 21#2019-03-03 22 2019-03-03_22#2019-03-03 22#2019-03-03 23 2019-03-03_23#2019-03-03 23#2019-03-03 23:49:50
2019.03.03 23:49:50 5: DbRep DbWolfStarts - Devices for operation - included: Wolf_betrd , excluded:
2019.03.03 23:49:50 5: DbRep DbWolfStarts - Readings for operation - included: Wb_Aussentemp, excluded: 
DBD::SQLite::db prepare_cached [b]failed: near "ASC": syntax error at ./FHEM/93_DbRep.pm line 4857[/b].
2019.03.03 23:49:59 1: DbRep DbWolfStarts -> BlockingCall deldoublets_DoParse pid:DEAD:2065 Process died prematurely

Wie angekündigt habe ich das Ganze mal auf dem Laptop(andere Daten/Hardware) nachgestellt und bekomme im Log dieselbe Fehlermeldung:

Code Auswählen Erweitern

2019.03.03 23:29:00 3: DbLog Amilo - Creating Push-Handle to database SQLite:dbname=/opt/fhem/fhem.db with user
2019.03.03 23:29:00 3: DbLog Amilo - Push-Handle to db SQLite:dbname=/opt/fhem/fhem.db created
2019.03.03 23:29:28 3: DbRep Ami - Connectiontest to database SQLite:dbname=/opt/fhem/fhem.db with user
2019.03.03 23:29:28 3: DbRep Ami - Initial data information retrieved successfully - total time used: 0.001927 seconds
2019.03.03 23:29:28 3: DbRep Ami - Connectiontest to db SQLite:dbname=/opt/fhem/fhem.db successful
DBD::SQLite::db prepare_cached failed: near "ASC": syntax error at ./FHEM/93_DbRep.pm line 4857.
2019.03.03 23:30:00 1: DbRep Ami -> BlockingCall deldoublets_DoParse pid:DEAD:15128 Process died prematurely
2019.03.03 23:39:38 4: DbRep Ami - -------- New selection ---------
2019.03.03 23:39:38 4: DbRep Ami - Command: delDoublets adviceDelete
2019.03.03 23:39:38 5: DbRep Ami - Timestamp begin epocheseconds: 1551650443
2019.03.03 23:39:38 4: DbRep Ami - Timestamp begin human readable: 2019-03-03 23:00:43
2019.03.03 23:39:38 5: DbRep Ami - Timestamp end epocheseconds: 1551652778
2019.03.03 23:39:38 4: DbRep Ami - Timestamp end human readable: 2019-03-03 23:39:38
2019.03.03 23:39:38 5: DbRep Ami - weekday of start for selection: So  ->  wdadd: 86400
2019.03.03 23:39:38 5: DbRep Ami - Daylight savings changed: 0 (on Mon Mar  4 00:00:43 2019)
2019.03.03 23:39:38 4: DbRep Ami - Aggregation: hour
2019.03.03 23:39:38 5: DbRep Ami - Timestamp-Array:
2019-03-03_23#2019-03-03 23:00:43#2019-03-03 23:39:38
2019.03.03 23:39:38 5: DbRep Ami - Devices for operation - included: sysmon , excluded:
2019.03.03 23:39:38 5: DbRep Ami - Readings for operation - included: cpu_freq, excluded: 
DBD::SQLite::db prepare_cached [b]failed: near "ASC": syntax error at ./FHEM/93_DbRep.pm line 4857[/b].
2019.03.03 23:39:56 1: DbRep Ami -> BlockingCall deldoublets_DoParse pid:DEAD:15322 Process died prematurely

Grüße Girgl

[DS_Starter]

Guten Morgen,

alles klar.
Konnte das Problem bei mir auch nachstellen. Es trifft bei SQLite zu. Normalerweise verwende ich MySQL und bei dieser Datenbank ist die Syntax ok.
Ich werde für SQLite eine ANpassung vornehmen und stelle dir eine Version zum Test heute Abend bereit.

LG,
Heiko

[DS_Starter]

Kannst schonmal testen.

Download der Version  hier aus meinem contrib herunterladen:

https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter  (Downloadbutton benutzen)

Danach shutdown restart oder reload 93_DbRep.

LG,
Heiko

[Girgl]

Hallo Heiko,

habs grad auf die schnelle getestet und es klappt jetzt. Werde es noch mit der "alten" großen Datenbank testen, dazu komme ich heute aber nicht mehr.

Danke und Schöne Grüße!

[DS_Starter]

Hallo zusammen,

ich habe soeben die aktuelle Version von DbRep eingecheckt.
Es wird der obige Fix für SQLite ausgeliefert.
Außerdem ist es nun möglich readingRename nur auf die Readings eines bestimmten Devices anzuwenden.

* readingRename <[Device:]alterReadingname>,<neuerReadingname>
Benennt den Namen eines Readings innerhalb der angeschlossenen Datenbank (siehe Internal DATABASE) um. Der Readingname wird immer in der gesamten Datenbank umgesetzt. Eventuell gesetzte Zeitgrenzen oder Beschränkungen durch die Attribute Device bzw. Reading werden nicht berücksichtigt.
Optional kann eine Device angegeben werden. In diesem Fall werden nur die alten Readings dieses Devices in den neuen Readingnamen umgesetzt.

    Beispiele:
    set <name> readingRename TotalConsumption,L1_TotalConsumption
    set <name> readingRename Dum.Energy:TotalConsumption,L1_TotalConsumption

[supergrobi]

Hallo Heiko,

ich habe mal die Backup Funktion ausgeführt.

(set xxx dumpMySQL clientside)

nach nun knapp 22h ist er auch damit fertig geworden.

Code Auswählen Erweitern

DumpFileCreated ./log/fhem_2019_03_13_10_04.sql.gzip 2019-03-14 07:15:26
DumpFileCreatedSize 113.38 MB 2019-03-14 07:15:26
DumpRowsCurrent 6632 2019-03-14 07:15:26
DumpRowsHistory 11346422 2019-03-14 07:15:26
background_processing_time 76264.9506 2019-03-14 07:15:26
state Database backup finished 2019-03-14 07:15:27

die DB läuft auf einem zweiten Raspi.
Gibt es da eine Möglichkeit, das zu beschleunigen?

Gruß
Thomas

[DS_Starter]

Morgen Thomas,

ja, das gibt es. Für clientSide gibt zwei mögliche Attribute die Abhängigkeiten zueinander haben.
Das sind dumpMemlimit und dumpSpeed. Das sind Parameter für den Ressourcenverbrauch.
Du kannst dich dem richtigen Wert iterativ nähern um möglichst viel aber nicht zuviel Ressourcen (CPU, RAM) für den Dump zu verwenden.
Aber viel schneller geht die Variante serverSide. Dahinter steht auch eine andere Technik. Die Unterschiede sind in der commandRef beschrieben.
Hast du serverSide schonmal ausprobiert ?

liebe Grüße
Heiko

[supergrobi]

Ich wollte eigentlich clientside nutzen, da dann das Backup über ein komplettes FHEM-Backup auf dem NAS gesichert wird.
So wie ich es aus der commandRef verstanden habe, wird das serverside Backup auch als .csv abgelegt und nicht als SQL.

bin ich da richtig?

was bewirkt optimizeTablesBeforeDump?

[DS_Starter]

Ich wollte eigentlich clientside nutzen, da dann das Backup über ein komplettes FHEM-Backup auf dem NAS gesichert wird.
So wie ich es aus der commandRef verstanden habe, wird das serverside Backup auch als .csv abgelegt und nicht als SQL.

Das ist alles genau richtig. Insofern hast du die richtige Wahl getroffen.
Meine Einstellungen bei clientSide sind z.B.

dumpMemlimit  100000000
dumpSpeed     1000000

Damit sichert clientSide 21 Mio Datensätze in rund 25 Minuten (auf einem NUC).

Mit optimizeTablesBeforeDump = 1 wird vor dem Dump die Tabelle history (im Prinzip auch current) optimiert, d.h. es wird Platz freigegeben. Hat nur Sinn wenn vorher (viele) Daten gelöscht wurden. Das braucht aber zusätzlich Zeit. Wenn der Dump ohnehin schon viel Zeit benötigt würde ich das nicht machen und ggf. einen Lauf zur Optmierung separat einplanen mit set ... optimzeTables.

[supergrobi]

danke dir, ich probier das mal aus...

edit: eine Frage hab ich noch, wird das dumpMemlimit in Bytes angegeben? Also in deinem Beispiel wären das dann 100MB ?