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
Hallo Hans-Jürgen,
ZitatHabe 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
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
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:
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
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
Schön, das Kommando für den Index steckt in im sql-skript unter contrib/dblog/db_create_sqlite.sql
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
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
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 :D
Heiko
Habe es im Wiki ergänzt
Nun am vierten Tag, wird auch meine Anzeige spürbar langsam(er), obwohl meine MariaDB Datenbank den "Search_Idx" bereits hat! :-[
Grüße
NehCoy
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
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
@Deckoffizier
: du meinst anstelle von attr myDbLog userReadings DbFileSize:lastReduceLogResult.* { (split(' ',`du -m fhem.db`))[0] } soll dein Code genommen werden? Ist der im Wiki falsch?
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
@Heiko kannst du da mal Licht ins Dunkle bringen, damit ich es im Wiki entsprechend ändern kann :)
Ja, nach meinem Urlaub. Habe den Code gerade nicht vor mir und mit einem telefon schreiben und testen ist eh keine so tolle Sache ;)
grüsse
Heiko
Zitat von: Deckoffizier am 12 September 2017, 20:33:16
Bei mir versuche ich erst mal mit DOIF
([03:00:00]) (set myDbLog deleteOldDaysNbl 3) { Log 1, "SQL Lite Datenbank geschrumpft" }
Hei,
nun habe ich auch einen index erstellt und es ist performater geworden. Super.
Die Datenreduzierung habe ich mal manuell üder das DBLog device gestartet, um dann
festzustellen, dass mein Fhem bis zum Ende (so ca. 8 Stunden später) nicht mehr
ansprechbar war.
Wie mache ich das richtig, ohne dass das System komplett ausgebremst wird ?
Habe irgendwas von nonblocking gelesen.
Jens
Ich habe für solche Sachen ein zweites FHEM auf dem gleichen Pi aufgesetzt. Alles was blockiert wird mit diesem ausgeführt und ist mit FHEM2FHEM mit der Hauptinstanz verbunden.
Hallo Jens,
stehe ja auch erst am Anfang zum Thema Reduzierung der Daten in der SQlite Datenbank.
Hierzu lässt sich eigentlich einiges im Forum erlesen aber vor Fehlern beim probieren habe ich doch schon Bange vom hunderdsten ins tausendste zu kommen.
Probiere doch mal bei Deiner Datenbank das attr userReadings zu setzen mit DbFileSize:reduceLogState.* { (split(' ',`du -m fhem.db`))[0] }
Dann mal in set ein reduceLog 3
Achtung !! die 3 bewirkt soweit alles gelöscht wird was älter als 3 Tage auf eigene Gefahr.
Nach einiger Zeit 1 - 2 Stunden den set Befehl wiederholen so sieht Du am geänderten Reading Wert DbFileSize was in der Zeit so aufgelaufen ist in MB.
Ein Tip hatte ich noch hier gefunden die Datenbank nicht selbst mit zu loggen mit attr DbLogExclude myDbLog.
myDbLog ist der Name meiner Datenbank.
Wie gesagt Thema ist auch nur Neuland für mich und stümpere erst mal nur und schau mal in Dein Log.
Gruß
Hans-Jürgen
Hallo Jens, @all,
das Dblog-device muss im asynchronen modus betrieben werden damit es non-blocking arbeitet und alle funktionen mit dem zusatz "nbl", die für sich genommen ebenfalls non-blocking designed sind, auch so funktionieren.
Hintergrund ist die arbeitsweise der datenbank eine tabelle in bestimmten situationen zu sperren. wird dann das dblog-device synchron betrieben und kann nicht in die db bzw. tabelle schreiben, blockiert fhem.
grüsse
Heiko
Hallo Amenophis,
Zitat@Heiko kannst du da mal Licht ins Dunkle bringen, damit ich es im Wiki entsprechend ändern kann :)
Der Code im Wiki ist tatsächlich falsch. Es wird das Reading "reduceLogState" angelegt und nicht "lastReduceLogResult".
Somit hat Hans-Jürgen recht und mit dem Code aus dem Wiki wird das userreading nicht funktionieren.
Grüße
Heiko
Alles klar, dank dir Heiko. Habe es auf DbFileSize:reduceLogState.* { (split(' ',`du -m fhem.db`))[0] } geändert.
Grüße Etienne