ElectricityCalculator und DBLog blockieren FHEM - Bitte um Hilfe!

Begonnen von cruser1800, 21 Oktober 2018, 21:20:16

Vorheriges Thema - Nächstes Thema

cruser1800

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

DS_Starter

#1
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".

ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

cruser1800

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

DS_Starter

Zitathabe ich folgendes erhalten, ich hoffe es war richtig!

Na fast  ;) ... "set ... configCheck". Bitte nochmal ... aber ich sehe es schon ...
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

cruser1800

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 !

DS_Starter

#5
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
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

cruser1800

Danke erst mal.

Ich beobachte es mal. Das mit den Feldern habe ich auch bemerkt und bin schon dabei es zu ändern.

DS_Starter

Ok, melde dich einfach wieder falls noch Fragen zu DbLog aufkommen.

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

cruser1800

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?

DS_Starter

#9
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 = 1

Weiterhin 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.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

cruser1800

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!

DS_Starter

ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter