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

[DS_Starter]

Ja, so etwas ähnliches habe ich zur Problemlösung bei Postgre auch gefunden. -> aufwändig. Deswegen würde ich für das Testscenario erstmal mit einer leeren history arbeiten wie in meinem EDIT oben geschrieben ... wenn es geht .
Einfachere Lösung scheint (weiter unten) gefunden.

[DS_Starter]

Hallo Pyro,

nachdem ich deinen Link etwas genauer gelesen habe könnte das folgende Statement eventuell funktionieren um die rows zu löschen:

Code Auswählen Erweitern

DELETE FROM history WHERE ctid IN (SELECT MAX(ctid) FROM history GROUP BY TIMESTAMP, DEVICE, READING HAVING COUNT(*) > 1);

[Pyromane]

Ja, so etwas ähnliches habe ich zur Problemlösung bei Postgre auch gefunden. -> aufwändig.

Ich habe es jetzt mal versucht und es schaut ganz gut aus:

Code Auswählen Erweitern

DELETE FROM fhem.history WHERE TIMESTAMP IN (SELECT MAX(TIMESTAMP) FROM fhem.history GROUP BY TIMESTAMP, DEVICE, READING HAVING COUNT(*) > 1);

DELETE 421030
Query returned successfully in 25 secs.

Code Auswählen Erweitern

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

ALTER TABLE
Query returned successfully in 14 secs.

[DS_Starter]

Prima  ...
Jetzt bin ich gespannt ob die Insert-Statements im Modul klappen ...

[Pyromane]

Auszug ausm Log:

Code Auswählen Erweitern

2017.02.10 23:09:27 5: DbLog myDbLog -> Primary Key used in fhemdaten.history: "timestamp" device reading
2017.02.10 23:09:27 5: DbLog myDbLog -> Primary Key used in fhemdaten.current: none
....
2017.02.10 23:09:27 5: DbLog myDbLog -> 3 of 3 events successfully inserted into table history
2017.02.10 23:09:27 5: DbLog myDbLog -> 3 of 3 events successfully updated in table current

[DS_Starter]

Na das ist doch Klasse ! .. sehr schön 
Darauf kann ich aufbauen und sehe mal zu auch noch den PK-Support für die current einzubauen. Das Verhalten liegt hier etwas anders weil wir versuchen wollen ein update oder insert in einem Step in die Tabelle zu bringen.

Aber heute nicht mehr. 

Danke Pyro und gute Nacht. Melde mich wieder.

Heiko

[Pyromane]

Danke Pyro und gute Nacht. Melde mich wieder.

Danke, dir auch eine gute Nacht

[DS_Starter]

Hallo Pyro,

habe jetzt nach langem hin und her wahrscheinlich eine Lösung für die current-Tabelle gefunden.
Probiers mal nach bewärtem Muster, der PK ist allerdings nur:

Code Auswählen Erweitern

ALTER TABLE current ADD PRIMARY KEY (DEVICE, READING);

Die V2.12.5, hier angehängt, habe ich auch noch bzgl. der Log-Ausgaben für verbose 5 für die PK Unterstützung verbessert.
Sollte das so nicht funktionieren, kannst du im asynch mode die Zeile 1431 für diverse Versuche abändern. Im synch mode wäre das Zeile 1078.

Grüße
Heiko

[JoeALLb]

spannend, was sich hier tut!!
Da ich PostgresQL nicht nutze, bin ich da im Moment weniger involviert, ich werde es aber noch in meinen Benchmark
mit aufnehmen, um die unterschiedlichen Geschwindigkeiten darstellen zu können.

Weiß jemand, warum DbLog die Datenabfrage mit

Code Auswählen Erweitern

select * where 1=1...
beginnt?Ist das Programmtechnisch, um die anderen Statements mit "and" anhängen zu können?

Joe

[Pyromane]

Hallo Heiko,

auch in der current Tabelle waren Einträge doppelt vorhanden, aber nach einem "truncate" war das Problem beseitigt.

Code Auswählen Erweitern

2017.02.11 13:53:10 5: DbLog myDbLog -> Start DbLog_PushAsync
2017.02.11 13:53:10 5: DbLog myDbLog -> Primary Key used in fhemdaten.history: timestamp,device,reading
2017.02.11 13:53:10 5: DbLog myDbLog -> Primary Key used in fhemdaten.current: device,reading
2017.02.11 13:53:10 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 13:53:07, Device: mySysMon, Type: SYSMON, Event: loadavg: 0.00 0.08 0.07, Reading: loadavg, Value: 0.00 0.08 0.07, Unit:
2017.02.11 13:53:10 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 13:53:07, Device: mySysMon, Type: SYSMON, Event: ram: Total: 3008.29 MB, Used: -2975.06 MB, -98.90 %, Free: 5552.51 MB, Reading: ram, Value: Total: 3008.29 MB, Used: -2975.06 MB, -98.90 %, Free: 5552.51 MB, Unit:
2017.02.11 13:53:10 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 13:53:07, Device: mySysMon, Type: SYSMON, Event: ens3_diff: RX: 0.04 MB, TX: 0.02 MB, Total: 0.06 MB, Reading: ens3_diff, Value: RX: 0.04 MB, TX: 0.02 MB, Total: 0.06 MB, Unit:
2017.02.11 13:53:10 5: DbLog myDbLog -> 3 of 3 events successfully inserted into table history using PK on columns timestamp,device,reading
2017.02.11 13:53:10 2: DbLog myDbLog -> Error: DBD::Pg::st execute_array failed: ERROR:  syntax error at or near "EVENT"
LINE 2: ...STAMP, DEVICE=EXCLUDED.DEVICE, TYPE=EXCLUDED.TYPE EVENT=EXCL...
                                                             ^ [err was 7 now 2000000000]
executing 3 generated 3 errors at ./FHEM/93_DbLog.pm line 1481.

2017.02.11 13:53:10 5: DbLog myDbLog -> DbLog_PushAsync finished
2017.02.11 13:53:10 5: DbLog myDbLog -> Start DbLog_PushAsyncDone
2017.02.11 13:53:10 5: DbLog myDbLog -> DbLog_PushAsyncDone finished

[DS_Starter]

Ach ja, habe Kommata vergessen ...

Hier nochmal V2.12.5.  Die andere Version nehme ich raus.

[DS_Starter]

Hi Joe,

Ist das Programmtechnisch, um die anderen Statements mit "and" anhängen zu können?

don't know. Aber deine Vermutung klingt plausibel.

[Pyromane]

Scheit zu funktionieren 

Code Auswählen Erweitern

2017.02.11 14:15:28 5: DbLog myDbLog -> Start DbLog_PushAsync
2017.02.11 14:15:28 5: DbLog myDbLog -> Primary Key used in fhemdaten.history: timestamp,device,reading
2017.02.11 14:15:28 5: DbLog myDbLog -> Primary Key used in fhemdaten.current: device,reading
2017.02.11 14:15:28 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 14:15:04, Device: ESPEasy_ESP2_Raum, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 14:15:28 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 14:15:04, Device: ESPEasy_ESP1_WW_WW, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 14:15:28 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 14:15:05, Device: ESPEasy_ESP1_KW_KW, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 14:15:28 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 14:15:06, Device: ESPEasy_ESP1_RA_UM, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 14:15:28 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 14:15:06, Device: ESPEasy_ESP1_FB_RL, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 14:15:28 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 14:15:07, Device: ESPEasy_ESP1_FW_UM, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 14:15:28 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 14:15:07, Device: ESPEasy_ESP1_FW_RL, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 14:15:28 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 14:15:07, Device: ESPEasy_ESP1_FW_VL, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 14:15:28 5: DbLog myDbLog -> 8 of 8 events successfully inserted into table history using PK on columns timestamp,device,reading
2017.02.11 14:15:28 5: DbLog myDbLog -> 8 of 8 events successfully updated in table current using PK on columns device,reading
2017.02.11 14:15:28 5: DbLog myDbLog -> DbLog_PushAsync finished
2017.02.11 14:15:28 5: DbLog myDbLog -> Start DbLog_PushAsyncDone
2017.02.11 14:15:28 5: DbLog myDbLog -> DbLog_PushAsyncDone finished

Welche Szenarien soll ich durchtesten?

[DS_Starter]

Great 

Welche Szenarien soll ich durchtesten?

Erstmal freuen 

Dann würde ich vorschlagen folgendes zu testen:

1. asynch mode -> sowohl für history, current PK definiert
2. asynch mode -> nur PK für history
3. asynch mode -> nur PK für current
4. synch mode -> sowohl für history, current PK definiert
5. synch mode -> nur PK für history
6. synch mode -> nur PK für current

Dann kannst du bitte auch mal probieren wie das Modul sich verhält wenn der Nutzer z.B. für die current ein Feld noch hinzunimmt, also den PK so aufbaut wie für die history. Interessant wären auch die Ausgaben wenn man versucht tatsächlich einen Datensatz doppelt einzufügen. Möglicherweise kannst du das provozieren.
Zum Schluß leere mal deine current Tabelle und lasse sie neu aufbauen. Die entsprechenden Insert-Meldungen sollten dann auch im Log eingetragen werden und die Current-Tabelle gefüllt werden.

EDIT: ich vergaß, baue dir auch mal einen neuen Plot mit Hilfe der Vorschläge aus der current auf.  Und schau ob die Inserts/Updates auch tatsächlich in den Tabellen ankommen, aber das hast du sicher schon kontrolliert ... 

EDIT2: auch mal in beiden Modi ganz ohne PK testen ob das nach wie vor gut klappt (also der Standard beim User)

LG
Heiko

[Pyromane]

Great 

Erstmal freuen 

Leider etwas zu früh gefreut, der Log aus meinem vorigen Beitrag war der letzte der erfolgreich in die history Tabelle geschrieben werden konnte, seitdem erhöht sich der CacheUsage ständig und der Log füllt sich damit:

Code Auswählen Erweitern

....
2017.02.11 15:19:38 5: DbLog myDbLog -> 231 of 231 events successfully inserted into table history using PK on columns timestamp,device,reading
2017.02.11 15:19:38 2: DbLog myDbLog -> Error: DBD::Pg::st execute_array failed: ERROR:  current transaction is aborted, commands ignored until end of transaction block [err was 7 now 2000000000]
executing 231 generated 228 errors at ./FHEM/93_DbLog.pm line 1481.