Hallo,
nachdem mein System in letzter Zeit sehr träge reagiert hat bin ich auf die Suche gegangen. Eine extreme Sache, die mir aufgefallen ist, wenn der ElectricityCalculator bei Änderungen in die Datenbank geschrieben wird!
Die Auswertung von apptime mit schreiben der Werte in die Datenbank deaktiviert!
ElectricityCalculator ElectricityCalculator_Notify 17 1 17.32 17.32 0.00 0.00 21.10. 21:02:40 HASH(ElectricityCalculator); HASH(Stromzaehler)
Die Auswertung von apptime mit schreiben der Werte in die Datenbank aktiviert!
ElectricityCalculator ElectricityCalculator_Notify 33201 1 33201.14 33201.14 0.00 0.00 21.10. 21:06:04 HASH(ElectricityCalculator); HASH(Stromzaehler)
Der Wert average ist deutlich der Hinweis auf das blockieren von FHEM. Ohne schreiben der Daten in die Datenbank kommt es zu keinem Blockieren!
Die Einstelluingen fürs loggen sind:
event-on-change-reading .*
DbLogInclude .*
Die Probleme sind erst in der letzten Zeit aufgetreten. Diese Konfiguration habe ich aber schon seit Jahren!
Hat jemand ein Tip für mich?
Danke
ZitatDie Probleme sind erst in der letzten Zeit aufgetreten. Diese Konfiguration habe ich aber schon seit Jahren!
Dann zeig doch mal bitte ein list von deinem DbLog-Device und einen Ausdruck von "get <name> configCheck".
Hier das List:
Internals:
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION ./db.conf
DEF ./db.conf .*:.*
MODE synchronous
MODEL MYSQL
NAME logdb
NR 211
NTFY_ORDER 50-logdb
PID 28776
REGEXP .*:.*
STATE connected
TYPE DbLog
UTF8 0
VERSION 3.12.2
dbconn mysql:database=DBLog;host=localhost;port=3306
dbuser fhemuser
HELPER:
COLSET 1
DEVICECOL 64
EVENTCOL 512
OLDSTATE connected
READINGCOL 64
TYPECOL 64
UNITCOL 32
VALUECOL 128
Helper:
DBLOG:
state:
logdb:
TIME 1540151455.72334
VALUE connected
READINGS:
2018-10-01 03:06:18 reduceLogState Rows processed: 2698514, deleted: 265233, updated: 26146, time: 378.12sec
2018-10-21 21:56:10 state connected
cache:
index 0
Attributes:
DbLogSelectionMode Exclude/Include
DbLogType Current/History
room Datenbank
verbose 3
Für 'get logdb configCheck' habe ich folgendes erhalten, ich hoffe es war richtig!
Usage: get logdb <in> ...
where column_spec is :::
see the #DbLog entries in the .gplot files
is not used, only for compatibility for FileLog, please use -
is a prefix, - means stdout
Zitathabe ich folgendes erhalten, ich hoffe es war richtig!
Na fast ;) ... "set ... configCheck". Bitte nochmal ... aber ich sehe es schon ...
Jetzt mit set:
Result of DbLog version check
Used DbLog version: 3.12.2
Recommendation: Your running version may be the current one. Please check for updates of DbLog periodically.
Result of configuration read check
Connection parameter store type: file
Connection parameter: Connection -> mysql:database=DBLog;host=localhost;port=3306, User -> fhemuser, Password -> read o.k.
Result of connection check
Connection to database DBLog successfully done.
Recommendation: settings o.k.
Result of encoding check
Encoding used by Client (connection): LATIN1
Encoding used by DB DBLog: LATIN1
Recommendation: settings o.k.
Result of logmode check
Logmode of DbLog-device logdb is: synchronous
Recommendation: Switch logdb to the asynchronous logmode by setting the 'asyncMode' attribute. The advantage of this mode is to log events non-blocking.
There are attributes 'syncInterval' and 'cacheLimit' relevant for this working mode.
Please refer to commandref for further informations about these attributes.
Result of plot generation method check
WARNING - at least one of your FHEMWEB devices have attribute "plotfork = 1" not set. This may cause blocking situations when creating plots.
WEB: plotfork=0
WEBphone: plotfork=0
WEBtablet: plotfork=0
Recommendation: You should set attribute "plotfork = 1" in relevant devices
Result of table 'history' check
Column width set in DB DBLog.history: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 32, 'UNIT' = 32
Column width used by logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: The relation between column width in table history and the field width used in device logdb don't meet the requirements. Please make sure that the width of database field definition is equal or larger than the field width used by the module. Compare the given results.
Currently the default values for field width are:
DEVICE: 64
TYPE: 64
EVENT: 512
READING: 64
VALUE: 128
UNIT: 32
You can change the column width in database by a statement like 'alter table history modify VALUE varchar(128);' (example for changing field 'VALUE'). You can do it for example by executing 'sqlCmd' in DbRep or in a SQL-Editor of your choice. (switch logdb to asynchron mode for non-blocking).
Alternatively the field width used by logdb can be adjusted by setting attributes 'colEvent', 'colReading', 'colValue'. (pls. refer to commandref)
Result of table 'current' check
Column width set in DB DBLog.current: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 32, 'UNIT' = 32
Column width used by logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: The relation between column width in table current and the field width used in device logdb don't meet the requirements. Please make sure that the width of database field definition is equal or larger than the field width used by the module. Compare the given results.
Currently the default values for field width are:
DEVICE: 64
TYPE: 64
EVENT: 512
READING: 64
VALUE: 128
UNIT: 32
You can change the column width in database by a statement like 'alter table current modify VALUE varchar(128);' (example for changing field 'VALUE'). You can do it for example by executing 'sqlCmd' in DbRep or in a SQL-Editor of your choice. (switch logdb to asynchron mode for non-blocking).
Alternatively the field width used by logdb can be adjusted by setting attributes 'colEvent', 'colReading', 'colValue'. (pls. refer to commandref)
Result of check 'Search_Idx' availability
Index 'Search_Idx' exists and contains recommended fields 'DEVICE', 'READING', 'TIMESTAMP'.
Recommendation: settings o.k.
Result of check 'Report_Idx' availability for DbRep-devices
At least one DbRep-device assigned to logdb is used, but the recommended index 'Report_Idx' is missing.
Recommendation: You can create the index by executing statement 'CREATE INDEX Report_Idx ON `history` (TIMESTAMP, READING) USING BTREE;'
Depending on your database size this command may running a long time.
Please make sure the device 'logdb' 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 'Report_Idx' as well !
Jetzt müsstest du es evtl. schon gesehen haben ..
Logmode of DbLog-device logdb is: synchronous
Recommendation: Switch logdb to the asynchronous logmode by setting the 'asyncMode' attribute. The advantage of this mode is to log events non-blocking.
There are attributes 'syncInterval' and 'cacheLimit' relevant for this working mode.
Please refer to commandref for further informations about these attributes.
Der synchrone Modus bringt auf jeden Fall blocking Situationen wenn deine DB nicht schnell genug ist.
Um die Auswirkung erstmal los zu werden, zunächst das Attribut "asyncMode = 1" setzen.
Danach wieder "set logdb configCheck" ausführen und das tun was vorgeschlagen wird.
Die andere Sache:
WEB: plotfork=0
WEBphone: plotfork=0
WEBtablet: plotfork=0
Recommendation: You should set attribute "plotfork = 1" in relevant devices
wäre sicherlich auch gut. Es hängt aber davon ab wieviel RAM du hast. Kann sonst auch kontraproduktiv sein.
EDIT: Deine Felddefinitionen sind auch nicht mehr up-to-date. Die solltest du auch anpassen wie empfohlen sonst kannst du auch Fehler bekommen. Das hat aber mit dem jetzigen Problem nichts zu tun
Danke erst mal.
Ich beobachte es mal. Das mit den Feldern habe ich auch bemerkt und bin schon dabei es zu ändern.
Ok, melde dich einfach wieder falls noch Fragen zu DbLog aufkommen.
Grüße,
Heiko
FHEM läuft jetzt wieder flüssig!
Danke
Jetzt habe ich festgestellt, dass Smartvisu keine Daten mehr erhält, um ein Graf darzustellen!
Hast du vielleicht auch dafür eine Lösung?
ZitatFHEM läuft jetzt wieder flüssig!
Das ist schonmal gut. Jetzt müsstest du eigentlich noch herausbekommen weshalb deine DB so langsam ist.
Um zu sehen wie schnell (oder langsam) deine DB arbeitet, setze dir das Attribut
showproctime = 1Weiterhin würde ich dir zur weiteren Untersuchung bzw. Optimierung das Tool MySQLTuner empfehlen:
https://github.com/major/MySQLTuner-perl
Zu Smartvisu kann ich dir addHoc nichts sagen. Funktionieren denn deine SVG-Grafen falls du welche hast ?
Möglicherweise ist deine träge Datenbank auch hier die Ursache wenn Daten zuuu lange nicht geliefert werden (timeout).
Du kannst ja mal einen einfachen SVG-Plot anlegen.
M. Meinung nach solltest du die Ursache für deine lahme DB versuchen herauszufinden und zu beseitigen.
Danke für deine Hilfe! Habe mal mit einem anderen Gerät probiert. Es lag an den Rechten in Fronthem! Also mit der Datenbankanbindung ist alles ok!
:)