DBLOG: sqlite Another operation is in progress - resync at NextSync

Begonnen von Hadl, 17 März 2026, 15:14:49

Vorheriges Thema - Nächstes Thema

Hadl

Hallo, ich nutze dblog mit einer mittlerweile großen sqlite Datenbank.
defmod logdb DbLog ./db.conf .*:.*
attr logdb DbLogType Current/History
attr logdb asyncMode 1
attr logdb cacheLimit 1000
attr logdb cacheOverflowThreshold 20000
attr logdb event-min-interval .*:3600
attr logdb event-on-change-reading .*
attr logdb room Log
attr logdb showproctime 1
attr logdb syncInterval 120

Das funktioniert meistens super, aber manchmal hängt sich das dblog auf und schreibt nichtsmehr in die Datenbank, bisher half dann nur ein fhem neustart. (Problem 1)
dblog ist dabei auf folgenden Status:
Zitatsqlite Another operation is in progress - resync at NextSync

Dabei werden dann die Daten beim Cache überlauf in ein Cache file geschrieben, welches dann aber (scheinbar) sofort wieder mit ner Null Byte Datei überschrieben wird. (Problem 2)
Zitat2026.03.17 14:13:33 2: logdb - WARNING - Cache is exported to file instead of logging it to database
2026.03.17 14:13:33 3: logdb - 20412 Cache rows exported to ./log/cache_logdb_2026-03-17_14-13-33
2026.03.17 14:13:33 3: logdb - Cache purged after exporting rows to ./log/cache_logdb_2026-03-17_14-13-33.
2026.03.17 14:13:33 2: logdb - WARNING - Cache is exported to file instead of logging it to database
2026.03.17 14:13:33 3: logdb - 0 Cache rows exported to ./log/cache_logdb_2026-03-17_14-13-33
2026.03.17 14:13:33 3: logdb - Cache purged after exporting rows to ./log/cache_logdb_2026-03-17_14-13-33.
Beim Versuch des Imports - der 0 Byte Datei - kommen dann natürlich keine Datensätze raus.
STATE: importCachefile finished, 0 datasets were imported

Das System ist ein Rpi 5 mit einer 1TB M.2 SSD

Hat jemand eine Idee was das sein könnte, oder wie ich das Problem weiter untersuchen könnte?

Vielen Dank

Hadl
FHEM: Rpi 5 + SSD / WR: Fronius Symo Gen24 10.0 Plus + BYD HVS 7.7, Fronius Symo Gen24 12.0 SC (60%) PV: (Ost=3.5 West=6.6 Nord=9.9 Ost=4.5) / Homematic BidCoS / Shelly / Viessmann

DS_Starter

Hallo Hadl,

ich gehe ganz stark davon aus, dass deine DB zu langsam ist um die anfallende Datenmenge im Block zu verarbeiten.
Schau dir das Reading sql_processing_time an. Normalerweise liegt das im ms Bereich (0.0866 s bei mir (MariaDB)).

Wahrscheinlich ist die Zeit bei dir sehr hoch und der Schreibprozess ist noch nicht fertig wenn der nächste starten will.
Möglicherweise hilft es dir auf synchron umzustellen um jeden Event sofort wegzuschreiben oder eine Einstellung des attr insertMode.

Aber das grundlegende Problem wird die DB-Zeit sein. Dort müsstest du ansetzen.

Grüße,
Heiko
Proxmox+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

Hadl

Hallo Heiko,
ja, über den Zeiten bin ich natürlich drüber, weil ich immer 1000 Einträge auf einmal schreibe.
Damit hab ich ne sql_processing_time von 1.0-1.8s
Das ging für mich so in Ordnung, denn das passiert ja nur alle ca. 2 Minuten einmal.

In Summe war das deutlich effizienter als jedes mal wegen ein paar Daten die ganze Datenbank inkl. Index Tabelle neu schreiben zu müssen.

Wenn aber das Problem auftritt dann steigt der Cache bis 20000 Elemente an was immer mindestens 40 Minuten dauert.
Dann wird der Cache geschrieben (mit Problem 2), aber die Datenbank bleibt blockiert.
Über mehrere Stunden wird so nichts in die DB geschrieben, bis ich fhem neu starte.

Syncron hatte ich am Anfang als Einstellung, das wurde dann aber schnell zu langsam und hat mir zusätzlich die damals noch verwendete SD Karte schnell über den Jordan gebracht. (Asche auf mein Haupt, ich weis ja das man das nicht macht, aber nur Versuch macht klug ;) )

insertMode als Array hört sich für mich richtig an, um nur einmal alle paar Minuten den Index schreiben zu müssen und nicht wegen jedem Eintrag extra. OK die SSD sollte nun mehr aushalten, aber kann das wirklich ne Verbesserung bewirken?

Was vermutest du, das die Blockade ist, warum über Stunden der Status "Another operation is in progress - resync at NextSync" besteht?

Hadl

FHEM: Rpi 5 + SSD / WR: Fronius Symo Gen24 10.0 Plus + BYD HVS 7.7, Fronius Symo Gen24 12.0 SC (60%) PV: (Ost=3.5 West=6.6 Nord=9.9 Ost=4.5) / Homematic BidCoS / Shelly / Viessmann

DS_Starter

ZitatinsertMode als Array hört sich für mich richtig an, um nur einmal alle paar Minuten den Index schreiben zu müssen und nicht wegen jedem Eintrag extra. OK die SSD sollte nun mehr aushalten, aber kann das wirklich ne Verbesserung bewirken?
Ausprobieren ...

ZitatWas vermutest du, das die Blockade ist, warum über Stunden der Status "Another operation is in progress - resync at NextSync" besteht?
Ich vermute es gibt bei dir Situationen gibt wo die Reaktionszeit/Schreibgeschwindigkeit derart schlecht ist, dass die ersten 1000  Einträge noch nicht geschrieben sind wenn die nächsten aus dem Cache in die DB sollen. Der Cache baut sich evtl. auf 1500 auf die dann im Block in die DB sollen was dann noch länger dauert.
Und so kann sich die Sutuation aufschaukeln bis es zum Überlauf kommt. Wie gesagt ... Theorie.

Du kannst dir sql_processing_time und CacheUsage in ein Filelog! loggen und kannst so vllt. über die Laufzeit einen Überblick erhalten wie sich die Situation entwickelt. Es gibt auch die Möglichkeit über attr SQLiteCacheSize bedingt Einfluß auf die Performance zu nehmen, genug RAM vorausgesetzt.
Proxmox+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