DBLog Mysql - asyncMode funktioniert nicht

[kamp]

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.

Code Auswählen Erweitern

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...

[OdfFhem]

@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 ...

[kamp]

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?

[OdfFhem]

@kamp

Um mit Deinen Einstellungen zu "arbeiten", habe ich auf meinem Testsystem ein dblog eingerichtet - funktioniert problemlos.

Code Auswählen Erweitern


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" ?

[kamp]

Internals:
   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?

[OdfFhem]

@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 ...

[kamp]

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?

Server version: 10.5.12-MariaDB-0+deb11u1 Debian 11

[OdfFhem]

@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 ...

[OdfFhem]

@kamp

Mal nachgeschaut - ich verwende auf einem Pi 3B+:

mysql  Ver 15.1 Distrib 10.3.17-MariaDB

Ganz weit auseinander scheinen die Versionsnummern nicht zu sein ...

[kamp]

Danke - habe das LogDB neu angelegt, jetzt bekomme ich zumindest eine Fehlermeldung:

Process died prematurely

[kamp]

ich habe jetzt von LXC auf VM umgestellt (fhem 1:1 rüber kopiert) und in der VM funktioniert es einwandfrei...