93_DbLog - Umstellung Log-Funktion auf non-blocking

[ioT4db]

Hallo Heiko,
kurze Rückmeldung: alles stabil und ohne Fehler bei mir seit dem letzten Update...
VG...

[ioT4db]

Und wie lange dauert es? du könntest zum Start des backups cacheInterval hochdrehen und danach noch einen commitCache machen.

Vielleicht aber schaffen wirs noch eine non-blocking backupfunktion mit in das modul zu integrieren.... dann müsstest du halt haperbackup umkonfigurieren...

Hi Joe,
momentan dauert es ca. 4-5 Minuten. Die Fehlermeldungen haben sich auf 1-2 pro Nacht reduziert, manchmal sehe ich gar keine Fehler. Das ist absolut verschmerzbar! das Hochsetzen des cachIntervals (ich vermute Du meinst mit nem DOIF o.ä.) behalte ich mal im Hinterkopf. Aber wie gesagt, da drückt mir der Schuh im Moment zu wenig - hab noch einige andere Baustellen. Vlt. gibt es da in den nächsten Monaten auch noch Modul-interne Lösung ala backup-funktion oder so...
VG...

[Sunny]

Moin Heiko,

War Heute morgen wohl noch nicht ganz wach....
Habe Deine Antwort leider übersehen. 
Werde Deine Version noch testen und Dir, dann die Ergebnisse zukommen lassen.
Habe heute noch einiges auf dem Zettel. Danke für Deine schnelle Reaktion.

LG
sunny

[Amenophis86]

Ich weiß zwar nicht warum, aber reduceLog scheint bei mir nicht zu funktionieren.

Ich habe auf einer zweiten FHEM Instanz DBLog laufen, welche nur reduceLog regelmäßig ausführt, da dies FHEM ja blockiert. Dachte bisher zumindest immer, dass es ausgeführt wird. Aber nun sehe ich, dass es zwar ausgeführt wird, aber nichts reduziert. Hier mal ein List des Device:

Code Auswählen Erweitern

Internals:
   CFGFN
   COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
   CONFIGURATION /opt/fhem-zwei/FHEM/db.conf
   DBMODEL    MYSQL
   DEF        /opt/fhem-zwei/FHEM/db.conf Nichts:Nichts
   MODE       asynchronous
   NAME       logdb
   NR         13
   NTFY_ORDER 50-logdb
   PID        1859
   REGEXP     Nichts:Nichts
   STATE      connected
   TYPE       DbLog
   VERSION    2.11.1
   dbconn     mysql:database=fhem;host=192.168.2.22;port=3306
   dbuser     fhem
   Helper:
     COLSET     1
     DEVICECOL  64
     EVENTCOL   512
     READINGCOL 64
     TYPECOL    64
     UNITCOL    32
     VALUECOL   128
   Readings:
     2017-02-04 16:18:01   CacheUsage      0
     2017-02-04 16:18:01   NextSync        2017-02-04 16:18:31 or if CacheUsage 500 reached
     2017-02-04 16:12:48   lastReduceLogResult Rows processed: 0, deleted: 0, updated: 0, time: 10.00sec
     2017-02-04 16:18:01   state           connected
   Cache:
     index      0
Attributes:
   asyncMode  1
   room       LogDB
   userReadings DbFileSize:lastReduceLogResult.* { (split(' ',`du -m dbLog.db`))[0] }

Als RegExfilter habe ich Nichts:Nichts gesetzt, weil ja auch hier nicht geloggt werden soll. Dacht erst, dass es daran liegt, aber auch, wenn ich auf .*:.* setze passiert bei reducelog nichts. Ich führe den Befehl wie folgt aus:

Code Auswählen Erweitern

set logdb reduceLog 60 average

allerdings werden keine Daten reduziert und nach 10 Sekunden kommt immer folgendes Ergebnis:

Code Auswählen Erweitern

DbLog logdb: reduceLog executed. Rows processed: 0, deleted: 0, updated: 0, time: 9.00sec

kann mir einer weiterhelfen wo der Fehler liegt?

[DS_Starter]

Hallo Amenophis86,

um zu vergelichen habe ich jetzt mal bei mir ein

Code Auswählen Erweitern

set logdb reduceLog 100 average

ausführt. Klappt problemlos. Im Logfile ist das Ergebnis protokolliert.

Code Auswählen Erweitern


2017.02.04 16:42:03.421 3: DbLog LogDB: reduceLog requested with DAYS=100, AVERAGE=HOUR
2017.02.04 16:42:41.970 3: DbLog LogDB: reduceLog deleting 5209 records of day: 2016-10-21
2017.02.04 16:42:48.273 3: DbLog LogDB: reduceLog (hourly-average) updating 51 records of day: 2016-10-21
2017.02.04 16:42:59.637 3: DbLog LogDB: reduceLog deleting 145905 records of day: 2016-10-22
2017.02.04 16:45:32.531 3: DbLog LogDB: reduceLog (hourly-average) updating 1533 records of day: 2016-10-22
2017.02.04 16:45:44.300 3: DbLog LogDB: reduceLog deleting 126102 records of day: 2016-10-23
2017.02.04 16:47:56.990 3: DbLog LogDB: reduceLog (hourly-average) updating 1527 records of day: 2016-10-23
2017.02.04 16:48:05.587 3: DbLog LogDB: reduceLog deleting 106131 records of day: 2016-10-24
2017.02.04 16:49:57.399 3: DbLog LogDB: reduceLog (hourly-average) updating 1493 records of day: 2016-10-24
2017.02.04 16:50:06.043 3: DbLog LogDB: reduceLog deleting 104278 records of day: 2016-10-25
2017.02.04 16:51:55.363 3: DbLog LogDB: reduceLog (hourly-average) updating 1521 records of day: 2016-10-25
2017.02.04 16:52:04.273 3: DbLog LogDB: reduceLog deleting 100690 records of day: 2016-10-26
2017.02.04 16:53:50.871 3: DbLog LogDB: reduceLog (hourly-average) updating 1475 records of day: 2016-10-26
2017.02.04 16:53:54.554 3: DbLog LogDB: reduceLog executed. Rows processed: 636375, deleted: 588315, updated: 7600, time: 711.00sec


Die Regexfilter oder Mode-Settings sind hier nicht relevant weil reducelog eine komplett eigenständige Funktion ist die ihre eigenen Selekt/Updatemechanismen mitbringt.Das hat auch nichts mit der non-blocking Log-Funktion zu tun.
Die einfachste Ursache wäre wenn deine DB keine EInträge älter als deine Angabe im Befehl enthält, aber das hast du sicher schon gecheckt.

Möglich wäre aber auch dass du mal schauen müßtest ob der benutze User auch die entsprechendne Rechte da du ja von einem entfernten Rechner auf deine DB zugreifst (nehme ich wegen deiner Erläuterung an). Es gibt ja u.U. diverse Beschränkungen in der Userverwaltung bei MySQL.
Mehr fällt mir dazu grad nicht ein ...

Viele Grüße

[Amenophis86]

Verstehe ich nicht, die Rechte habe ich mal auf "all privileges" geändert, aber passiert trotzdem nichts.

Alte Daten sind auf jeden Fall drin. Sind über 1,5 Millionen und ich sehe auch die älteren Daten. Dann muss ich mal weiter suchen, woran das liegen kann. Ich danke dir trotzdem für die Antwort.

[DeeSPe]

Dass reduceLog noch nicht non-blocking ist, musste ich gestern schmerzhaft feststellen als mein FHEM für 34 Minuten blockiert war.

lastReduceLogResult Rows processed: 5944765, deleted: 5528207, time: 2036.02sec

Was mich allerdings viel mehr wundert ist die Tatsache dass die Datenbank (Dateigröße) kaum geschrumpft ist.
Vor reduceLog waren es rund 7,5 Millionen Einträge bei rund 700 MB und danach sind es 1,7 Millionen Einträge mit 580 MB.
Die Anzahl der Datensätze ist um Faktor 4,4 geschrumpft! Die Datenmenge aber nur um Faktor 1,2.
Wird da irgendwo Speicher nicht wieder frei gegeben?

Gruß
Dan

[JoeALLb]

Welchen Datenbank typ nutzt du? Mysql mit InnoDB gibt tatsächlich den Speicher ungern/nicht wieder frei.
Wenn du das dennoch willst kannst du die Daten "umkopieren".

[DeeSPe]

Welchen Datenbank typ nutzt du? Mysql mit InnoDB gibt tatsächlich den Speicher ungern/nicht wieder frei.
Wenn du das dennoch willst kannst du die Daten "umkopieren".

Jepp!!!

Das ist ja eine Sauerei! Was soll denn das?

Gruß
Dan

[DS_Starter]

Hallo Dan,

ja Reducelog läuft noch so wie es von rapster bei der Erstellung designed war. Ich habe noch vor diese Funktion auf non-blocking umzustellen.
Aber das führen wir in diesem Thread https://forum.fhem.de/index.php/topic,65860.0.html weiter.

Davon unabhängig reduziert recucelog allein noch nicht den belegten Platz auf der Platte/SD. Je nach DB-Typ ist dann noch ein "optimize table" (MySQL) bzw. ein "VACUUM" (SQLite) nötig um Platz freizugeben. Bei Postgre weiß ich es jetzt nicht ad hoc. Ich habe es noch nicht prbiert, aber wenn die DB im asynchronen Mode betrieben wird, sollte FHEM nicht blockieren sofern man diese Aktivität von außen auf der DB initiiert.

EDIT: oder so wie Joe schrieb 

Grüße
Heiko

[DeeSPe]

Hallo Dan,

ja Reducelog läuft noch so wie es von rapster bei der Erstellung designed war. Ich habe noch vor diese Funktion auf non-blocking umzustellen.
Aber das führen wir in diesem Thread https://forum.fhem.de/index.php/topic,65860.0.html weiter.

Davon unabhängig reduziert recucelog allein noch nicht den belegten Platz auf der Platte/SD. Je nach DB-Typ ist dann noch ein "optimize table" (MySQL) bzw. ein "VACUUM" (SQLite) nötig um Platz freizugeben. Bei Postgre weiß ich es jetzt nicht ad hoc. Ich habe es noch nicht prbiert, aber wenn die DB im asynchronen Mode betrieben wird, sollte FHEM nicht blockieren sofern man diese Aktivität von außen auf der DB initiiert.

EDIT: oder so wie Joe schrieb 

Grüße
Heiko

Danke Heiko für den OPTIMIZE Tipp. Arbeite zwar schon eine Weile hin und wieder mal mit SQL aber richtig gut damit auskennen ist was Anderes... 
Nach Optimize von ehemals 580,7 MB nur noch 143,7 MB Platte belegt!
Happy!

Gruß
Dan

[JoeALLb]

Danke Heiko für den OPTIMIZE Tipp. Arbeite zwar schon eine Weile hin und wieder mal mit SQL aber richtig gut damit auskennen ist was Anderes... 
Nach Optimize von ehemals 580,7 MB nur noch 143,7 MB Platte belegt!

Hallo Dan, ja, sorry, das hatte ich gerade so nicht mehr im Kopf. Wenn InnoDB beim OPTIMIZE gelockt wird, wird
(in neueren Versionen) auch die Dateigröße reduziert.

[DeeSPe]

Hallo Dan, ja, sorry, das hatte ich gerade so nicht mehr im Kopf. Wenn InnoDB beim OPTIMIZE gelockt wird, wird
(in neueren Versionen) auch die Dateigröße reduziert.

Kein Ding, hat ja jetzt so geklappt!
Muss man ja nur wissen.

Gruß
Dan

[Benni]

Mit meinem Wunderground-Problem muss ich mich wohl wieder in den entsprechenden Thread zu Wunderground trollen 

Hallo Heiko!

nur kurz zu deiner Info! Ich habe da jetzt etwas weiter analysiert und bin inzwischen tatsächlich mit einem weiteren Ansatz im entsprechenden Wunderground-Thread wieder "vorstellig" geworden

Gruß Benni.

[DS_Starter]

Hallo Benni, MichaelT, fiesenjung und alle anderen Mitstreiter,

danke für eure Rückmeldungen.

Anbei noch die V2.11.4, welche die letzte Version hier in diesem Thread sein soll. Sie hat eigentlich nichts mehr mit der Umstellung der Log-Funktion auf non-blocking zu tun, sondern enthält ein Feature für SQLite -User.

Die Attribute colEvent, colReading, colValue gelten nun auch für SQLite sofern sie man setzt. Es geht zurück auf einen Vorschlag von Garry um z.B. die Event-Daten nicht in die DB zu schreiben. Mit colEvent=0 ist das möglich. Natürlich auch für Nicht-SQlite DBs.

Zur Beachtung ... wird eines dieser Attribute gesetzt, gelten die Feldlängenbeschneidungen insgesamt auch für SQLite, weshalb u.U. die Feldlängen insgesamt im Modul über die Attribute angepasst werdn müssen sofern man z.B. längere Readings als 512 Zeichen speichern will.
Ohne diese Attr bleibt alles wie bisher. Steht in Commandref beschrieben.

Außerdem sind die Logausgaben im asynch-Mode etwas erweitert und es wird geprüft ob das DBI-Modul installiert ist. Sonst beim Define eine entsprechende Meldung ausgegeben.

Bitte testet die Version auch bei euch, insbesondere SQLite mit diesem Feature.  Garry (weiter vorn) hat es schon erfolgreich getan. Diese Version möchte ich im Laufe der Woche einchecken.
Danach möchte ich diesen Thread hier schließen, da er sich speziell mit der non-blocking Logfunktion beschäftigte was seit 2.10.1 abgeschlossen ist.

Alle weiteren Optimierungen diskutieren und verfolgen wir hier https://forum.fhem.de/index.php/topic,65860.0.html

viele Grüße
Heiko