[Gelöst]dbLog Performance Plot

[Deckoffizier]

Hallo,

bin gerade dabei von FileLog auf dbLog umzustellen.
Wenn ich es richtig verstanden habe soll es auch es etwas Performance Gewinn bringen ?

Hmm...  wenn ich den Seitenaufbau eines SVG Plot betrachte dauert es bald 2 Sekunden bis zur Anzeige eines Plots generiert aus dbLog.

Aus FileLog sind sie (die Plots) quasi sofort da.

Habe ich eventuell falsche Einstellungen oder ist dies normal?

Gruß

Hans-Jürgen

[DS_Starter]

Hallo Hans-Jürgen,

Habe ich eventuell falsche Einstellungen oder ist dies normal?

Also normal ist es nicht und so soll es auch nicht sein.

Nur ist die Frage wieso es so ist nicht ganz trivial zu beantworten. Eine DB zu benutzen ist unter Umständen nicht immer die erste Wahl.
Es kommt ganz stark auf dein Umfeld an. Also welches Datenbanksystem verwendest du (SQLite, MySQL, Postgre), läuft die DB auf dem FHEM-Server selbst oder remote , wieviel Ressorcen kann die DB verwenden, ist das Datenbanksystem optimal konfiguriert usw.

Meist wird ja für FHEM ein relativ schwaches RPi-System verwendet. Das kann etwas kontraproduktiv sein wenn z.B. keine CPU Kapazität mehr zur Verfügung steht was die DB dann ausbremst. Ähnliches gilt für RAM.

Damit dir weitergeholfen werden kann, wäre es sicherlich von Vorteil wenn du möglichst viele Details zur verwendeten DB und deinem Umfeld lieferst und im Unterforum "Automatisierung" einstellst. Je nach verwendeten DB-System findet sich dann sicherlich ein in der Datenbankkonfiguration erfahrener User der dir weiterhelfen kann.
Diese Performanceoptimierung  hat wahrscheinlich nicht direkt etwas mit FHEM zu tun sondern ist vermutlich eher von Einflüssen außerhalb FHEM abhängig.
Ich selbst kann dir urlaubsbedingt momentan nicht direkt viel weiterhelfen.

Grüße
Heiko

[Deckoffizier]

Hallo DS_Starter,

Danke für Deinen Schnellschuss

genieße Deinen Urlaub ist ja bei mir kein schwerwiegendes Problem.

SQLite läuft bei mir auf dem FHEM-Server einem Raspi 3.

RAM und CPU Auslastung sieht soweit unproblematisch aus.

Gruß

Hans-Jürgen

[viegener]

SQLite ist im Prinzip schon ein relativ einfaches System und nicht unbedingt ein vollwertiges Datenbanksystem, trotzdem sollte es normalerweise nicht langsamer sein als Filelog.

Ohne im Detail die Zugriffe zu kenne, wäre meine erste Frage, ob der search_idx auch existiert?
Dazu im DBtool von SQLite (sqlite3 /opt/fhem/fhem.db)mal .schemaeingeben. Dann sollte eine Zeile wie folgende dabei sein:

Code Auswählen Erweitern

CREATE INDEX Search_Idx ON `history` (DEVICE, READING, TIMESTAMP);

Ansonsten sind das immer noch nicht sehr viel Informationen, deshalb ist es schwer zu helfen.
Interessant wäre sicher auch zu sehen wieviel Datenpunkte gelesen werden ob das ein spezieller Plot ist oder mehrere - etc

[Deckoffizier]

Hallo viegener,

scheinst wohl den richtigen Riecher zu haben

da sieht es nur so aus
CREATE TABLE 'current' (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
CREATE TABLE 'history' (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));

werde mich auf die Suche machen den search_idx zu erstellen.

Danke für Deine Mühe

Hans-Jürgen

[viegener]

Schön, das Kommando für den Index steckt in im sql-skript unter contrib/dblog/db_create_sqlite.sql

[NehCoy]

Hallo!

Bin ebenfalls gerade dabei von FileLog auf DbLog umzustellen.
Auch bei mir hat das anzeigen der SVG Plots im Vergleich dazu recht lange gedauert.
Aber die Graphs sahen etwas "komisch" aus. - Mir ist dann aufgefallen, dass ich die Filter beim Auslesen nicht beachtet hatte und so auch werde "geplotet" wurden, die eigentlich nicht dazu gehörten.
siehe auch: https://forum.fhem.de/index.php/topic,76392.0.html

Gruß
NehCoy

[Deckoffizier]

Hallo an Alle,

ja das erstellen des Search_IDx hat Abhilfe geschaffen.

Schön wäre es wenn diese Zeile im Wiki zu DBlog beim Beispiel: Anlegen und Nutzung einer SQLite-Datenbank Eingang gefunden hätte.
Setze die Sache mal auf gelöst.

Danke an alle Mitstreiter

Hans-Jürgen

[DS_Starter]

steht aber in der commandref wenn ich mich nicht täusche. ansonsten nehmevichbes dort mit auf weil sehr wichtig.

grüsse aus dem schönen österreich 
Heiko

[Amenophis86]

Habe es im Wiki ergänzt

[NehCoy]

Nun am vierten Tag, wird auch meine Anzeige spürbar langsam(er), obwohl meine MariaDB Datenbank den  "Search_Idx" bereits hat! 

Grüße
NehCoy

[Deckoffizier]

Hallo Amenophis86,

weil wir gerade dabei sind,
könnte es sein im Wiki unten die Zeile für userReadings um zu ändern ergänzen in

DbFileSize:reduceLogState.* { (split(' ',`du -m fhem.db`))[0] }

für SQLite

sorry falls ich mit meiner 0 Ahnung Mist geschrieben habe .
Hat mich schon einige Stunden sucherei gekostet warum dieses userReading nicht angelegt wurde.

Gruß
Hans-Jürgen

[Deckoffizier]

Hallo NehCoy,

bin ja selber nur am Blindflug und rate mal ins Blaue

Anzeige nur der SVG Plots oder Insgesamt?

Datenmenge der Datenbank eingeschränkt oder wächst und wächst?

Bei mir versuche ich erst mal mit DOIF     
([03:00:00]) (set myDbLog deleteOldDaysNbl 3) { Log 1, "SQL Lite Datenbank geschrumpft" }

analog nrarchive Attribut erst mal etwas einzuschränken und bin beim Feintuning.
Dann läuft bei mir noch unter Benutzung von FileLog sysmon so sieht man ganz gut den Speicherverbrauch auf USB Stick + RAM am Pi.
Umzug auf vorhandenen "richtigen" Server ist geplant und der Pi dann als Hardware Reserve.

Gruß
Hans-Jürgen

[Amenophis86]

@Deckoffizier
: du meinst anstelle von

Code Auswählen Erweitern

attr myDbLog userReadings DbFileSize:lastReduceLogResult.* { (split(' ',`du -m fhem.db`))[0] } soll dein Code genommen werden? Ist der im Wiki falsch?

[Deckoffizier]

Hallo  Amenophis86,

ob der Code im Wiki falsch ist kann ich nicht beurteilen, da mir der Sachverstand fehlt und er für andere Datenbankarten eventuell so passt.

Bei mir wurde mit SQLite mit dem Original Code kein userReadings mit der Datenbankgröße angelegt.

Ansonsten ja bitte !

Gruß
Hans-Jürgen