Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)

[flummy1978]

Hallo Heiko,

Du könntest

vielen herzlichen Dank für alle Vorschläge. Ich würde sie nacheinander umsetzen und versuchen herauszufinden, was dort passiert.

Nur zur Erklärung:
Ich habe mein DS endlich auf DSM 7 upgedatet und in diesem Zuge natürlich alles andere auch aktualisiert. Seitdem (und auch der Umstellung auf multiCmd) habe ich den log recht voll mit diesen oder vorher den anderen Meldungen. Daher ist es für mich eben auch etwas schwerer festzustellen woher der jeweilige "Fehler" (der wie du sagst, keiner ist) bzw Meldung kommt. Die Verbindung und Geschwindigkeit der DB sollte sich maximal nach oben verandert haben, aber noch nicht schlechter geworden sein, weil die DS seitdem gefühlt schneller / bssser läuft.

Eine Frage vorab zu showproctime = 1. Ich habe das Attribut schon länger gesetzt (erinnere mich an eine frühere Fehlersuche) aber das genannte Reading ist dort nicht zu finden. Kann ich das irgendwie erzwingen?

Vielen Dank nochmal für Deine Geduld und Hilfe und ich werde weiter berichten

VG
Andreas

[DS_Starter]

Hallo Andreas,

es ist davon ausgezugehen dass die DB auf der Synology mit den Default-Einstellungen des Synology-Paketes nicht optimal eingestellt ist. Synology gibt m.W. auch Einstellungstemplates mit um die Serverparameter entsprechend der Syno (RAM) anpassen zu können (low, medium, high).
Wichtig ist zu wissen, dass man dieses Einstellungen in einem User-Konfigfile vornimmt und nicht in  von Syno ausgelieferten Konfig-Files. Die werden bei einem DSM-Update überschrieben!

Diesbezüglich würde ich dir empfehlen den Austausch hier im Synology Thread vorzunehmen.

Zum Reading...
Wenn du das Attr showproctime = 1 setzt, wird das Reading sql_processing_time automatisch angelegt und zeigt die Abarbeitungszeit von SQL-Statements. Sollte das Reading nicht da sein, wäre es schon ein sehr merkwürdiger Zustand und ein Achtungszeichen mal genauer deine DB anzuschauen.

Viel bekommt man schon mit den Möglichkeiten von DbLog heraus. Wäre aber ein anderer/neuer Thread.
Auch das Tool MySQLTuner kann hilfreich sein um herauszubekommen an welchen Schrauben es sich lohnen würde zu drehen.
Wie gesagt, das Reading sql_processing_time gibt schonmal einen groben Überblick über die Performance.

Grüße,
Heiko

[Thowe]

Hallo Heiko,
die Sprünge funktionieren. Das Fehlen war in meinem Fall das letzte Umsetzungshindernis. Von meiner Seite aus kann die Version eingecheckt werden.
Bei der Migration auf den Hash-Ablauf habe ich Dank der übersichtlichen Hash-Struktur im alten Ablauf sogar einen Fehler entdeckt - genau bei den Sonderhandlungen zum Monatsende.
Ich bin gespannt auf den ersten Volldurchlauf. Falls ich auf ein Problem stoße, könntest Du involviert werden.
Vielen Dank für dieses geniale Modul und Deinen Support,
Thowe

[DS_Starter]

Hallo Thowe,
danke für deine Rückmeldung   
Die neue V ist morgen früh im Update enthalten.

LG,
Heiko

[maa1]

Hallo Heiko,

möchte meine DB-Reorganisation auf multiCmd umstellen. Es fehlt mir aber noch das Attribut seqDoubletsVariance für delSeqDoublets. Falls möglich bitte ergänzen.

Noch eine Frage: Warum werden die Attribute bei Ausführung von multiCmd im DBRep-Device gespeichert? Dies hätte ich so nicht erwartet bzw. müsste darauf hingewiesen werden.

Danke.

LG Fredi

[DS_Starter]

Hallo Fredi,

bzgl. des Attr seqDoubletsVariance schau ich mir das an.

Warum werden die Attribute bei Ausführung von multiCmd im DBRep-Device gespeichert? Dies hätte ich so nicht erwartet bzw. müsste darauf hingewiesen werden.

multiCmd ist im Prinzip eine Verkettung von Befehlen mit einem dynamisch konfigurierten DbRep Device.
Würdest du die Befehle manuelle ausführen ohne multiCmd, müsstest/würdest du vorab das Device ebenfalls entsprechend einstellen müssen. Daraus erklärt sich das speichern der Attribute.

Ich kann den Umstand aber gern in der Hilfe vermerken, kein Thema.

LG,
Heiko

[DS_Starter]

@Fredi,
habe das Attr dem multiCmd hinzugefügt, die CommandRef ergänzt und eingecheckt.
Morgen früh ist die V im Update enthalten.

Grüße,
Heiko

[maa1]

Hallo Heiko,

vielen Dank für die rasche Umsetzung.

Bin übrigens auch ein Forecast-Fan.

lG Fredi

[flummy1978]

Hallöchen Heiko,

@alle anderen: Eigetnlich isses offtopic, da ich aber hier gefragt habe, möchte ich eine (hoffentlich kurze) Rückmeldung geben. Ich wollte dafür keinen neuen Beitrag wo anders aufmachen.

es ist davon ausgezugehen dass die DB auf der Synology mit den Default-Einstellungen des Synology-Paketes nicht optimal eingestellt ist

Auch das Tool MySQLTuner kann hilfreich sein um herauszubekommen an welchen Schrauben es sich lohnen würde zu drehen.
Wie gesagt, das Reading sql_processing_time gibt schonmal einen groben Überblick über die Performance.

Du hast mit Deiner Vermutung genau richtig gelegen  Ich taste mich zwar langsam an die Sachen heran, die sehr schwer zu verstehen sind (bis dato war ich der Meinung ich kenne DBs ein wenig -.-) aber ich habe lediglich 2 kleine Dinge in der my.cnf ergänzt, die meinen RAM betrafen und die DB rannte von da an wie verrückt. Vorher waren sql_processing_time von 100 300 und mehr sek keine Seltenheit. Ich habs nach der Änderung einen Tag lang verfolgt und heute mal einen halben Tag geloggt. Ergebnis: Fast alle Abfragen passieren unter 2 Sek die Meisten sogar unter 1 Sek.
Genauso meine Vergleiche mit einigen SQL Abfragen, die vorher auch schon mal gerne 2-300 Sek gedauert haben sind jetzt schnell erledigt.

Seit dieser Änderung sind die o.g. Fehler bzw Warnungen erledigt.

Vielen Dank nochmal für Deinen Schubs in die richtige Richtung. Komischerweise war die DB unter DSM 6 noch deutlich schneller, aber nicht zu vergleichen mit dem was ich jetzt habe. Wenn jemand schon einiges an Optimierungen an diversen Synologys gemacht hat, habe ich natürlich nichts gegen einen Austausch (gern auch PM) ich hab aktuell eine DS918+ mit 12 GB RAM in Nutzung. Ich hab da zwar sicher nicht mal Ansatzweise vieles verstanden und nur wenig angepasst, aber es ist überhaupt kein Vergleich mehr.

VG
Andreas

[DS_Starter]

Hallo Andreas,

nur nochmal zur Info.
Standardkonfiguration befindet sich in /volume1/@appstore/MariaDB/etc/mysql/my.cnf.
Diese Datei wird bei einem DSM Update überschrieben.

In der /volume1/@appstore/MariaDB/etc/mysql/my.cnf gibt es ein Include:

Code Auswählen Erweitern

...
# Please add your custom configuration to here:
!include /var/packages/MariaDB/etc/my.cnf
...

Deine Änderungen/Einträge machst du dann in der Datei /var/packages/MariaDB/etc/my.cnf damit sie beim Update erhalten bleiben. Wenn es die Datei nicht gibt, legst du sie einfach an.

Grüße,
Heiko

[CP]

Hallo Heiko,

dieser Thread scheint ja allgemein um Fragen rund um Dein (echt gelungenes) DBrep zu gehen, daher traue ich mich mal einfach mit meiner Frage mich hier anzuschliessen.

Ich habe das Modul intensiv im Einsatz um meine Datenbank in erträglichen Größen zu halten.
Dabei bin ich gerade dazu übergegangen bzw. bin dabei die DBRep devices nach "Filterkriterien" zu sortieren (z.B. DeleteAfter7Days) und dann alle DEVICES da reinzuhängen.
Jetzt habe ich die folgende Situation:
DEVICE A hat die READINGS X,Y,Z
DEVICE B hat die READING U,V,W
Ich will jetzt nach dem selben Muster die READINGS X und Y aus DEVICE A und das READING V aus DEVICE B bearbeiten.
Kann ich in dem DBRep Device die Attribute wie folgt setzen?
attr device A,B
attr reading X,Y,V

Würde DBRep dann aus dem Kreuzprodukt die richtigen Elemente aus der Datenbank bearbeiten?

Viele Grüße,
Carsten

[betateilchen]

Kann ich in dem DBRep Device die Attribute wie folgt setzen?
attr device A,B
attr reading X,Y,V

Nein, kannst Du nicht.

Was Du machen kannst: Entweder mehrere DbRep anlegen oder multiCmd verwenden und das Aufräumen automatisch Schritt für Schritt ausführen lassen.

multiCmd {<Befehl-Hash>}

Executes several set commands sequentially in a definable order.
The commands and certain modifiable attributes that are relevant for the commands are transferred in a hash.
The commands to be executed (key cmd) and the attributes to be set for them are defined via keys in the transferred hash. The order in which the commands are processed is determined via the command index in the hash which must not be '0'.

Attribute keys that can be defined in the hash are:
autoForward, averageCalcForm, device, executeBeforeProc, executeAfterProc, reading, readingNameMap, seqDoubletsVariance, timestamp_begin, timestamp_end, timeDiffToNow, timeOlderThan, timeYearPeriod, userExitFn,

Note: All of the above attributes are deleted before each command index is executed.
The attributes specified in the respective command index are set before the step is executed.

[CP]

Danke, dass mit dem multiCmd schaue ich mir morgen abend mal an....

[dennisk]

Aber dumpDirLocal ist doch gesetzt.

Wenn es gesetzt ist, wird das angegebene Verzeichnis benutzt.
Wenn die Fehlerausschrift in diesem Fall auftritt, kann das angegebene Verzeichnis nicht gelesen werden.

Also nach einem Update und Neustart habe ich nun wieder folgendes im Log - ohne, dass ich DbRep im UI aufgerufen hätte:

Code Auswählen Erweitern

2024.04.20 17:57:57 1: PERL WARNING: readdir() attempted on invalid dirhandle DIR at /usr/share/fhem/FHEM/93_DbRep.pm line 558.
2024.04.20 17:57:57 1: PERL WARNING: closedir() attempted on invalid dirhandle DIR at /usr/share/fhem/FHEM/93_DbRep.pm line 563.
Das DEF sieht wie gesagt so aus:

Code Auswählen Erweitern

defmod globalDbLog_DbRep DbRep globalDbLog
attr globalDbLog_DbRep dumpDirLocal /var/lib/fhem/dblog/

setstate globalDbLog_DbRep initialized
setstate globalDbLog_DbRep 2024-04-20 17:53:33 state initialized
setstate globalDbLog_DbRep 2024-03-24 07:56:37 timestamp_oldest_dataset 2023-09-25 20:37:40+02
dumpDirLocal ist also gesetzt. Und wenn ich in fhem den Befehl

Code Auswählen Erweitern

{qx(echo "test" > /var/lib/fhem/dblog/testfile)} ausführe, wird die Datei anstandslos erstellt. Unter /var/lib/fhem/dblog existiert auch das Unterverzeichnis log, auch dort kann fhem reinschreiben. Lesen mittels in fhem ausgeführtem

Code Auswählen Erweitern

{qx(ls /var/lib/fhem/dblog/)} bzw.

Code Auswählen Erweitern

{qx(ls /var/lib/fhem/dblog/log)} funktioniert ebenso. Kann ich irgendwas tun, um rauszufinden, warum gerade beim Neustart von fhem diese Fehlermeldungen auftauchen?

[bertl]

Hallo Heiko,

nachdem ich FHEM auf einem RaspberryPi-3-Model-B neben PiHole, MariaDB und Grafana laufen habe, kommt es 1-2 mal pro Monat vor, dass DbRep beim Schreiben der Mitternachts-Werte ins Timeout läuft.

Dabei kommen folgende Meldungen im Log:

Code Auswählen Erweitern

2024.04.24 00:01:11 2: DbRep myDbRep - Timeout occured (limit: 10 seconds). You may be able to adjust the "Timeout" attribute.
2024.04.24 00:01:11 2: DbRep myDbRep - ERROR - Timeout occured (limit: 10 seconds). You may be able to adjust the "Timeout" attribute.
2024.04.24 00:01:11 1: PERL WARNING: Argument "Timeout occured (limit: 10 seconds). You may be able to ..." isn't numeric in subtraction (-) at (eval 39568) line 39.
Nun meine Fragen dazu:

• Heißt das, dass die Werte später oder NICHT in die Datenbank geschrieben werden?
• Falls NICHT - leider sehe ich nicht, bei welchem DbRep Befehl der Timeout auftrat - kann das geloggt werden?
• Kann die 'PERL WARNING' abgefangen werden?

Danke für deine Rückmeldung.

Schönen Tag
Robert