[gelöst] DBLog funktioniert nicht mehr wie gewünscht

ronzo · 08 September 2023, 08:30:33

Ich habe DBLog seit Jahren im Einsatz. Habe FHEM dieses Jahr containerisiert und lasse es in einem K3s-Setup laufen. Auch hier hat DBLog schon wunderbar funktioniert. Leider dürfte irgendwas passiert sein. Seitdem sehe ich bei DBLog nur noch "Another operation is in progress.
Data is stored temporarily." im State.

Code Auswählen

define DBLogging DbLog /opt/fhem/db.conf .*:.*
#   .FhemMetaInternals 1
#   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 .*:.*
#   FD         5
#   FUUID      5d7bd3ef-f33f-88ea-25a6-1cecdcc69c1f344d
#   FVERSION   93_DbLog.pm:v5.8.6-s27379/2023-04-01
#   MODE       synchronous
#   MODEL      POSTGRESQL
#   NAME       DBLogging
#   NR         2
#   NTFY_ORDER 50-DBLogging
#   PID        18140
#   REGEXP     .*:.*
#   SBP_PID    18147
#   SBP_STATE  running
#   STATE      <html>Another operation is in progress. <br>Data is stored temporarily.</html>
#   TYPE       DbLog
#   dbconn     Pg:database=fhemlogs;host=dbhost.lan
#   dbuser     fhem
#   eventCount 4
#   .attraggr:
#   .attrminint:
#   .fhem:
#   HELPER:
#     COLSET     1
#     DEVICECOL  64
#     EVENTCOL   512
#     LONGRUN_PID 1694152880.60373
#     OLDSTATE   Another operation is in progress. <br>Data is stored temporarily.
#     PACKAGE    main
#     READINGCOL 64
#     TC         current
#     TH         history
#     TYPECOL    64
#     UNITCOL    32
#     VALUECOL   128
#     VERSION    5.8.6
#   Helper:
#     DBLOG:
#       state:
#         DBLogging:
#           TIME       1694152883.02559
#           VALUE      <html>Another operation is in progress. <br>Data is stored temporarily.</html>
#   OLDREADINGS:
#   READINGS:
#     2023-09-08 08:06:59   CacheUsage      1229
#     2023-09-08 08:06:59   state           <html>Another operation is in progress. <br>Data is stored temporarily.</html>
#
setstate DBLogging <html>Another operation is in progress. <br>Data is stored temporarily.</html>
setstate DBLogging 2023-09-08 08:06:59 CacheUsage 1229
setstate DBLogging 2023-09-08 08:06:59 state <html>Another operation is in progress. <br>Data is stored temporarily.</html>

Die DB läuft und ist vom Pod aus auch wunderbar erreichbar. Es landen in einer halben Stunde aber nur 20 rows in der DB.

Wo beginn ich zu suchen? Blockiert hier ev. ein anderer Prozess?

DS_Starter · 08 September 2023, 09:39:36

Ich gehe stark davon aus, dass deine DB zu langsam arbeitet.
Du arbeitest im synchronen Modus. Alle zu verarbeitenden Events sollen sofort in die DB geschrieben werden.
Sie werden zu diesem Zweck dem Logprozess übergeben. Wenn dieser Schreibprozess noch nicht beendet ist, sobald die nächsten Events in die DB geschrieben werden sollen, werden sie zwischengespeichert und es kommt diese Meldung.

Als Schnelllösung könntest du zunächst auf asynchronen Betrieb umstellen. Allerdings behebt das nur diese Meldung und bekämpft nicht die Ursache.

Setzte die das Attr showproctime=1 und schaue im Reading sql_processing_time ob meine These stimmt.
Zum Vergleich liegt mein Wert (MySQL) bei sql_processing_time=0.0030 Sekunden.

Vermutlich wirst du dort sehr hohe Werte feststellen. Dann müsstest du analysieren weshalb deine DB so langsam performt.
Das Forum Automatisierung ist dazu aber besser geeignet als das Anfängerforum. Du solltest den Thread verschieben.

LG

ronzo · 08 September 2023, 10:12:43

Das Setzen von showProcTime scheint überhaupt keinen Effekt zu zeigen. Es taucht kein entsprechendes Reading auf.

Aber der Hinweis, dass es der DB zu viel wird, dürfte in die richtige Richtung gehen. Ich gehe dem mal nach...

DS_Starter · 08 September 2023, 10:47:52

ZitatDas Setzen von showProcTime scheint überhaupt keinen Effekt zu zeigen. Es taucht kein entsprechendes Reading auf.

Abwarten ...

ronzo · 08 September 2023, 11:20:34

Ich fürchte ich muss vorher ein paar Anpassungen vornehmen. Wie kann ich festlegen defaultmäßig gar nichts zu loggen und nur bei einzelnen Devices bestimmte Dinge? (bin hier erst dabei mich schlau zu machen...)

DS_Starter · 08 September 2023, 11:41:05

ZitatWie kann ich festlegen defaultmäßig gar nichts zu loggen und nur bei einzelnen Devices bestimmte Dinge?

Im einfachsten Fall das DEF so setzen:

Code Auswählen

/opt/fhem/db.conf xxxxxxx:yyyyyyyy

Was du dann explizit loggen willst, kannst du mit "set <dblog> addLog" erledigen -> Commandref

ronzo · 08 September 2023, 13:06:52

Besten Dank. Das generelle Logging konnte ich mit xxxx:yyyy schön abdrehen.

Code Auswählen

set DBLogging addLog Wetterstation:state funktioniert auch.

Und das nun Beispielsweise als

Code Auswählen

DbLogInclude am gewünschten Device?

Wenn ich auf dem Device "Wetterstation" das Attribut "DbLogInclude" mit "state" befülle, landet dennoch nichts in der DB. Was mache ich hier falsch?

DS_Starter · 08 September 2023, 13:35:18

ZitatUnd das nun Beispielsweise als
Code Auswählen
DbLogInclude
am gewünschten Device? Das wäre ja zu einfach und schön um wahr zu sein?

Geht schon. Du musst dann nur DbLog Modus umsetzen in DbLogSelectionMode=Include. (im DbLog Device)

ronzo · 08 September 2023, 13:38:27

Perfekt. Soeben auch im Wiki gefunden...

ZitatEbenso ist es mittlerweile möglich, lediglich erwünschte Werte (Positiv-Liste) zu loggen und alle anderen zu verwerfen. Hierfür wird im LogDevice das attribut DbLogSelectionMode Include verwendet.

Besten Dank für die prompte Hilfe. Es funktioniert nun bestens.

Mir ist jedoch aufgefallen, dass bei eine ThreeStateSensor von HM für einen neuen State zum Teil zwei oder drei Rows in der DB geschrieben werden. Warum ist das eigentlich so?

DS_Starter · 08 September 2023, 14:06:04

Es werden die Events geloggt. Wenn ein Device, z.B. dein HM, für den state Wechsel mehrere Events wirft werden diese geloggt wenn man es nicht steuert, z.B. durch die event-on-* Attribute.

ronzo · 08 September 2023, 14:09:19

Besten Dank! Nun kenn ich mich aus!

CoolTux · 08 September 2023, 17:04:15

Interesse halber. Luft die DB auch in nem Pod oder haste das außerhalb des k8s?

ronzo · 08 September 2023, 17:23:48

Zitat von: CoolTux am 08 September 2023, 17:04:15Interesse halber. Luft die DB auch in nem Pod oder haste das außerhalb des k8s?

DB ist außerhalb. (eine herkömmliche DB hat für mich im Kubernetes-Cluster nicht unbedingt was verloren.) Aber auf einem Server, der so auch schon ein wenig zu tun hat.

CoolTux · 08 September 2023, 19:04:23

Zitat von: ronzo am 08 September 2023, 17:23:48
Zitat von: CoolTux am 08 September 2023, 17:04:15Interesse halber. Luft die DB auch in nem Pod oder haste das außerhalb des k8s?

DB ist außerhalb. (eine herkömmliche DB hat für mich im Kubernetes-Cluster nicht unbedingt was verloren.) Aber auf einem Server, der so auch schon ein wenig zu tun hat.

Ich hatte mal ne Zeitlang PostgreSQL als StatefullSet am laufen. War ganz ok, aber ich bin dann doch wieder zurück zu externer DB.