[GELÖST] Fhem Absturz mit DBLog Fehler

[DS_Starter]

Ja habe ich, trotzdem gibt es die Fehler, allerdings hat reduceLogNblndie fhem.db verkleinert, also der Zugriff auf die DB an sich scheint wieder zu funktionieren

Ja, gebe dir recht weil auch auch der configCheck weiter oben funktioniert hat.
Da fehlt mir momentan eine Idee was noch stören könnte.

Stelle mal bitte auf asynchronen Betrieb um.

[DS_Starter]

Setzt mal bitte verbose 3 und führe ein FHEM-Restart durch.
Beim Start solltest du im Log diese Meldung, oder aber diesbezügliche Fehlermeldungen sehen:

Code Auswählen Erweitern


2018.01.11 18:35:59.035 3: DbLog LogSQLITE: Creating Push-Handle to database SQLite:dbname=/opt/fhem/fhem.db with user
2018.01.11 18:35:59.044 3: DbLog LogSQLITE: Push-Handle to db SQLite:dbname=/opt/fhem/fhem.db created


VG

[Tommy82]

Guten Morgen,
ich hatte gestern keine Zeit mich um Fhem zu kümmern, aber es scheint auch so als ob sich sachen von alleine lösen, heute Morgen habe ich nicht einen Log eintrag, und die DBLOG scheint Problemlos zu laufen.

Code Auswählen Erweitern

Internals:
   COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
   CONFIGURATION /opt/fhem/db.conf
   DEF        /opt/fhem/db.conf .*:.*
   MODE       synchronous
   MODEL      SQLITE
   NAME       myDbLog
   NR         251
   NTFY_ORDER 50-myDbLog
   PID        15496
   REGEXP     .*:.*
   STATE      connected
   TYPE       DbLog
   VERSION    3.6.0
   dbconn     SQLite:dbname=/media/Platte/home/fhem.db
   dbuser     
   HELPER:
     COLSET     1
     DEVICECOL  64
     EVENTCOL   512
     OLDSTATE   connected
     READINGCOL 64
     TYPECOL    64
     UNITCOL    32
     VALUECOL   128
   Helper:
     DBLOG:
       countCurrent:
         myDbLog:
           TIME       1515732605.50288
           VALUE      1677
       countHistory:
         myDbLog:
           TIME       1515732605.4518
           VALUE      159724
       lastRowsDeleted:
         myDbLog:
           TIME       1515718920.31242
           VALUE      0
       state:
         myDbLog:
           TIME       1515705070.97567
           VALUE      connected
   READINGS:
     2018-01-10 22:12:29   CacheUsage      33
     2018-01-10 22:12:29   NextSync        2018-01-10 22:12:59 or if CacheUsage 500 reached
     2018-01-12 05:50:05   countCurrent    1677
     2018-01-12 05:50:05   countHistory    159724
     2016-03-02 18:45:47   lastReduceLogResult Rows processed: 1028663, deleted: 978048, time: 528.78sec
     2018-01-12 02:02:00   lastRowsDeleted 0
     2018-01-11 06:07:47   reduceLogState  Rows processed: 0, deleted: 0, time: 0.01sec
     2018-01-12 05:50:34   state           connected
   cache:
     index      0
Attributes:
   DbLogType  Current/History
   asyncMode  0
   group      Info
   room       Zentral

Beim configCheck gibt es diese 2 Warnungen, sollte ich die Attribute entsprechend Setzen oder kann ich das ignorieren?

Code Auswählen Erweitern

Result of logmode check

Logmode of DbLog-device myDbLog is: synchronous
Recommendation: Switch myDbLog 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 table 'history' check

Column width set in DB /media/Platte/home/fhem.db.history: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 32, 'UNIT' = 32
Column width used by myDbLog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: WARNING - The relation between column width in table history and the field width used by device myDbLog should be equal but it differs. The field width used by the module can be adjusted by attributes 'colEvent', 'colReading', 'colValue'. Because you use SQLite this is only a warning. Normally the database can handle these differences.

Was mich im nachhinein noch wundert ist wieso die fhem.db so groß geworden ist, ich lasse jede nacht ein at laufen, welches die DB bereinigen sollte

Code Auswählen Erweitern

Internals:
   COMMAND    set myDbLog deleteOldDays 2
   DEF        *02:02:00 set myDbLog deleteOldDays 2
   NAME       DbLog_aufrauumen
   NR         325
   PERIODIC   yes
   RELATIVE   no
   REP        -1
   STATE      Next: 02:02:00
   TIMESPEC   02:02:00
   TRIGGERTIME 1515805320
   TRIGGERTIME_FMT 2018-01-13 02:02:00
   TYPE       at
   READINGS:
     2018-01-12 02:02:00   state           Next: 02:02:00
Attributes:
   group      Info
   room       Zentral

Danke für eure Hilfe

[DS_Starter]

Guten Morgen,

na das sieht doch gut aus. Hatte mich auch stark gewundert nachdem die Checks und Aktionen erfolgreich waren.

Die Warnungen sind nur als Info gedacht, dass der Nutzer aufmerksam wird. Wenn es keine Probleme mit der Speicherung längerer Daten als der Spaltenbreite gibt (gibt es bei dir nicht) musst du auch nichts tun.

Wegen der Grösse....auch wenn du Daten aus der DB löscht bleibt die einmal erreichte Grösse solange erhalten bis ein VACUUM Lauf erfolgte. Es gibt auch eine Einstellung autovacuum, aber die ist meines Wissens nicht per default aktiv.
Schau dir doch dazu mal die Funktionen von DbRep an. Ganz aktuell habe ich eine Online-Backup/Restore Funktion implementiert, vielleicht magst du das mal testen. (Forum Sonstiges).

schönen Tag,
Heiko

[nils_]

Was mich im nachhinein noch wundert ist wieso die fhem.db so groß geworden ist, ich lasse jede nacht ein at laufen, welches die DB bereinigen sollte

laut

Code Auswählen Erweitern

2018-01-12 02:02:00   lastRowsDeleted 0
hat er nix gelöscht. 


//edit:
überschnitten mit DS_Starter

[Tommy82]

laut

Code Auswählen Erweitern

2018-01-12 02:02:00   lastRowsDeleted 0
hat er nix gelöscht.  [emoji50]


//edit:
überschnitten mit DS_Starter [emoji4]

Hi, ja das ist richtig, liegt aber daran das ich gestern mal alles bis auf 1 Tag Manuel gelöscht habe, daher gab es heute nacht nichts zu löschen, sollte morgen wieder anders sein:-)

@DS_Starter, werde ich mir am WE mal ansehen, Danke für den tip

Gesendet von iPhone mit Tapatalk

[Tommy82]

Wegen der Grösse....auch wenn du Daten aus der DB löscht bleibt die einmal erreichte Grösse solange erhalten bis ein VACUUM Lauf erfolgte. Es gibt auch eine Einstellung autovacuum, aber die ist meines Wissens nicht per default aktiv.
Schau dir doch dazu mal die Funktionen von DbRep an. Ganz aktuell habe ich eine Online-Backup/Restore Funktion implementiert, vielleicht magst du das mal testen. (Forum Sonstiges).

schönen Tag,
Heiko

Hi, also in meinem dblog finde ich keine VACUUM welches ich aktivieren könnte, oder ich gucke falsch!?
Dein Modul guck ich mir die Tage an.
Danke

[schnitzelbrain]

Hi, also in meinem dblog finde ich keine VACUUM welches ich aktivieren könnte, oder ich gucke falsch!?
Dein Modul guck ich mir die Tage an.
Danke

Vacuum ist im dbrep modul unter set zu finden.

Grüße
Schnitzelbrain

[Tommy82]

Ja ok, aber weil @DS_Startet schrieb

Wegen der Grösse....auch wenn du Daten aus der DB löscht bleibt die einmal erreichte Grösse solange erhalten bis ein VACUUM Lauf erfolgte. Es gibt auch eine Einstellung autovacuum, aber die ist meines Wissens nicht per default aktiv.

hörte sich das für mich so an, das das in der DBLOG ginge, oder wie bekomme ich diese reduziert wenn nicht durch löschen der Daten?

[schnitzelbrain]

Ja ok, aber weil @DS_Startet schrieb
hörte sich das für mich so an, das das in der DBLOG ginge, oder wie bekomme ich diese reduziert wenn nicht durch löschen der Daten?

Naja, mit dem löschen der Daten wird anscheinend nur die Tabellenfelder gelehrt (oder vielleicht auch nur der Inhalt markiert als nicht benutzbar).
Die Struktur (Speicherplatz) bleibt.
Beim vaccum wird die Größe tatsächlich reduziert.

Grüße

Schnitzelbrain

[Tommy82]

JA aber sowas muss es doch auch in DBLOG geben!?

[DS_Starter]

hörte sich das für mich so an, das das in der DBLOG ginge, oder wie bekomme ich diese reduziert wenn nicht durch löschen der Daten?

Sorry für die Verwirrung, die Pflegefunktion(en) sind im DbRep. Löschen der Daten ist natürlich richtig. Dafür gibt es im DbLog reduceLog(Nbl), deleteOldDays(Nbl) und im DbRep delEntries, delSeqDoublets. Diese Funktionen unterscheiden sich hinsichtlich ihrer Eigenschaften sowie Einstellbarkeit/Mächtigkeit -> Commandref.

Aber allen gemeinsam ist, dass sie Daten löschen, jedoch das File an sich nicht verkleinern. Dazu gibt es "set ... vacuum" im DbRep wie Schnitzelbrain schon schrieb.

JA aber sowas muss es doch auch in DBLOG geben!?

Nicht wirklich, DbLog ist ein Logging-Device. DbRep ist ein Device zum Management/Auswertung und zur Pflege. Das sich verschiedene Löschfunktionen in DBLog finden ist historisch bedingt.

EDIT: DbLog und DbRep sind zwar zwei getrennte Module, arbeiten jedoch SEHR eng zusammen, ohne DbLog-Device kann es auch kein DbRep-Device geben. Man könnte sie als Familie bezeichnen.