DBLogging reduceLogNbl tut nichts?

[Nicees]

Hello zusammen!

Aufgrund einiger Probleme, konnte wohl möglich das tägliche reduceLogNbl für 2-3 Tage nicht anstarten, weshalb ich es heute einmal manuell triggern wollte. Dabei fiel mir auf, dass nach Ausführung des Befehls kein wirkliches Feedback von FHEM zurückkommt und ich bin aktuell ein wenig unschlüssig, ob es erfolgreich war

Normalerweise dürfte im Log doch zurückkommen, dass der Task erfolgreich war mit Angabe der durchlaufenden Rows etc.?

Folgendes Beispiel-Szenario:
1.

Code Auswählen Erweitern

set reduceLogNbl 1
2. Im Log sehe ich dann

Code Auswählen Erweitern

2021-09-09 17:56:49 DbLog DBLogging reduceLogState: reduceLogNbl 1 started
3. Auf meinem NAS, wo die DB läuft, fängt es hörbar an zu rödeln und die Volume-Auslastung geht nachweislich für etwa 30-60s hoch
4. Anschließend verstummt das NAS, Last geht runter, und selbst nach Stunden des Wartens sehe ich im Reading von DBLogging kein "reduceLog finished" o.Ä.

Code Auswählen Erweitern

set configCheck zeigt folgendes:

Result of version checkUsed Perl version: 5.28.1 Used DBI (Database independent interface) version: 1.642 Used DBD (Database driver) version mysql: 4.050 Used DbLog version: 4.10.2.A new DbLog version is available (creation time: 2021-05-16_07:45:04, size: 457912 bytes) Recommendation: You should update FHEM to get the recent DbLog version from repository ! Your DBD version fulfills UTF8 support, no need to update DBD. Result of configuration read checkConnection parameter store type: file Connection parameter: Connection -> mysql:database=fhem;host=192.168.1.23;port=3307, User -> fhemdb, Password -> read o.k. Result of connection checkConnection to database fhem successfully done. Recommendation: settings o.k. Result of encoding checkEncoding used by Client (connection): LATIN1 Encoding used by DB fhem: UTF8 Recommendation: Both encodings should be identical. You can adjust the usage of UTF8 connection by setting the UTF8 parameter in file '/opt/fhem/contrib/dblog/db.conf' to the right value. Your DBD version fulfills UTF8 support, no need to update DBD. Result of logmode checkLogmode of DbLog-device DBLogging is: asynchronous Recommendation: settings o.k. Result of insert mode checkInsert mode of DbLog-device DBLogging is: Array Recommendation: Setting attribute "bulkInsert" to "1" may result a higher write performance in most cases. Feel free to try this mode. Result of plot generation method checkWEB: plotfork=1 / plotEmbed=2Recommendation: settings o.k. Result of table 'history' checkColumn width set in DB history: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 255, 'UNIT' = 32 Column width used by DBLogging: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32 Recommendation: settings o.k. Result of table 'current' checkColumn width set in DB current: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 255, 'UNIT' = 32 Column width used by DBLogging: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32 Recommendation: settings o.k. Result of check 'Search_Idx' availabilityThe index 'Search_Idx' is missing. Recommendation: You can create the index by executing statement 'CREATE INDEX Search_Idx ON `history` (DEVICE, READING, TIMESTAMP) USING BTREE;' Depending on your database size this command may running a long time. Please make sure the device 'DBLogging' 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 'Search_Idx' as well ! Result of check 'Report_Idx' availability for DbRep-devicesNo DbRep-device assigned to DBLogging is used. Hence an index for DbRep isn't needed. Recommendation: settings o.k.

ASync mode ist an.

Ich stehe gerade ein wenig auf'm Schlauch. Hat jemand eine Idee wie ich noch herausfinden könnte, woran es hakt? Oder wo mein Denkfehler liegt?


Danke & Grüße
Nic

[DS_Starter]

Hallo Nic,

stelle dein DbLog-Device auf verbose 4 und führe das reduceLogNbl  wieder aus.
Vllt. sieht man dann mehr.
Achte auch auf evtl. Fehlermeldungen im Log.

Grüße,
Heiko

[Nicees]

Hallo Heiko,

verbose habe ich auf 4 gestellt und am Ende folgendes Resultat erhalten:

Code Auswählen Erweitern

reduceLogState reduceLogNbl finished. Rows processed: 1877796, deleted: 488869, time: 2613.00sec 2021-09-09 22:21:24

Sehr seltsam... heute 5x probiert, 2x sogar etwa 4h gewartet, da ist nichts passiert. Auf verbose 4 gestellt, und schon lief es sauber durch... ?! ?! ?! Mein NAS hat sogar die ganze Zeit "durchgerödelt" und nicht nach 30-60s aufgehört.

Ich versteh die Welt nicht mehr. War es der "Vorführeffekt" oder kann verbose tatsächlich Einfluss auf die eigentliche Funktionalität haben?

Cheers!
Nic

[DS_Starter]

Merkwürdiges Verhalten.
Also einen Einfluss des verbose Levels auf das Ergebnis kann man ausschließen, das ist eine FHEM Zentralroutine.

Eine Erklärung habe ich aber auch nicht.
Schaue doch mal im Log ob du dort irgendwelche Fehler siehst wenn du mit deinem normalen verbose arbeitest.