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

[JoeALLb]

@DS_Starter
andere Idee zum Umgang mit der Current-Tabelle:
Wenn wir den Inhalt der Current-Tabelle im Speicher behalten, und diesen nur beim Neustart von FHEM in die Current-Tabelle schreiben? (analog zum aktuellen stat-file).
Zusätzlich könnten wir noch einen setter "rereadCurrent" (oder ähnlich) erzeugen. Das wäre von der Performance her das absolut beste und
würde auch einen kleinen RPI kaum belasten.

[DS_Starter]

Hi Joe,

ich bin mir gerade nicht sicher ob es sinnvoll ist soviel Kraft in die current-Tabelle zu investieren. Ein select auf diese Tabelle passiert ja nur wenn man mal eine neue SVG-Definition mit der Unterstützung durch Vorschlagswerte anlegen will. Der advanced User wird die vermutlich nicht immer mitlaufen/ beschreiben lassen und abschalten bzw. bei Bedarf mal zuschalten. Obendrein enthält sie typischerweise nur wenige Datensätze auch wenn es ein paar hundert sein sollten.

Ich würde die Energie eher auf die Umsetzung solcher Dinge wie "Direktes addLog in die Datenbank statt über Trigger" aus deiner Liste am Anfang verwenden wollen. Das wäre ein schönes Feature finde ich.

Aber was ich wirklich bräuchte wäre ein engagierter Tester für die Unterstützung von PK bei PostgreSQL. Ich glaube passende Statements gefunden zu haben und baue die nächste Version auch zügig. Nur mit dem Test hapert es nun.

Grüße
Heiko

[ghayne]

Hallo alle,


Eine Idee:

Mysql hat Untersstutzung fur Sekundenbruchteile https://dev.mysql.com/doc/refman/5.7/en/fractional-seconds.html.


Damit waere ein PK fuer TIMESTAMP allein eindeutig.

Korrektur:
Erst ab Mysql version 5.6, aber mit MariaDB muss es moeglich sein auf der Pi.
 


Regards, Garry

[Pyromane]

Aber was ich wirklich bräuchte wäre ein engagierter Tester für die Unterstützung von PK bei PostgreSQL. Ich glaube passende Statements gefunden zu haben und baue die nächste Version auch zügig. Nur mit dem Test hapert es nun.

Ich setze PostgreSQL ein und würde mich als Tester zur Verfügung stellen.
Reicht eine Kopie der History Tabelle und Konsole die Befehle ausführen oder wird eine vollständige FHEM Inst benötigt? (Beides wäre möglich)

[DS_Starter]

Hallo Pyro,

prima... danke ! 

Anbei die V2.12.4.
Hier ist der PK Support erstmal nur für die history-Tabelle integriert. Wir schauen zunächst ob das klappt.

Welche Konstellation du wählst ist eigentlich egal solange du dir eine zweite DB, zb. fhemtest, mit einer kopierten (oder neuen leeren) history-Tabelle zur Verfügung hast mit der du spielen kannst.
Dann definierst du dir ein zweites DbLog-Device und ein DEF mit dem auch Events geloggt werden. Ohne weitere Massnahmen soll bis hierher alles wie gewohnt laufen und die events in die history geschrieben werden.

Dann legst du dir in der DB den PK an:

Code Auswählen Erweitern

ALTER TABLE `history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);

Möglicherweise einfach über dein DB Management-Tool. Wenn alles richtig läuft, geht alles wie gewohnt weiter. Erst mit verbose 5 sieht man Unterschiede. Hier mal ein Beispiel mit MySQL:

2017.02.09 18:28:23.534 4: DbLog LogDB -> ################################################################
2017.02.09 18:28:23.534 4: DbLog LogDB -> ###              start of new Logcycle                       ###
2017.02.09 18:28:23.534 4: DbLog LogDB -> ################################################################
2017.02.09 18:28:23.534 4: DbLog LogDB -> amount of events received: 5 for device: sysmon
2017.02.09 18:28:23.534 4: DbLog LogDB -> check Device: sysmon , Event: stat_cpu_percent: 1.73 0.00 0.49 97.43 0.17 0.00 0.18
2017.02.09 18:28:23.535 4: DbLog LogDB -> added event - Timestamp: 2017-02-09 18:28:23, Device: sysmon, Type: SYSMON, Event: stat_cpu_percent: 1.73 0.00 0.49 97.43 0.17 0.00 0.18, Reading: stat_cpu_percent, Value: 1.73 0.00 0.49 97.43 0.17 0.00 0.18, Unit:
2017.02.09 18:28:23.535 4: DbLog LogDB -> check Device: sysmon , Event: eth0_diff: RX: 0.24 MB, TX: 0.33 MB, Total: 0.57 MB
2017.02.09 18:28:23.536 4: DbLog LogDB -> added event - Timestamp: 2017-02-09 18:28:23, Device: sysmon, Type: SYSMON, Event: eth0_diff: RX: 0.24 MB, TX: 0.33 MB, Total: 0.57 MB, Reading: eth0_diff, Value: RX: 0.24 MB, TX: 0.33 MB, Total: 0.57 MB, Unit:
2017.02.09 18:28:23.536 4: DbLog LogDB -> check Device: sysmon , Event: loadavg: 0.02 0.07 0.09
2017.02.09 18:28:23.536 4: DbLog LogDB -> added event - Timestamp: 2017-02-09 18:28:23, Device: sysmon, Type: SYSMON, Event: loadavg: 0.02 0.07 0.09, Reading: loadavg, Value: 0.02 0.07 0.09, Unit:
2017.02.09 18:28:23.536 4: DbLog LogDB -> check Device: sysmon , Event: swap: Total: 1293.00 MB, Used: 3.53 MB,  0.27 %, Free: 1289.46 MB
2017.02.09 18:28:23.536 4: DbLog LogDB -> added event - Timestamp: 2017-02-09 18:28:23, Device: sysmon, Type: SYSMON, Event: swap: Total: 1293.00 MB, Used: 3.53 MB,  0.27 %, Free: 1289.46 MB, Reading: swap, Value: Total: 1293.00 MB, Used: 3.53 MB,  0.27 %, Free: 1289.46 MB, Unit:
2017.02.09 18:28:23.536 4: DbLog LogDB -> check Device: sysmon , Event: ram: Total: 876.27 MB, Used: 229.55 MB, 26.20 %, Free: 646.71 MB
2017.02.09 18:28:23.537 4: DbLog LogDB -> added event - Timestamp: 2017-02-09 18:28:23, Device: sysmon, Type: SYSMON, Event: ram: Total: 876.27 MB, Used: 229.55 MB, 26.20 %, Free: 646.71 MB, Reading: ram, Value: Total: 876.27 MB, Used: 229.55 MB, 26.20 %, Free: 646.71 MB, Unit:
2017.02.09 18:28:23.547 5: DbLog LogDB -> Primary Key used in fhemtest.history: TIMESTAMP DEVICE READING
2017.02.09 18:28:23.547 5: DbLog LogDB -> Primary Key used in fhemtest.current: none
2017.02.09 18:28:23.547 4: DbLog LogDB -> processing event Timestamp: 2017-02-09 18:28:23, Device: sysmon, Type: SYSMON, Event: stat_cpu_percent: 1.73 0.00 0.49 97.43 0.17 0.00 0.18, Reading: stat_cpu_percent, Value: 1.73 0.00 0.49 97.43 0.17 0.00 0.18, Unit:
2017.02.09 18:28:23.547 4: DbLog LogDB -> processing event Timestamp: 2017-02-09 18:28:23, Device: sysmon, Type: SYSMON, Event: eth0_diff: RX: 0.24 MB, TX: 0.33 MB, Total: 0.57 MB, Reading: eth0_diff, Value: RX: 0.24 MB, TX: 0.33 MB, Total: 0.57 MB, Unit:
2017.02.09 18:28:23.547 4: DbLog LogDB -> processing event Timestamp: 2017-02-09 18:28:23, Device: sysmon, Type: SYSMON, Event: loadavg: 0.02 0.07 0.09, Reading: loadavg, Value: 0.02 0.07 0.09, Unit:
2017.02.09 18:28:23.547 4: DbLog LogDB -> processing event Timestamp: 2017-02-09 18:28:23, Device: sysmon, Type: SYSMON, Event: swap: Total: 1293.00 MB, Used: 3.53 MB,  0.27 %, Free: 1289.46 MB, Reading: swap, Value: Total: 1293.00 MB, Used: 3.53 MB,  0.27 %, Free: 1289.46 MB, Unit:
2017.02.09 18:28:23.547 4: DbLog LogDB -> processing event Timestamp: 2017-02-09 18:28:23, Device: sysmon, Type: SYSMON, Event: ram: Total: 876.27 MB, Used: 229.55 MB, 26.20 %, Free: 646.71 MB, Reading: ram, Value: Total: 876.27 MB, Used: 229.55 MB, 26.20 %, Free: 646.71 MB, Unit:
2017.02.09 18:28:23.553 4: DbLog LogDB -> 5 of 5 events successfully inserted into table history
2017.02.09 18:28:23.558 5: DbLog LogDB -> 5 events successfully inserted or replaced in table current using primary key
2017.02.09 18:28:23.639 5: DbLog LogDB -> DbLog_Push Returncode: 0

Die farbigen Stellen sollten erkennen lassen dass DbLog den gesetzten PK erkennt. Die Werte sollten in die DB geschrieben werden, aber jetzt können auch Fehler auftreten wenn z.B. ein Satz wegen eines vorhandenen Duplicates nicht geschrieben wird. Dieser Fehler wäre dann i.O., das muß man wissen !

EDIT:  So sieht der Fehler auf, wenn er durch die duplicate row verursacht wird (sorry hatte falsche Meldung von meinem Testsystem kopiert):
2017.02.10 07:18:20.129 3: DbLog LogDB -> Failed to insert into history - Device: Rep.Show.DbSize, Event: done
2017.02.10 07:28:50.686 3: DbLog LogDB -> Failed to insert into history - Device: Rep.Show.DbSize, Event: done
2017.02.10 07:48:41.507 3: DbLog LogDB -> Failed to insert into history - Device: Rep.Show.DbSize, Event: done
2017.02.10 08:08:32.183 3: DbLog LogDB -> Failed to insert into history - Device: Rep.Show.DbSize, Event: done
[/code]


Der PK-Support  wird aber erst ab Postgre Version 9.5 funktionieren. Ich hoffe du hast mindestens dieses Release.
Wenn du getestet hast mache bitte ein paar verbose 5 Auszüge so wie oben jeweils im synch bzw. asynch mode.

Grüße
Heiko

[JoeALLb]

Hallo Garry

Eine Idee:

Mysql hat Untersstutzung fur Sekundenbruchteile https://dev.mysql.com/doc/refman/5.7/en/fractional-seconds.html.
Damit waere ein PK fuer TIMESTAMP allein eindeutig.

Was genau versprichst Du dir davon?
DB-Einträge unter einer Sekunde machen für mich aus mehreren Gründen keinen SInn, aber ich würde gerne Deine Beweggründe erfahren!

SG Joe

[ghayne]

Hallo GarryWas genau versprichst Du dir davon?
DB-Einträge unter einer Sekunde machen für mich aus mehreren Gründen keinen SInn, aber ich würde gerne Deine Beweggründe erfahren!

SG Joe

Hallo Joe, ich dachte es waere einfacher ein PK zu erstellen auf nur ein Feld. Ist meistens schneller. Ich habe es selbst aufgegeben schnelle events in eine DB zu schreiben, Fhem ist nicht dafuer geeignet.

Garry

[JoeALLb]

Hallo Joe, ich dachte es waere einfacher ein PK zu erstellen auf nur ein Feld. Ist meistens schneller. Ich habe es selbst aufgegeben schnelle events in eine DB zu schreiben, Fhem ist nicht dafuer geeignet.

FHEM ist eigentlich nicht langsam.....
und mit async=1 sind die events auch schnell gespeichert. Aber ja, ein Echtzeit-System wird es nie werden.
Dein Problem habe ich dennoch noch nicht ganz verstanden...

Bezüglich PK: Man könne als PK auch eine fortlaufende Nummer oder einen Zufallswert generieren,
das hat alles vor und Nachteile.
Hier geht es aber darum, zu verhindern, dass ein Device/reading zus selben Zeit loggt. Das macht für FHEM keinen Sinn und kann in Plots auch nicht geloggt werden.
Zusätzlich sind Löschungen ohne PK nicht eindeutig.

[vbs]

Sorry, falls ich hier nicht richtig bin, aber ich hab in letzter Zeit ziemlich viele Logeinträge dieser Art (vermutlich seit der Umstellung auf non-blocking?):

Code Auswählen Erweitern

2017.02.10 09:27:37.454 3: DbLog benDbLog: Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user fhem
2017.02.10 09:27:37.455 3: DbLog benDbLog: Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2017.02.10 09:27:43.798 3: DbLog benDbLog: Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user fhem
2017.02.10 09:27:43.799 3: DbLog benDbLog: Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2017.02.10 09:28:03.964 3: DbLog benDbLog: Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user fhem
2017.02.10 09:28:03.965 3: DbLog benDbLog: Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2017.02.10 09:34:25.363 3: DbLog benDbLog: Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user fhem
2017.02.10 09:34:25.364 3: DbLog benDbLog: Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2017.02.10 09:36:54.618 3: DbLog benDbLog: Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user fhem
2017.02.10 09:36:54.619 3: DbLog benDbLog: Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2017.02.10 09:37:18.145 3: DbLog benDbLog: Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user fhem
2017.02.10 09:37:18.146 3: DbLog benDbLog: Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created

[DS_Starter]

Hallo VBS,

Passt schon. Solche Verbindungsmeldungen habe schon vorher, sahen nur anders aus und kamen evtl. Seltener. Es ist nur eine Info, kannst du mit verbose 2 im DbLog unterdrücken.

Grüße,
Heiko

[vbs]

Ok danke, kann ich machen. Aber besteht da nicht die Gefahr, dass ich damit auch andere, relevantere Logs wegfiltere?

[DS_Starter]

Eher weniger. Richtige Fehler werden im Modul mit verbose 1 oder 2 generiert und würden dann natürlich auch ins Log gelangen. Dies Verbindungsinfos oben werden generiert wenn im synchronen Mode die gespeicherte Session zur DB aus irgendwelchen Gründen neu erstellt wurde/werden musste. Das nur zur Erläuterung dieser Meldung. Im asychronen Mode wird es diese Meldung in dieser Form sicherlich nicht geben.

[Pyromane]

Hallo Pyro,

prima... danke ! 

Guten Abend Heiko,

ich habe zu danken für deinen Einsatz 

Wir können alles gefahrlos probieren und keine Rücksicht nehmen.

Hier ist der PK Support erstmal nur für die history-Tabelle integriert. Wir schauen zunächst ob das klappt.

Dann legst du dir in der DB den PK an:

Code Auswählen Erweitern

ALTER TABLE `history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);

Der PK-Support  wird aber erst ab Postgre Version 9.5 funktionieren. Ich hoffe du hast mindestens dieses Release.
Wenn du getestet hast mache bitte ein paar verbose 5 Auszüge so wie oben jeweils im synch bzw. asynch mode.

Ich setze 9.5 ein und erhalte beim Ausführen von

Code Auswählen Erweitern

ALTER TABLE fhem.history ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);
folgende Fehlermeldung

Code Auswählen Erweitern

ERROR:  could not create unique index "history_pkey"
DETAIL:  Key ("timestamp", device, reading)=(2017-01-10 10:35:35, ESPEasy_ESP2_System, ram) is duplicated.

[DS_Starter]

Nabend Pyro,

ja, du hast in deiner history schon duplcate rows. War bei mir genauso.
Versuche es mal mit

ALTER IGNORE TABLE `history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);

Weiß allerdings nicht ob dieser Befehl MySQL-spezifisch ist. Möglicherweise heißt er bei Postgre anders um den PK trotz vorhandener Duplikate anlgen zu können. Probier mal, ich frage inzwischen Tante Google ...

EDIT: Also ich finde zu Postgre eigentlich nur, dass man in dieser Situation mit entsprechenden SQLs versucht die doppelten Sätze herausbekommen und dann löschen muß.
Hmmm ... wenn es geht dann würde ich vorschlagen die Test-history zu leeren "delete from history". Dann den PK wie beim ersten Versuch anlegen und DbLog dann loggen lassen um mit dem Test voranzukommen.
Wenn der Inhalt wichtig für dich ist, dann mache dir bitte vorher ein Backup damit du es später wieder einpielen kannst wenn nötig.

[Pyromane]

Leider nein.

Hier wird beschrieben wie man doppelte Einträge löscht, wobei ich noch überlege wie man dass an die history Tabelle anpassen kann.
http://www.it-iss.com/mysql/sql-removing-duplicate-records/