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

[DS_Starter]

Musst nichts einstellen. Hast du auch reload oder Restart gemacht ?
Ansonsten schauen wir morgen nochmal ...

GN

[OiledAmoeba]

Beides. Nachdem reload 93_DbLog.pm keinen Erfolg hatte, hatte ich fhem neu gestartet. Internals zeigt auch Version 3.8.0 an.
Import des Cache schlägt weiter fehl. Habe die Datei noch nicht geändert, kann ich also morgen wieder als Test nehmen.

Gesendet von meinem VTR-L09 mit Tapatalk

[DS_Starter]

Moin Florian,

ich war wohl gestern schon zu müde und verbraucht. Die Umstellung im Modul betrifft das Logging. Das hat direkte Auswirkung auf den Cacheinhalt, der dann wiederum gleich im richtigen Format mit exportCache exportiert wird.

Für den Import deines Files müssen wir dem Modul einmalig noch unter die Arme greifen. Editiere bitte den Datensatz wie folgt:

2018-01-25 12:38:22|global|GLOBAL|ATTR TempFeuchte event-on-update-reading (1.HUMIDITY_ESC_1.TEMPERATURE)|state|ATTR TempFeuchte event-on-update-reading (1.HUMIDITY|1.TEMPERATURE)|

Wenn der Datensatz in der DB gespeichert wird, wirst du wieder den originalen Inhalt vorfinden.
Zukünftig werden beim Logging solche "Problemdaten" von vornherein so behandelt. Der charFilter betrifft die Behandlung von Steuerzeichen, Umlauten (Umsetzung in ue, ae, usw.)

Grüße,
Heiko

[OiledAmoeba]

Moin,

hat funktioniert!

Code Auswählen Erweitern

26048 cache rows processed from ./log/cache_logdb_2018-01-25_16-04-32
An den Plots ist schön zu sehen, dass die Daten auch angekommen sind.

Klasse Arbeit, vielen Dank!

Gruß
Florian

PS. Eigentlich wollte ich jetzt global ausschließen, aber ich lasse es heute noch mal drin und werde ein paar Attribute setzen. Dann kann ich testen, ob der neue Code auch lüppt.

[DS_Starter]

Super 
Ja, mach das mal bitte. Ich teste heute auch noch etwas.
Wenn bei dir auch alles rund läuft würde ich die Version ins SVN übernehmen.

LG,
Heiko

[OiledAmoeba]

So, ich habe jetzt mehrere Attribute mit | gesetzt, Dummys angelegt und denen dann Umlaute in den Status geschrieben - ohne Probleme. Ich habe jetzt aber nicht die Datenbank kontrolliert, ob da alles richtig ankommt. Da aber die Status und für die Graphen die History vorhanden sind, unterstelle ich, dass da alles lüppt.
Nur meinen CUL konnte ich nicht überreden, Grütze zu senden...

[DS_Starter]

Hallo Florian,

danke für die Rückinfo. Das sieht gut aus. Bei mir habe ich meine Tests auch erfolgreich absolviert.
Denke das passt und ich werde die Version morgen ins SVN übernehmen. Ist dann MOntag früh im Update.

Danke und Grüße
Heiko

[DS_Starter]

Hallo zusammen,

Ich habe soeben eine neue Version 3.8.3 eingecheckt. Neben einigen weiteren Verbesserungen/Fixes habe ich das CacheUsage-Handling umgestellt.
Wenn cacheLimit erreicht ist, wird nach einem fehlerhaften Schreibvorgang ein erneuter Versuch frühestens nach syncInterval/2 gestartet.
Das entlastet fhem in diesem speziellen Fehlerfall.

Bitte updaten !

Grüße,
Heiko

[abc2006]

Hi,
ich wollte mal ein Feedback zu Performance geben:

Ich hab eine SQLite3-Datenbank mit ca. 400 MB nach optimierungen, vorher waren es knapp 2 GB.
Auf meinem Rechner hat der import einer Logdatei mit ca. 8 MB mit importFileLog etwa 1,5h gedauert.
Nun habe ich einen Primary Key hinzugefügt:

Code Auswählen Erweitern

sqlite> .schema
CREATE TABLE IF NOT EXISTS 'current' (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
CREATE TABLE IF NOT EXISTS 'history' (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32), PRIMARY KEY(TIMESTAMP, DEVICE, READING));


Der import der aktuellen Logdatei, Größe etwa 7,5 MB, wurde um 16:42 begonnen und ist noch nicht fertig.
Vielleicht geht was schief, aber das dauert mir echt (zu) lange...

Sooo.
Ein Blick ins Log (nach restart, verbose 5 und neuem import) zeigt:

Code Auswählen Erweitern

2018.02.05 21:57:08.372 4: BlockingCall (FileLogConvert_FileRead): created child (15418), uses telnetPort to connect back
2018.02.05 21:57:08.373 4: Executing INSERT INTO history (TIMESTAMP,DEVICE,TYPE,EVENT,READING,VALUE,UNIT) VALUES ('2018-01-23 00:00:00','DF_setHTNT','','tarif: NT','tarif','NT','');
DBD::SQLite::db do failed: UNIQUE constraint failed: history.TIMESTAMP, history.DEVICE, history.READING at ./FHEM/93_DbLog.pm line 2388, <FH> line 1.


Mein Fehler? Ich kanns nicht deuten....
Ah, ich hab irgendwo was von INSERT IGNORE gelesen, was man benutzen (muss?), wenn man möglicherweise doppelte Datensätze in eine PK-Tabelle einfügt ...
Das habe ich auch gebraucht, um den PK anzulegen...


Grüße,
Stephan

[DS_Starter]

Hallo Stephan,

so wie ich das lese bist du gerade dabei logfiles mit dem Tool von DeeSpe zu importieren, richtig ?

Ich denke das hat nicht geklappt. Die verschiedenen Statements abhängig vom vorhandenen PK oder nicht wird von DbLog automatisch gewählt wenn es um das Loggen von Events geht.
DeeSpe verwendet mit seinem Importtool die Funktion "DbLog_ExecSQL". Das ist ein Seiteneinstieg für Modulentwickler um Werte in die DB zu pumpen.

Frag ihn mal in dem richtigen Thread (siehe commandref von DbLog am Anfang) ob er mit seiner insert-Syntax Rücksicht nimmt auf einen vorhandenen PK.
Das sieht mir nämlich nicht so aus.

DBD::SQLite::db do failed: UNIQUE constraint failed:  ....

Dann fliegt der Prozess weg, weil die DB das nicht handeln kann (falsches Statement).

Was macht dein Memory-Problem ?

Grüße,
Heiko

[abc2006]

Code Auswählen Erweitern


Das sieht mir nämlich nicht so aus.

Dann sind wir der gleichen Meinung.

Code Auswählen Erweitern

Was macht dein Memory-Problem ?

Danke der Nachfrage:
Rudi hat aufgegeben... Ich werde wohl mal in neue Hardware investieren, oder ein zweites FHEM auf einem neuen Rechner aufsetzen oder ... tja.. sobald, wenn, falls ich mal Zeit hab...

Wenn ich noch was durchschlagendes finde, meld ich mich. Aber es sieht nicht danach aus;(

Grüße, Stephan

[DeeSPe]

Was müsste ich denn mit dem Aufruf von DbLog_ExecSQL tun um Rücksicht auf den PK zu nehmen?
Bin doch nicht so der SQL Junkie sondern hab mich ja mit FileLogConvert nur an Deine Funktion gehängt.

Gruß
Dan

[abc2006]

Huhu Kann ich mir dann den zweiten Post sparen?

Edit:

http://www.sqlitetutorial.net/sqlite-replace-statement/

Code Auswählen Erweitern

REPLACE INTO history

Grüße,
Stephan

[DS_Starter]

Hi Dan,

Was müsste ich denn mit dem Aufruf von DbLog_ExecSQL tun um Rücksicht auf den PK zu nehmen?

Das ist ein bisschen Aufwand.

Zunächst musst du ermitteln ob PK benutzt wird. Dazu kannst du eine DbLog Funktion nutzen:

Code Auswählen Erweitern

($usepkh,$usepkc,$pkh,$pkc) = DbLog_checkUsePK($hash,$dbh);

Dann musst du abhängig davon die SQL's zusammenbauen. Dummerweise haben die verschiedenen DB-Typen auch noch unterschiedliche Syntax dafür.
Hier mal die Syntax wie ich sie für den Insert der Events benutze:

Code Auswählen Erweitern


      # insert history mit/ohne primary key
  if ($usepkh && $hash->{MODEL} eq 'MYSQL') {
      eval { $sth_ih = $dbh->prepare("INSERT IGNORE INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"); };
  } elsif ($usepkh && $hash->{MODEL} eq 'SQLITE') {
      eval { $sth_ih = $dbh->prepare("INSERT OR IGNORE INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"); };
  } elsif ($usepkh && $hash->{MODEL} eq 'POSTGRESQL') {
      eval { $sth_ih = $dbh->prepare("INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?) ON CONFLICT DO NOTHING"); };
  } else {
      # old behavior
      eval { $sth_ih = $dbh->prepare("INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"); };
  }
  if ($@) {
             # Eventliste zurückgeben wenn z.B. disk I/O error bei SQLITE
             $error = encode_base64($@,"");
             Log3 ($name, 2, "DbLog $name - Error: $@");
             Log3 ($name, 5, "DbLog $name -> DbLog_PushAsync finished");
             $dbh->disconnect();
            return "$name|$error|0|$rowlist";
         }


Das müßtest du entsprechend adaptieren und das richtige Statement dann an DbLog_ExecSQL übergeben. So zumindst die Theorie 

Grüße
Heiko

[DeeSPe]

Hmm, dann denke ich ist für diesen Fall die Funktion DbLog_ExecSQL einfach falsch.
Im Prinzip brauche ich ja kein volles ExecSQL. Eine InsertSQL Funktion würde mir ja reichen wenn das restliche DB-Handling eh schon in DbLog vorhanden ist.
Gibt es so eine Funktion in DbLog?

Gruß
Dan