93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)

[erwin]

Hi Heiko,

ich hätte noch schreiben sollen:
ca 25 Mio records in der DB , beginnend mit 1.1.2012, mySQL.
Zu den Antwortzeiten: soweit ok, ich hab auch ohne reduceLogNbl ab und zu einige freezes, speziell wenns um historische SVG-Plots, (Monat/Jahr) geht.
Ein Problem war ein kompletter Hänger für etliche Minuten , als ich einen Plot aus der DB holen wollte. - ist aber klar, kann nicht gehen wenn DB locked...

ich denke die sql-performance ist bei mir dzt. durch den RPI-1 limitiert, da liegt die CPU bei  40% für den SQL-fork und bei 25% für den main task.
Bin allerdings schon dabei einen RPI-3 aufzusetzten, schaun wir mal...
Das out-of-memory problem: ich hab mom. keine idee, wie man das abfangen könnte, es muss ja nicht notwendigerweise der sql-task betroffen sein, es kann jedes andere modul, welches forked ein problem bekommen...

Wenn ich mir noch eine Funktion wünschen dürfte, wäre dass folgende:
Ähnlich der average funktion, aber für nicht-numerische werte, also löschen aller records, ausser VALUE ändert sich, behalten von min 1 Wert/Stunde bzw. Tag...
l.g. & danke erwin

[DS_Starter]

Hi Dan,

grundsätzlich kommt diese Meldung wenn noch "{HELPER}{RUNNING_PID}" gesetzt ist.
Mit einem "set ... reopen" wird dieser Eintrag ebenfalls gelöscht, zumindest in der neuesten Version.

Unter set ... findest du:

Code Auswählen Erweitern

delete $hash->{HELPER}{RUNNING_PID};

Du kannst es auch mal versuchen über die Eingabezeile zu löschen:

Code Auswählen Erweitern

{ delete $defs{myDbLog}{HELPER}{RUNNING_PID}}

Mit set reopen sollte es aber greifen. Kannst ja mit list auch schauen ob es diesen Helper-Eintrag noch gibt.
Probier mal.

Grüße
Heiko

[DS_Starter]

Hallo Erwin,

Wenn ich mir noch eine Funktion wünschen dürfte, wäre dass folgende:
Ähnlich der average funktion, aber für nicht-numerische werte, also löschen aller records, ausser VALUE ändert sich, behalten von min 1 Wert/Stunde bzw. Tag...

Ja, ich schau mal wenn ich wieder etwas mehr Zeit habe.
Sind bei mir gerade noch ein paar andere Baustellen um die ich mich kümmern muß.
DbLog hatte mich ziemlich in Anspruch genommen 

Grüße
Heiko

[DS_Starter]

Hallo Joe,

kannst du bitte den Wunsch von erwin

Wenn ich mir noch eine Funktion wünschen dürfte, wäre dass folgende:
Ähnlich der average funktion, aber für nicht-numerische werte, also löschen aller records, ausser VALUE ändert sich, behalten von min 1 Wert/Stunde bzw. Tag...

mit in deine Liste am Anfang einfügen ? Ich kann das ja nicht.
Und der Verweis auf die aktuelle Testversion ist auch veraltet.

LG
Heiko

[DeeSPe]

Hi Dan,

grundsätzlich kommt diese Meldung wenn noch "{HELPER}{RUNNING_PID}" gesetzt ist.
Mit einem "set ... reopen" wird dieser Eintrag ebenfalls gelöscht, zumindest in der neuesten Version.

Unter set ... findest du:

Code Auswählen Erweitern

delete $hash->{HELPER}{RUNNING_PID};

Du kannst es auch mal versuchen über die Eingabezeile zu löschen:

Code Auswählen Erweitern

{ delete $defs{myDbLog}{HELPER}{RUNNING_PID}}

Mit set reopen sollte es aber greifen. Kannst ja mit list auch schauen ob es diesen Helper-Eintrag noch gibt.
Probier mal.

Grüße
Heiko

Hallo Heiko,

mein Problem sitzt irgendwie tiefer.
Auf besagtem System werden alle BlockingCall(s) mit "Connection refused" im Log angezeigt.
Bin gerade etwas ratlos woher das resultiert, scheint nach bisherigen Erkenntnissen aber nichts mit DbLog zu tun zu haben.

Gruß
Dan

[DS_Starter]

Hi Dan,

schau mal im Umfeld von telnet und allowed.
Möglicherweise darf keine Telnet-Session eröffnet werden.
Telnet-Paswort gesetzt ? usw...

Grüße
Heiko

[DeeSPe]

Hi Dan,

schau mal im Umfeld von telnet und allowed.
Möglicherweise darf keine Telnet-Session eröffnet werden.
Telnet-Paswort gesetzt ? usw...

Grüße
Heiko

Danke, das habe ich schon getan.
Kann mich auch problemlos auf den Host per telnet verbinden mit globalpassword.
Alles was ich bisher geprüft habe ist identisch zu meinen anderen Hosts, trotzdem bleibt es beim refused.

Gruß
Dan

[JoeALLb]

kannst du bitte den Wunsch von erwin

Erledigt!

[JoeALLb]

Update aus den Benchmarks:
Die bei mir aktuell schnellste Konfiguration ist diese:
Die Tabelle zeigt für alle berüksichtigten SQLs (wenn ihr weitere habt, die wichtig sind, bitte zusenden)
das beste Ergebnis.
Die Tabelle ist hier partitioniert, das bringt auf meinem kleinen System ca. 10% bessere Ergebnisse wie ohne Partition.

Code Auswählen Erweitern

CREATE TABLE `history` (
`TIMESTAMP` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
`DEVICE` VARCHAR(64) NOT NULL DEFAULT '' COLLATE 'latin1_bin',
`TYPE` VARCHAR(32) NULL DEFAULT NULL COLLATE 'latin1_bin',
`EVENT` VARCHAR(64) NULL DEFAULT NULL COLLATE 'latin1_bin',
`READING` VARCHAR(64) NOT NULL DEFAULT '' COLLATE 'latin1_bin',
`VALUE` VARCHAR(32) NULL DEFAULT NULL COLLATE 'latin1_bin',
`UNIT` VARCHAR(32) NULL DEFAULT NULL COLLATE 'latin1_bin',
PRIMARY KEY (`DEVICE`, `READING`, `TIMESTAMP`),
INDEX `DbLog_Group` (`TIMESTAMP`, `DEVICE`, `READING`)
)
COLLATE='latin1_bin'
PARTITION BY RANGE  COLUMNS(device)
(PARTITION Arest VALUES LESS THAN ('#') ENGINE = Aria,
PARTITION Btrash VALUES LESS THAN ('$') ENGINE = Aria,
PARTITION Eg VALUES LESS THAN ('E') ENGINE = Aria,
PARTITION Ig VALUES LESS THAN ('I') ENGINE = Aria,
PARTITION Og VALUES LESS THAN ('O') ENGINE = Aria,
PARTITION Ug VALUES LESS THAN ('U') ENGINE = Aria,
PARTITION ak VALUES LESS THAN ('a') ENGINE = Aria,
PARTITION ek VALUES LESS THAN ('e') ENGINE = Aria,
PARTITION ik VALUES LESS THAN ('i') ENGINE = Aria,
PARTITION ok VALUES LESS THAN ('o') ENGINE = Aria,
PARTITION uk VALUES LESS THAN ('u') ENGINE = Aria,
PARTITION zk VALUES LESS THAN ('z') ENGINE = Aria,
PARTITION zz VALUES LESS THAN (MAXVALUE) ENGINE = Aria);


Zusätzlich kann ich hier sehr ressourcensparend Datensätze löschen.
Ich habe dies bei mir so konfiguriert, dass ich alle Datensätze, die ich nicht lange aufbewahren möchte umbenenne.
Device="HeizungBad" wird dann zu "Device=#HeizungBad".
Durch die vorangestellte "#" werden solche Datensätze in die Partition "Btrash" verschoben.
Die andere Aufteilung der Partitionen ist so gewählt, um eine durchschnittliche VErteilung der Devices zu erziehlen. Wenn ihr alle Devices mit einem bestimmtem Prefix
angelegt habt, müsst ihr die Partitionsaufteilung ggf. abändern.

Für Berechnungen kann ich mit diesem Layout auch noch die Trash-Datensätze nutzen.

Mit

Code Auswählen Erweitern


ALTER TABLE history TRUNCATE PARTITION Btrash;
lösche ich diese Daten des Papierkorbs dann "verzögerungsfrei".

Vermutlich ist das alles nicht wirklich einfach genug für den Endanwender, funktioniert jedoch für mich wunderbar!

Welche Bereinigungen kosten denn im Moment am meisten Performance? Vielleicht kann ich da noch etwas finden?

sG
Joe

[DS_Starter]

Hallo miteinander,

ich habe eine neue Version 2.13.6 hier angehängt. Es sind keine neuen Funktionen hinzugekommen, nur Ergänzungen die aus
Hinweisen aus dem Forum resultieren.

* es ist für die reduceLog(Nbl) Funktion ein erweiterter Plausibilitätscheck hinzugekommen der z.B. Schreibfehler
   wie "verage" statt "average" abfängt und die Funktion dann nicht loslaufen lässt.
   (https://forum.fhem.de/index.php/topic,68713.msg601965.html#msg601965)

* Ausstattung der Get-Funktion (Ploterstellung) mit einem separaten DB-Handle zur proaktiven Optimierung
   
Würde mich freuen wenn ihr diese Version wieder bei euch integriert und Feedback gebt ob es bei euch ebenso läuft.
Bitte FHEM nach Einspielung restarten !

viele Grüße
Heiko

[JoeALLb]

Bisher höchst unauffällig Danke für die Version!!

[JoeALLb]

Hallo Heiko,

im Log finde ich immer wieder mal solche Einträge,
leider ohne Information, warum diese nicht gespeichert werden können.
Ich vermute mal, dass hier nicht alle Daten ausreichend vorhanden sind, im Falle cin
HeizunDI wurde nur in ein Status verändert das Event der Readinggroup wird hier (denk ich) nicht korrekt erkannt?!?

Dies ist aber unabhängig von der aktuellen Version, diese Meldungen hatte ich zuvor auch.

Code Auswählen Erweitern

2017.03.16 19:11:53 3: DbLog myDbLogSQL -> Failed to insert into history - TS: 2017-03-16 19:11:39, Device: HeizDI, Event: Auto
2017.03.16 19:11:53 3: DbLog myDbLogSQL -> Failed to insert into history - TS: 2017-03-16 19:11:39, Device: rg_HeizunP, Event: HeizunDI.state: <html>Auto</html>
2017.03.17 02:14:37 3: DbLog myDbLogSQL -> Failed to insert into history - TS: 2017-03-17 02:14:01, Device: telegram, Event: PollingErrCount: 2
2017.03.17 03:26:44 3: DbLog myDbLogSQL -> Failed to insert into history - TS: 2017-03-17 03:26:05, Device: KNX_020001, Event: getG1: 0.000
2017.03.17 03:26:44 3: DbLog myDbLogSQL -> Failed to insert into history - TS: 2017-03-17 03:26:05, Device: KNX_020001, Event: last-sender: 1/1/20
2017.03.17 03:26:44 3: DbLog myDbLogSQL -> Failed to insert into history - TS: 2017-03-17 03:26:05, Device: KNX_020001, Event: 0.000

Hast Du eine Idee dazu?

Davor und danach stehen leider keine näheren Hinweise im Log.

[DS_Starter]

Hallo Joe,

Das Array insert bringt nur zurück ob ein Element erfolgreich gespeichert wurde oder nicht. Deswegen sind die Infos etwas mager.
Aber der Grund für diese Meldungen ist (übrigens auch bei mir) wenn der Primary Key das Speichern verhinderte.
Siehst du auch dass der Timestamp gleich ist, das Device auch. Schau mal in deine DB. Du wirst mit ziemlicher Sicherheit bereits einen Eintrag zu fraglicher Zeit mit dem Device und dem angemeckerten Reading (als Teil des Events) finden.
Wenn du den PK löscht wird es diese Fehler nicht mehr geben. Bin auch schon längere Zeit am Überlegen ob man PK noch etwas anders bauen könnte/sollte.

Grüße
Heiko

[JoeALLb]

Hallo Heiko,
Sorry, da hätte ich auch selber drauf kommen können. Danke für Deine Antwort! Ich habe das sogar geprüft, jedoch wegen einem Tippfehler im SQL keine Werte erhalten.

Den PK sehe ich eigentlich so schon als genau richtig, denn was bedeuten Werte zur exakt gleichen zeit mit gleichem Reading? Das ist nichts wirklich brauchbares.
Eher würde ich das nutzen, um die Module zu korrigieren, die so etwas produzieren. Bisher habe ich dadurch 2 fehlerhafte Module entdeckt (wurden bereits korrigiert).

Diese Fälle habe ich im Moment entdeckt, die doppelte Logeinträge generieren:
# Das KNX-Modul schreibt denke ich tatsächlich manchmal doppelte Events
# DOIFs, die sich selbst aufrufen, verursachen ebenfalls doppelte Logs (welche ich nicht benötige)
# Die Readingsgroup duplizierte Events von dargestellten Devices... habe das abgestellt indem ich die RG mit DbLogExclude versehen habe. Da dies nur zur Anzeige benutzt wird will ich dort nichts loggen.
# userReadings ohne Filter für Events. Wenn das zugrundeliegende Device mehrere Readings gleichzeitig aktualisiert, wird dieses userReading mehrmals zur selben Zeit neu berechnet. In den meisten Fällen ist dies auch aus Performancegründen nicht optimal.

Idee:
Wie wäre es, wenn wir die Fehlermeldung

Code Auswählen Erweitern

DbLog sql -> Failed to insert into history -
durch

Code Auswählen Erweitern

DbLog sql -> Failed to insert into history (check for possible PK violation)-
ersetzen? Dadurch könnten vielleicht zukünftige Fragen diesbezüglich hier reduziert werden?!


Aus aktuellem Anlass hätte ich auch noch einen Wunsch (auch wenn ich es manuell halbwegs lösen konnte)
Die Festplatte meiner DB eines Systems hatte sich verabschiedet, im Cache waren 117000 Einträge.
Eine andere Festplatte im System funktionierte noch.
Mein Wunsch wäre also:

Code Auswählen Erweitern

set sql exportCache /mnt/usb/export.data purgeCache
und

Code Auswählen Erweitern

set sql importCache /mnt/usb/export.data

Der optionale Parameter "purgeCache" sollte den Speicher des Caches löschen, nachdem dieser erfolgreich in die Datei geschrieben wurde.
Wenn ich das ohne diesen Parameter manuell über "set sql purgeCache" mache, vergeht zuviel Zeit zwischen dem schreiben der Datei und dem Löschen des Caches, ich verliere
dadurch also zu viele Einträge...

Grüße
Joe

[DS_Starter]

Hi Joe,

ja, die Fehlermeldung "Failed to insert into history ..." kann ich noch etwas pimpen. Ich wollt esie nur nicht so lang werden lassen. Es kommt nach dem ganzen blabla ja noch der Inhalt des nicht gespeicherten Events an sich. Aber du hast recht, dann kommt man evtl. schneller drauf.

Die andrere Sache

Code Auswählen Erweitern

set sql exportCache /mnt/usb/export.data purgeCache

kann ich gerne mit mit vorsehen.
Wenn ich dich richtig verstanden habe, soll der Befehl exportCache nur den Inhalt des Caches in eine beliebige Textdatei an beliebiger Stelle schreiben können (optional mit löschen des Caches danach) damit man die Daten im Disasterfall (wie bei dir) nicht verliert sondern hinterher, wenn man  seine DB verfügbar hat, wieder importieren kann. Habe ich das so richtig zusammengefasst ?

Grüße
Heiko