FHEM läd extrem langsam

[DS_Starter]

Habe aber leider noch nichts gefunden, wie ich einzelne devices ausschließen kann oder nur bestimmte Devices loggen kann.

Es gibt verschiedene Möglichkeiten. Die Beschränkung im DEF wie bei Filelog, aber auch über die Attribute DbLogInclude oder
DbLogExclude in den Quelldevices. Dazu unbedingt das Attribut DbLogSelectionMode im DbLog beachten.

Ich empfehle dringend die commadref zu DbLog durchzulesen um zu verstehen wie was arbeitet.

Für den Anfang ist vermutlich am einfachsten direkt im DEF (Regex) die Einschränkung vorzunehmen. z.B.:

Code Auswählen Erweitern

define DbLog DbLog ./db.conf (<device>:temperature|<device>:humidity|<device>:dewpoint|<device>:absFeuchte|<device>:pressure|<device>:open|<device>:closed|<device>:ValvePosition)

Benötigt man DbLog eigentlich noch für etwas anderes oder "nur" um Plots grafisch anzeigen zu können?

Um einfach nur Plots anzuzeigen kann man FileLog und DbLog gleichermaßen verwenden. Wenn man viele Daten auch über längere Zeit speichern will, bietet sich DbLog an. Ebenfalls für weitere Auswertungen (siehe DbRep) und das relative einfache Datenmanagement, wie das (selektive) Löschen von Daten die man nicht mehr braucht oder das Ausdünnen um nur Wichtiges zu behalten oder,oder ...

DbLog hat viele Vorteile, aber auch Nachteile. So sollte man sich ein bisschen mit Datenbanken beschäftigen, speziell sich auch um ein Backupkonzept Gedanken machen.
Und meistens braucht eine DB auch entsprechend leistungsfähige Hardware, wobei SQLite dabei sehr genügsam ist gegenüber "richtigen" DB-Systemen wie MySQL und PostgreSQL.

Jetzt zu deinem System. Hast du ein Update gemacht ? Wenn noch nicht, bitte machen.

Code Auswählen Erweitern


WEB: plotfork=0
Recommendation: You should set attribute "plotfork = 1" in relevant devices

Für die Schreibperformance ist das Attr asyncMode wichtig. Für die Erstellung der SVGs ist plotfork = 1 im deinem WEB Device wichtig. Wenn plotfork = 1 gesetzt ist, werden die SVG-Daten aus der DB in einem Nebenprozess gelesen was die Performance unabhängig von der DB-Schnelligkeit macht.
Dazu auch das Attr plotEmbed im WEB beachten !

Code Auswählen Erweitern

Column width set in DB /opt/fhem/fhem.db.history: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 64, 'UNIT' = 32
Column width used by DbLog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: WARNING - The relation between column width in table history and the field width used by device DbLog should be equal but it differs.The field width used by DbLog can be adjusted by setting attributes 'colEvent', 'colReading', 'colValue'. (pls. refer to commandref)Because you use SQLite this is only a warning. Normally the database can handle these differences.

Das ist im Umfeld SQLite eher eine Warnung. Hast vermutlich nicht das aktuellste Script zur Erstellung der DB verwendet. Der Link zum aktuellen Script ist in der Commandref zu DbLog angegeben. Wenn es sich anbietet, löscht du DB nochmal und erstellst sie neu. Ist aber ein "kann".

Code Auswählen Erweitern


The index 'Search_Idx' is missing.
Recommendation: You can create the index by executing statement 'CREATE INDEX Search_Idx ON `history` (DEVICE, READING, TIMESTAMP)'

Das ist ganz bitter. Ohne Index wird deine DB nicht vernünftig laufen !
Du kannst den Index über die Befehlszeile anlegen oder benutzt ein angelegtes DbRep-Device dazu:

Code Auswählen Erweitern

set <dbrep> index recreate_Search_Idx

Wenn du das alles gemacht hast, nochmal ein configCheck ausführen.
Unnütze DB-Einträge von Devices oder Readings wirst du mit den entsprechnden Befehlen in einem DbRep-Device einfach wieder los.

Grüße,
Heiko

[Ruggy]

Update habe ich gestern noch gemacht.
Hat aber keine spürbare Verbesserung gebracht.

Eine Einschränkung für jedes device wird evlt. unübersichtlich aber ist wahrscheinlich die sicherste Methode. Müsste also bei define für jeden Sensor alle benötigten Werte einzeln zum loggen befehlen?

Habe den Hinweis von MadMax-FHEM bzgl. event-on-change-reading gestern irgendwie ein paar Mal überlesen. Ist bestimmt auch sinnvoll. Muss ich dies bei jedem Sensor setzen?


Habe jetzt gerade plotfork = 1 gesetzt und den index erstellt.


-> ist der Wahnsinn wie schnell es jetzt ist. So schnell war es glaube ich noch nie 
Das gefällt mir schon mal sehr gut. Danke
Bedeutet dies, dass die "bremse" meine schlechte Datenbank war?

Wird der Index ab jetzt immer automatisch erstellt oder muss ich diesen hin und wieder manuell erstellen?


Die anderen vorgeschlagenen Dinge habe ich noch nicht gemacht, weil ich manches noch nicht verstehe wie ich es machen muss.
Werde mich darüber machen.
Das DbRep-Device muss ich erst mal Verstehen. Muss man anscheinend erst erstellen bzw. anlegen?


Das sagt configCheck

Code Auswählen Erweitern

Result of version check

Used Perl version: 5.24.1
Used DBI (Database independent interface) version: 1.636
Used DBD (Database driver) version SQLite: 1.54
Used DbLog version: 4.7.4.
Your local DbLog module is up to date.
Recommendation: No update of DbLog is needed.

Result of configuration read check

Connection parameter store type: file
Connection parameter: Connection -> SQLite:dbname=/opt/fhem/fhem.db, User -> , Password -> read o.k.

Result of connection check

Connection to database /opt/fhem/fhem.db successfully done.
Recommendation: settings o.k.

Result of encoding check

Encoding used by DB /opt/fhem/fhem.db: UTF-8
Recommendation: This is only an information about text encoding used by the main database.

Result of logmode check

Logmode of DbLog-device DbLog is: asynchronous
Recommendation: settings o.k.

Result of plot generation method check

WEB: plotfork=1
Recommendation: settings o.k.

Result of table 'history' check

Column width set in DB history: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 64, 'UNIT' = 32
Column width used by DbLog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: WARNING - The relation between column width in table history and the field width used by device DbLog should be equal but it differs.The field width used by DbLog can be adjusted by setting attributes 'colEvent', 'colReading', 'colValue'. (pls. refer to commandref)Because you use SQLite this is only a warning. Normally the database can handle these differences.

Result of table 'current' check

Column width set in DB current: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 64, 'UNIT' = 32
Column width used by DbLog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: WARNING - The relation between column width in table current and the field width used by device DbLog should be equal but it differs. The field width used by DbLog can be adjusted by setting attributes 'colEvent', 'colReading', 'colValue'. (pls. refer to commandref)Because you use SQLite this is only a warning. Normally the database can handle these differences.

Result of check 'Search_Idx' availability

The index 'Search_Idx' is missing.
Recommendation: You can create the index by executing statement 'CREATE INDEX Search_Idx ON `history` (DEVICE, READING, TIMESTAMP)'
Depending on your database size this command may running a long time.
Please make sure the device 'DbLog' is operating in asynchronous mode to avoid FHEM from blocking when creating the index.
Note: If you have just created another index which covers the same fields and order as suggested (e.g. a primary key) you don't need to create the 'Search_Idx' as well !


Result of check 'Report_Idx' availability for DbRep-devices

No DbRep-device assigned to DbLog is used. Hence an index for DbRep isn't needed.
Recommendation: settings o.k.


[MadMax-FHEM]

event-on-change-reading (und "Derivate") dämmen generell die "Flut" von Events ein...

D.h. das System muss generell weniger tun und ja: bei jedem Sensor (im Prinzip / allerdings reicht es [erst mal] bei den "Geschwätzigsten" -> Eventmonitor / es gibt auch die Möglichkeit sich durch DOIF-Tools Events pro Device "zählen" zu lassen)

Wichtig ist halt die Einschränkung so zu machen, dass nur unnötige Events wegfallen...

Und wie bereits geschrieben: da kann man immer wieder mal ran und optimieren...

Wichtig ist dabei: genau lesen!

Bzw. immer mal einen Blick in den Eventmonitor um zu sehen, ob "wichtige" Events noch kommen (oder plötzlich "weg" sind)...

Gruß, Joachim

[DS_Starter]

Update habe ich gestern noch gemacht.
Hat aber keine spürbare Verbesserung gebracht.

Das ist klar. Es sollte nur aktuell sein. (auch wegen configCheck) 

Habe den Hinweis von MadMax-FHEM bzgl. event-on-change-reading gestern irgendwie ein paar Mal überlesen. Ist bestimmt auch sinnvoll. Muss ich dies bei jedem Sensor setzen?

Ist sinnvoll, wie Joachim schon schrieb. Musst du in jedem Device bzw. Reading setzen wo du es haben willst.
Aber hier nochmal der Hinweis, es gibt den "DbLogSelectionMode  = Include" -Modus ! In dem Modus wird überhaupt nichts geloggt außer das was man explizit über DbLogInclude in den Quelldevices freigibt.
Ich kann verstehen, dass du erstmal heiß auf Ergebnisse bist, aber unbedingt commandref lesen !! 

Habe jetzt gerade plotfork = 1 gesetzt und den index erstellt.

-> ist der Wahnsinn wie schnell es jetzt ist. So schnell war es glaube ich noch nie 
Das gefällt mir schon mal sehr gut. Danke
Bedeutet dies, dass die "bremse" meine schlechte Datenbank war?

Sehr gut.    ... Und ja, an der richtigen Einstellung der DB bzw. dem Gesamtwerk lag es. Eine DB ist nicht nur ein File. Und eine DB ist für "Massendaten" gemacht, will damit sagen dass es normalerweise nicht auf ein paar tausend Datensätze mehr oder weniger ankommt. Dafür ist diese Technik gemacht. Den "configCheck" kann man immer mal wiederholen.

Wird der Index ab jetzt immer automatisch erstellt oder muss ich diesen hin und wieder manuell erstellen?

Im Normalfall braucht man den Index in useren Fällen nicht nochmal erstellen. Aber selbst das geht mit einem DbRep-Befehl sehr einfach.

Das sagt configCheck:
....
The index 'Search_Idx' is missing.
.....

Das wundert mich allerdings. War die Indexerstellung noch nicht durch oder hast du den check vorher gemacht ?

Das DbRep-Device muss ich erst mal Verstehen. Muss man anscheinend erst erstellen bzw. anlegen?

Ja, musst du einfach definieren. Im Wiki findest du auch jede Menge Infos und Hilfe: https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten

Denke auch an ein Backup deiner DB ! Auch dafür gibts Befehle im DbRep.

[Ruggy]

bzgl. The index 'Search_Idx' is missing habe ich wie im wiki-fhem zu DbLog und dort bei "Erstellung von Indizes" beschrieben folgenden Befehl (in der fhem.db) ausgeführt:

Code Auswählen Erweitern

create index idx_device_reading_timestamp on history (device, reading, timestamp);

War das nicht richtig?


Folgender Befehl zeigte bei mir keine Reaktion.

Code Auswählen Erweitern

set <dbrep> index recreate_Search_Idx

ein aktuelles config Check zeigt immer noch "The index 'Search_Idx' is missing" an.

[DS_Starter]

War das nicht richtig?

Nicht direkt. Der Name ist falsch und wird nicht gefunden.

Folgender Befehl zeigte bei mir keine Reaktion.

Der Befehl läuft eine Weile je nach Größe der DB.
Schreibt in status und Logfile.

Was schreibt DbRep denn aus mit:

Code Auswählen Erweitern

set .... index list_all

?

Müßte etwa so aussehen:

Code Auswählen Erweitern


background_processing_time

0.0094

2019-10-07 23:19:14
index_state


Index found in database:
========================
Table: history, Idx: Search_Idx, Col: DEVICE, READING, TIMESTAMP


2019-10-07 23:19:14
sql_processing_time

0.0043

2019-10-07 23:19:14
state

done

2019-10-07 23:19:14


EDIT: Hinweis, bei DbRep immer mal die Browserseite refreshen.