Hallo,
ich möchte von SQLite auf MySQL umsteigen und habe das Device mal konfiguriert. Da ich den Empfehlungen aus configCheck nachgehen möchte und auch den asyncMode aktiviert habe, habe ich festgestellt, dass dieser nicht funktioniert. CacheUsage steigt stetig an, es werden keine DB-Einträge geschrieben. Ohne asyncMode funktioniert es einwandfrei.
Es handelt sich um eine leere Testdatenbank, also da kann das Problem nicht liegen.
defmod logdb DbLog ./db.conf .*:(humidity|temperature|desired-temp|measured-temp|frequency|voltage).*
attr logdb DbLogType Current/History
attr logdb asyncMode 1
attr logdb bulkInsert 1
attr logdb cacheEvents 2
attr logdb cacheLimit 50
attr logdb room Zentrale
attr logdb showproctime 1
attr logdb syncEvents 1
attr logdb verbose 5
setstate logdb Commit already running - resync at NextSync
setstate logdb 2022-02-08 20:52:40 CacheOverflowLastNum 55
setstate logdb 2022-02-08 20:49:11 CacheOverflowLastState exceeded
setstate logdb 2022-02-08 20:52:40 CacheUsage 106
setstate logdb 2022-02-08 20:52:40 NextSync 2022-02-08 20:53:10 or if CacheUsage 50 reached
setstate logdb 2022-02-08 20:43:43 sql_processing_time 0.0703
setstate logdb 2022-02-08 20:52:40 state Commit already running - resync at NextSync
Der Status steht unverändert auf "Commit already running - resync at NextSync" - weder wenn das Limit von 50 Einträgen, noch die nächste Zeit eintritt, wird in die DB geschrieben. Der manuelle Befehl "commitCache" bewirkt auch nichts.
Stelle ich asyncMode auf 0, schreibt er sofort wieder brav in die DB, nur halt nicht asynchron...
@kamp
Ich nutze ebenfalls den asyncMode und es läuft reibungslos.
Ich verwende dabei cacheLimit 1000 und syncInterval 60; CacheOverflow tritt so gut wie nie auf.
Bei Dir könnte cacheLimit 50 das Problem verursachen, da sich die Schreibvorgänge scheinbar "überholen".
CacheUsage ist mit z.B. 106 auf jeden Fall deutlich höher als 50 ...
ich hatte es vorher mit dem Defaultwert 500 - auch hier steigen die Einträge im Chache stetig, es wird nie etwas abgebaut (Es kommen nur ca 2 Einträge pro 10 Sekunden dazu, da ich nur Temperaturwerte und Luftfeuchtigkeit logge zum testen). Hier dürfte es ihm also sicherlich nicht zu viel werden von der Menge her. Im Log steht auch nie etwas was auf einen Commit schließen lässt?
@kamp
Um mit Deinen Einstellungen zu "arbeiten", habe ich auf meinem Testsystem ein dblog eingerichtet - funktioniert problemlos.
defmod logdb DbLog ./DbLog.conf .*:(action|occupancy|water_leak):.*
attr logdb DbLogType Current/History
attr logdb asyncMode 1
attr logdb bulkInsert 1
attr logdb cacheEvents 2
attr logdb cacheLimit 50
attr logdb showproctime 1
attr logdb syncEvents 1
setstate logdb connected
setstate logdb 2022-02-09 12:30:24 CacheOverflowLastNum 0
setstate logdb 2022-02-09 12:25:24 CacheOverflowLastState normal
setstate logdb 2022-02-09 12:33:04 CacheUsage 0
setstate logdb 2022-02-09 12:33:04 NextSync 2022-02-09 12:33:34 or if CacheUsage 50 reached
setstate logdb 2022-02-09 12:30:25 background_processing_time 0.0426
setstate logdb 2022-02-09 12:32:59 countCurrent 4
setstate logdb 2022-02-09 12:32:59 countHistory 320
setstate logdb 2022-02-09 12:30:25 sql_processing_time 0.0132
setstate logdb 2022-02-09 12:33:04 state connected
Aufgefallen ist, dass bei Dir kein Reading background_processing_time auftaucht ... daher vermute ich mal, dass Du noch nie eine asynchrone Verarbeitung erfolgreich abschliessen konntest.
Zu Testzwecken hatte ich die Datenbank gestoppt ... der Cache wächst zwar langsam, aber stetig und verursacht regelmäßig fehlerhafte Sync-Versuche ... Neustart der Datenbank sorgt für raschen Cache-Abbau und nach kurzer Zeit läuft wieder alles normal.
Abschließend habe ich mir nochmals das Modul angesehen und dabei festgestellt, dass besagte Meldung u.a. abhängig vom Internal MODEL kommt: Bei mir steht MODEL auf "MYSQL"; steht Dein MODEL vielleicht noch weiterhin auf "SQLITE" ?
ZitatInternals:
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION ./db.conf
DEF ./db.conf .*:(humidity|temperature|desired-temp|measured-temp|frequency|voltage).*
FUUID 6021a34f-f33f-1b7d-6147-858752c52b52c21a
FVERSION 93_DbLog.pm:v4.12.6-s25478/2022-01-17
MODE synchronous
MODEL MYSQL
NAME logdb
NR 3
NTFY_ORDER 50-logdb
PID 413
REGEXP .*:(humidity|temperature|desired-temp|measured-temp|frequency|voltage).*
STATE connected
TYPE DbLog
UTF8 1
dbconn mysql:database=fhem;host=localhost;port=3306
dbuser fhemuser
HELPER:
COLSET 1
DEVICECOL 64
EVENTCOL 512
OLDSTATE connected
PACKAGE main
READINGCOL 64
TC current
TH history
TYPECOL 64
UNITCOL 32
VALUECOL 128
VERSION 4.12.6
READINGS:
2022-02-09 19:52:42 CacheOverflowLastNum 0
2022-02-08 21:55:08 CacheOverflowLastState normal
2022-02-08 21:47:51 countCurrent 33
2022-02-08 21:47:51 countHistory 931
2022-02-10 08:16:27 sql_processing_time 0.0336
2022-02-10 08:16:27 state connected
Attributes:
DbLogType Current/History
asyncMode 0
bulkInsert 1
cacheEvents 2
cacheLimit 1000
room Zentrale
showproctime 1
syncEvents 1
syncInterval 90
Das ist mein aktuelles device list. Ich sehe kein SQLITE mehr? (Dzt. läuft es auf synchronem Modus - da nur der funktioniert, den ich aber nicht unbedingt beibehalten möchte). Einen Fehler mit Mysql würde ich intuitiv ausschließen, denn dann würde der synchrone Modus auch keine Inserts machen können.
Meinst du, ein neues Device könnte helfen, oder ist das vergebene Mühe?
@kamp
Ich hatte Dein list mal mit meinem verglichen - sieht quasi identisch aus.
Hast Du schon mal FHEM neu gestartet ?
Wenn nein, würde ich das mal probieren ...
mehrmals, auch den LXC auf dem es läuft... auch der host wurde schon 4 mal neu gestartet seit ich das Problem erstmals identifiziert hatte.
kann es vielleicht an der mysql-version liegen?
ZitatServer version: 10.5.12-MariaDB-0+deb11u1 Debian 11
@kamp
Meine mysql-version könnte ich erst später nachschauen, da ich aktuell keinen Zugriff habe ...
Keine Ahnung, ob es helfen würde ... wenn Du keine DbLog-Attribute bei den FHEM-Geräten verwendest, würde ich einfach das logdb-Device löschen und komplett neu anlegen ...
@kamp
Mal nachgeschaut - ich verwende auf einem Pi 3B+:
Zitatmysql Ver 15.1 Distrib 10.3.17-MariaDB
Ganz weit auseinander scheinen die Versionsnummern nicht zu sein ...
Danke - habe das LogDB neu angelegt, jetzt bekomme ich zumindest eine Fehlermeldung:
ZitatProcess died prematurely
ich habe jetzt von LXC auf VM umgestellt (fhem 1:1 rüber kopiert) und in der VM funktioniert es einwandfrei...