93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)

DS_Starter · 17 Oktober 2017, 01:14:06

krass ... gut zu wissen

Grüsse,
Heiko

DS_Starter · 18 Oktober 2017, 00:00:27

Guten Abend zusammen,

ich habe DbRep erweitert um das device-Attribut nun mit Devspec-Syntax angeben zu können.
Damit steht bei der Auffüllung der Current-Tabelle eine komfortablere Abgrenzung der zu berücksichtigenden Device-Datensätze zur Verfügung.
Weitere Infos dazu sind hier: https://forum.fhem.de/index.php/topic,53584.msg700877.html#msg700877

Würde mich über Testergebnisse freuen.

VG
Heiko

DS_Starter · 19 Oktober 2017, 21:19:32

Hallo,

habe herausgefunden wieso der "state" im DbLog manchmal unleserliche Zeichen enthielt und ist nun in der hier angehängten Version 2.22.12 gefixt.
Ich checke die Version dann auch ins SVN ein.

Grüße
Heiko

Pyromane · 19 Oktober 2017, 23:56:02

Hallo Heiko,

22.12 zeigt keinerlei Auffälligkeiten

DbRep werde ich mir am Wochenende genauer anschauen.

Gute Nacht zusammen
Pyro

JoeALLb · 23 Oktober 2017, 11:31:40

Danke fürs einchecken, funktioniert bei mir wunderbar.

DS_Starter · 30 November 2017, 22:12:36

Hallo zusammen,

Es gab noch eine Funktion die wir im ersten Beitrag notiert hatten:

#27 Eine Funktion ähnlich der average funktion, aber für nicht-numerische werte, also löschen aller records, ausser VALUE ändert sich, behalten von min 1 Wert/Stunde bzw. Tag... (werner)

So etwas habe ich jetzt in DbRep realisiert. Es wird auch mindestens der erste und letzte Datensatz eines Tages in der DB behalten.
https://forum.fhem.de/index.php/topic,53584.msg723924.html#msg723924

EDIT: inzwischen kann man über aggregation wählen ob mindestens der erste und letzte Datensatz eines Tages, einer Stunde, Woche usw. behalten werden soll.

Grüße
Heiko

abc2006 · 03 Dezember 2017, 20:16:13

Hi,
auch von mir erstmal Respekt für die Arbeit, die ihr hier geleistet habt. Hab mich im Laufe der letzten drei Tage mal durch alle 35 Seite gearbeitet

Dann hab ich mein Contrib auf vordermann gebracht (dafür gibts auch keine richtige Anleitung, oder?)
und jetzt das neue DbLog getestet. Dabei ist mir aufgefallen, dass im state unleserliche Zeichen enthalten waren. Allerdings wollte ich nicht von Seite 20 direkt eine Antwort posten - und jetzt ist der State wieder prima.
Ich benutze Mysql mit etwa 90 Mio. Einträgen in der history-Datenbank.

meine 93_DbLog.pm ist die Version:

Zitat$Id: 93_DbLog.pm 15517 2017-11-28 20:22:56Z DS_Starter $

Wenn ihr noch Infos braucht - ich hab keinerlei Ansatzpunkt - dann meldet euch.

Danke nochmal an alle,
Stephan

DS_Starter · 03 Dezember 2017, 20:27:21

Hallo Stephan,

dieses Verhalten war bekannt, ist aber mit der Version 2.22.12 vom 19.10.2017 behoben.
Mit der von dir zitierten Version sollte es nicht mehr auftreten (ist es bei mir und auch den Testern nicht mehr aufgetreten).

Grüße
Heiko

DS_Starter · 03 Dezember 2017, 21:06:37

Da ich grad angemeldet bin möchte ich euch auch gleich die aktuellste DbLog zum Download anbieten und euch bitten die Version bei euch zu testen und zu schauen ob alles wie gewohnt läuft:

* die Ausgaben sind erweitert (verbose 4), man sieht z.B. mit welchem AutoCommit mode die Session läuft (On/Off), bzw. wieviele Datensätze eines Sync-Laufs commited wurden und welche rejected wurden -> Beispiel:

Code Auswählen


2017.12.03 20:36:48.701 4: DbLog LogDB1 -> ################################################################
2017.12.03 20:36:48.702 4: DbLog LogDB1 -> ###      New database processing cycle - asynchronous        ###
2017.12.03 20:36:48.703 4: DbLog LogDB1 -> ################################################################
2017.12.03 20:36:48.703 4: DbLog LogDB1 -> MemCache contains 54 entries to process
2017.12.03 20:36:48.704 4: DbLog LogDB1 -> DbLogType is: SampleFill/History
2017.12.03 20:36:48.718 4: DbLog LogDB1 -> AutoCommit mode: ON
2017.12.03 20:36:48.856 3: DbLog LogDB1 -> Insert into history rejected (possible PK violation) - TS: 2017-12-03 20:36:02, Device: Rep.Show.DbSize, Event: state: done
2017.12.03 20:36:48.857 3: DbLog LogDB1 -> Insert into history rejected (possible PK violation) - TS: 2017-12-03 20:36:02, Device: SDS1_SVS, Event: Errorcode: none
2017.12.03 20:36:48.858 3: DbLog LogDB1 -> Insert into history rejected (possible PK violation) - TS: 2017-12-03 20:36:02, Device: SDS1_SVS, Event: Error: none
2017.12.03 20:36:48.858 3: DbLog LogDB1 -> Insert into history rejected (possible PK violation) - TS: 2017-12-03 20:36:02, Device: SDS1_SVS, Event: Errorcode: none
2017.12.03 20:36:48.859 3: DbLog LogDB1 -> Insert into history rejected (possible PK violation) - TS: 2017-12-03 20:36:02, Device: SDS1_SVS, Event: Error: none
2017.12.03 20:36:48.860 4: DbLog LogDB1 -> 49 of 54 events inserted into table history using PK on columns TIMESTAMP,DEVICE,READING
2017.12.03 20:36:48.861 4: DbLog LogDB1 -> insert history committed
2017.12.03 20:36:48.863 4: DbLog LogDB1 -> insert or update current committed

* für die reduceLog/Nbl habe ich Fortschrittsmitteilungen eingebaut, damit man sieht wo der Prozess ungefähr steht. Das gilt auch für das blockierende reduceLog. Hier muß man sich das Logfile außerhalb von fhem anschauen, z.B. mit tail -f <file>, um es zu verfolgen. Das ist sicherlich insbesondere bei lang laufenden Prozessen von Interesse. Beispiel:

Code Auswählen


2017.12.03 20:42:02.260 3: DbLog LogDB1: reduceLogNbl requested with DAYS=197, AVERAGE=DAY
2017.12.03 20:42:04.039 3: DbLog LogDB1: reduceLogNbl deleting 1448 records of day: 2017-05-18
2017.12.03 20:42:04.249 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-18 is: 100
2017.12.03 20:42:04.441 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-18 is: 200
2017.12.03 20:42:04.635 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-18 is: 300
......
2017.12.03 20:42:07.227 3: DbLog LogDB1: reduceLogNbl (hourly-average) updating 23 records of day: 2017-05-18
2017.12.03 20:42:07.316 3: DbLog LogDB1: reduceLogNbl (daily-average) updating 33, deleting 629 records of day: 2017-05-18
2017.12.03 20:42:07.501 3: DbLog LogDB1: reduceLogNbl (daily-average) deleting progress of day: 2017-05-18 is: 100
2017.12.03 20:42:07.677 3: DbLog LogDB1: reduceLogNbl (daily-average) deleting progress of day: 2017-05-18 is: 200
2017.12.03 20:42:07.879 3: DbLog LogDB1: reduceLogNbl (daily-average) deleting progress of day: 2017-05-18 is: 300
.....
2017.12.03 20:42:09.317 3: DbLog LogDB1: reduceLogNbl deleting 39029 records of day: 2017-05-19
2017.12.03 20:42:29.305 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-19 is: 10000
2017.12.03 20:42:51.521 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-19 is: 20000
2017.12.03 20:43:12.680 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-19 is: 30000
....

* ein neues Attribut "autocommit". Man kann explizit den Autocommit-Modus der DB schalten. Gedacht ist es z.Zt. für Sonderfälle oder Supportfälle.
Standard ist "basic", d.h. wie bis jetzt auch wird die Servereinstellung verwendet, was meist Autocommit "ON" sein dürfte. Man kann den Modus mit dem Attr explizit on oder off schalten. Im Code habe ich nochmal besonders danach geschaut dass beide Varianten auch unterstützt werden.

* einige kleinere / kosmetische Anpassungen

Bitte gebt wieder Rückmeldung.

viele Grüße
Heiko

abc2006 · 03 Dezember 2017, 22:07:17

Hallo Heiko,

deswegen melde ich mich ja.
Wenn ich es nochmal sehe, versuche ich es festzuhalten - war blöd, dass ich es erst festgestellt und dann erst die Beiträge dazu gelesen hatte.

Zum Thema current/history:
Ich häng da ein bisschen fest. Ist es richtig, dass wenn ich eine current-tabelle nutze, im SVG dropdowns für Device und Reading habe (haben sollte)?

Ich habe:

eine Datenbank (DEVEL_fhem) angelegt
Tabellen (current und history) nach der db_create_mysql angelegt
ein DbLog-Device angelegt
ein DbRep-Device angelegt
bei DbLog
- attr DbLogDevice DbLogType SampleFill/History ausgewählt
bei DbRep
- set <DbRep-name> tableCurrentFillup ausgeführt

dann bei DbLog auf den "Create SVG"-Link geklickt

Aber im SVG hab ich für Reading und Device keine Dropdowns.

Mach ich was falsch, bzw, Was mache ich falsch?

btw: Ich muss jetzt für diese eine Funktion ein DbRep-Device besitzen. Wäre es eine Idee, ein Attribut "reloadCurrentTable" einzuführen, in dem man dann eine Uhrzeit ([12:00]),eine Zeitspanne eingeben kann (86400) oder ein Event, zu der/dem die current-Tabelle aktualisiert wird?

Grüße,
Stephan

DS_Starter · 03 Dezember 2017, 22:28:45

ZitatIst es richtig, dass wenn ich eine current-tabelle nutze, im SVG dropdowns für Device und Reading habe (haben sollte)?

Ja, richtig.

Was du gemacht hast um das fllup auszuführen sieht erstmal richtig aus. Allerdings kommt es nun darauf an dass DbRep so eingestellt ist dass auch die Selektionen erfolgen können, also keine (bzw. die richtigen ! Zeit-, Device-, Reading EIngrenzungen).

Nach einem fillup kannst du im debrep mit set ... fetchrows current prüfen was dort drinsteht.
Steht denn etwas drin ?

Wenn nicht, wäre zu prüfen weshalb. Ich würde erstmal mit der ganz normalen Einstellung current/history starten um damit warm zu werden.

Zitatbtw: Ich muss jetzt für diese eine Funktion ein DbRep-Device besitzen. Wäre es eine Idee, ein Attribut "reloadCurrentTable" einzuführen, in dem man dann eine Uhrzeit ([12:00]),eine Zeitspanne eingeben kann (86400) oder ein Event, zu der/dem die current-Tabelle aktualisiert wird?

Genau dazu gibt es ja die Möglichkeit mit DbRep. Du kannst du über umfangreiche Einstellungsmöglichkeiten bestimmen womit die current Tabelle aufgefüllt werden soll, z.B. nur über die Selektionen des letzten Monats o.ä. Und wann das geschehen soll macht man über ein AT (so mache in es) , ja und wenn es ein Event sein soll tut es ein Notify

Grüße
Heiko

abc2006 · 04 Dezember 2017, 10:59:00

Hi,

ZitatSteht denn etwas drin ?

Nein. Dafür hab ich folgenden Fehler:

Zitat
DBD::mysql::st execute failed: Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'DEVELfhem.history.TIMESTAMP' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at ./FHEM/93_DbRep.pm line 3453.

Da ich nicht genau weiss, was ich jetzt wie gemacht hatte, mach ich grade alles nochmal.
Also "DROP DATABASE;" und jetzt neu anlegen.
Dabei fällt mir folgendes auf:
In diesem Thread gings oft um einen Primary Key. In der "db_create_mysql" wird aber *nur* der normale Index erzeugt. Gibt es bereits eine Anleitung, um den PK umzusetzen?
Also nicht, dass ich nicht einen PK erzeugen könnte.. aber Ich hatte den Eindruck, ihr habt viel getestet. Habt ihr einen optimalen herausgefunden?

So, ich habe meine Datenbank mit

ZitatCREATE DATABASE `DEVELfhem` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
CREATE USER 'DEVELfhemuser'@'%' IDENTIFIED BY 'stephan';
CREATE TABLE `DEVELfhem`.`history` (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
CREATE TABLE `DEVELfhem`.`current` (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
GRANT SELECT, INSERT, DELETE, UPDATE ON `DEVELfhem`.* TO 'DEVELfhemuser'@'%';
CREATE INDEX Search_Idx ON `DEVELfhem`.`history` (DEVICE, READING, TIMESTAMP);

erzeugt. in die Tabelle History werden auch Daten geschrieben.
Das füllen der Tabelle current mit dem SampleFill hingegen schlägt weiterhin fehl.

Danach hatte ich Probleme mit meinem live-logdb - es konnte nicht mehr connecten und vertröstete mich auf den nächsten Sync. Ein Shutdown restart" hat geholfen.

Umstellen auf Current/History funktioniert einwandfrei. Die current-Tabelle wird einwandfrei gefüllt. Jetzt hab ich auch Dropdowns.

Hab das ganze nochmal mit dbrep verbose 5 ausgeführt, kommen aber leider nicht mehr Meldungen als das

Zitat2017-12-04 10:00:14.508 DbRep DEVEL_repdb running
2017-12-04 10:00:14.711 DbRep DEVEL_repdb errortext: DBD::mysql::st execute failed: Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'DEVELfhem.history.TIMESTAMP' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at ./FHEM/93_DbRep.pm line 3453.
2017-12-04 10:00:14.728 DbRep DEVEL_repdb error

Grüße,
Stephan

DS_Starter · 04 Dezember 2017, 12:55:52

ZitatDBD::mysql::st execute failed: Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'DEVELfhem.history.TIMESTAMP' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at ./FHEM/93_DbRep.pm line 3453.

Das ist natürlich ein Fehler der da nichts zu suchen hat. Mach mal bitte ein list deines DbRep-Devices.
Ich benutze ebenfalls MySQL (konkret MariaDB).

Bzgl. PK würde ich an die Beiträge von JoeAllb verweisen. Er hat viele Tests gemacht.
Meines Erachtens nach war dieser der günstigste (verwende ich ) für die history:

Code Auswählen

ALTER TABLE fhem.history ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);

und die current:

Code Auswählen

ALTER TABLE `current` ADD PRIMARY KEY (DEVICE, READING);

Grüße
Heiko

abc2006 · 04 Dezember 2017, 13:15:36

Hier ist das list:

ZitatInternals:
DATABASE DEVELfhem
DEF DEVEL_logdb
LASTCMD tableCurrentFillup
NAME DEVEL_repdb
NOTIFYDEV global,DEVEL_repdb
NR 737
NTFY_ORDER 50-DEVEL_repdb
ROLE Client
STATE error
TYPE DbRep
UTF8 0
VERSION 6.0.0
HELPER:
DBLOGDEVICE DEVEL_logdb
CV:
aggregation no
aggsec 1
destr 2017-12-04
dsstr 1970-01-01
epoch_seconds_end 1512378014
mestr 12
msstr 01
testr 10:00:14
tsstr 01:00:00
wdadd 345600
yestr 2017
ysstr 1970
READINGS:
2017-12-04 10:00:14 errortext DBD::mysql::st execute failed: Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'DEVELfhem.history.TIMESTAMP' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at ./FHEM/93_DbRep.pm line 3453.

2017-12-04 10:00:14 state error
dbloghash:
COLUMNS field length used for Device: 64, Type: 64, Event: 0, Reading: 64, Value: 128, Unit: 32
CONFIGURATION ./db_DEVELfhem.conf
DEF ./db_DEVELfhem.conf .*:.*
MODE asynchronous
MODEL MYSQL
NAME DEVEL_logdb
NR 736
NTFY_ORDER 50-DEVEL_logdb
PID 11980
REGEXP .*:.*
STATE disabled
TYPE DbLog
UTF8 0
VERSION 2.22.15
dbconn mysql:database=DEVELfhem;host=localhost;port=3306
dbuser DEVELfhemuser
HELPER:
COLSET 1
DEVICECOL 64
EVENTCOL 0
OLDSTATE disabled
READINGCOL 64
TYPECOL 64
UNITCOL 32
VALUECOL 128
Helper:
DBLOG:
state:
DEVEL_logdb:
TIME 1512377850.21721
VALUE disabled
READINGS:
2017-12-04 09:57:37 CacheUsage 1
2017-12-04 09:57:30 NextSync 2017-12-04 09:58:00 or if CacheUsage 500 reached
2017-12-04 09:57:37 state disabled
cache:
index 925
memcache:
925 2017-12-04 09:57:30|DEVEL_logdb|DBLOG||state|disabled|
Attributes:
room Logging,x_devel

Wegen dem PK:
Wenn der besser ist, würde ich vorschlagen, den (ggf mit kommentar) in die db_create.* zu übernehmen... Zum testen lass ichs jetzt erstmal original lt. Anleitung.

Bin eh dran, um meine DB zu optimieren, dafür brauch ich die Test-, bzw. Backup-DB.

Grüße,
Stephan

DS_Starter · 04 Dezember 2017, 22:35:33

Hallo Stephan,
das Problem kommt durch eine Servereinstellung, die offensichtlich bei dir (oder MySQL) und MariaDB nicht identisch ist.
Habe im Modul eine Gegenmassnahem eingebaut.

Probiere mal ob es mit der angehängten V6.3.1 auch bei dir funktioniert.

Grüße
Heiko