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

[DS_Starter]

Hi Joe,

danke dir !
Vielleicht wäre auch eine ganz einfache und für alle DBs passende Methode über ein eval auf die Tabelle currrent zuzugreifen:

Code Auswählen Erweitern

select count(*) from current;

und auszuwerten ob es fehlerfrei möglich ist oder ein Fehlercode zurückkommt. Wenn die Tab nicht da ist, irgendwie nicht zugreifbar ist, was auch
immer .... kommt auf jedenfall ein Code zurück und dann greift der else-Zweig von DbLog_sampleDataFn. Damit sollte man sicher sein denke ich.
Ist mir gerade an der frischen Luft eingefallen.....

Grüße
Heiko

[JoeALLb]

Ist mir gerade an der frischen Luft eingefallen.....

Frische Luft tut manchmal einfach gut Sehr gute Idee!
Diese Vorgehensweise bringt auch gleich einen Vorteil bezüglich Zugriffsrechte in den DBs mit:
Für den anderen Vorschlag bräuchten wir zugriff auf die die System-Tabellen (was zu mehr Supportaufwand bei manchen kommen könnte).


Edit: Formulierung

[DS_Starter]

Hallo miteinander,

wie oben angekündigt habe ich in der angehängten Version 2.13.5 nun zusätzlich zu den Anpassungen in der 2.13.4 (#163) noch einen check auf die Zugreifbarkeit der current-Tabelle bei der Erstellung von neuen Plots eingebaut.

Falls man das Attribut DbLogType auf "Current" oder "History/Current" gesetzt haben sollte und die current-Tabelle nicht vorhanden, nicht zugreifbar sein oder sie keine Datensätze enthalten sollte, wird das Eingabefeld "device:reading::" zur manuellen Angabe bei der Ploterstellung angezeigt.
Das Verhalten ist somit das gleiche als ob man das Attribut DbLogType nicht oder nur auf "History" gesetzt hat.

Das heißt im Umkehrschluß .... nur wenn das  Attribut DbLogType auf "Current" oder "History/Current" gesetzt ist UND die Tabelle current vorhanden ist UND diese Tabelle auch Einträge enthält, wird eine Drop-Down-Liste bei der Ploterstellung angezeigt.

Wenn man das Attribut DbLogType auf "Current" oder "History/Current" gesetzt hat und current nicht beschreibbar ist, kommt allerdings schon beim Logging eine Meldung im state. Es sollte also hinreichend auffallen. FHEM stürzt auf jeden Fall in dieser speziellen Konstellation nicht mehr ab.

Bitte übernehmt die Version für entsprechende Tests bei euch ...

Grüße
Heiko

[DS_Starter]

Hallo zusammen,

die Version 2.13.5 läuft bei mir (und offfensichtlich auch bei euch wie an den Downloadzahlen zu sehen ist) schon seit einigen Tagen problemlos und ohne Auffälligkeiten.
Ich werde die Version nun demnächst einchecken bzw. Tobias bitten es zu tun.

viele Grüße und einen guten Wochenanfang.
Heiko

[JoeALLb]

Hallo Heiko,
bei mir läuft's absolut Unauffällig, also alles bestens.
Besondere Tests konnte ich jedoch nicht machen.

SG Joe

[MichaelT]

2.13.5 bei mir auch ok

Grüsse
Michael

[DS_Starter]

Hallo Michael,

danke für die Rückinfo.

@all ...  habe die Version 2.13.5 soeben eingecheckt.

viele Grüße
Heiko

[DeeSPe]

Hallo Michael,

danke für die Rückinfo.

@all ...  habe die Version 2.13.5 soeben eingecheckt.

viele Grüße
Heiko

Danke Heiko!
Da Du ja mit alten Funktionen kompatibel geblieben bist, sollte es ja keine Probleme geben mit den neuen Funktionen.

Gruß
Dan

[DS_Starter]

Hi Dan,

ja denke ich auch ....

Ich hatte mich erstmal mit der Umstellung meiner IT beschäftigt (unten Profil). Jetzt will ich auch mal an das Upgrade meiner Synology ran. Die ist noch auf 5.2 ...
Wenn wir noch weiter am DbLog entwickeln wollen dauert es zumindest bei mir nun etwas länger 

Grüße
Heiko

[DeeSPe]

Mach mal ganz in Ruhe Heiko!
In den letzten Wochen hat sich hier echt viel getan. Würde sagen sogar mehr als ursprünglich angenommen.
Hab gerade mal über das eingecheckte diff geschaut, meine Herren das ist ordentlich.

Gruß
Dan

[DeeSPe]

Hab auf einem meiner Systeme mit MySQL ständig Folgendes im Log:

Code Auswählen Erweitern

2017-03-02 20:05:51 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:06:21 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:07:21 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:07:51 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:08:21 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:08:51 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:09:21 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:09:51 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:10:21 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:10:51 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:11:21 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:11:51 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:12:21 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:12:51 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:13:21 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:14:21 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:14:51 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:15:21 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:15:51 DbLog DbLog state: Commit already running - resync at NextSync



Gruß
Dan

[DS_Starter]

Hi Dan,

Da ist dir ein Hintergrund Prozess abgeschmiert.
Gib Mal ein Set reopen. Dann sollte sich das wieder fangen.

Grüße
Heiko

[erwin]

Hi Developers!
Erstmal herzlichen Dank für die Weiterentwicklung des Moduls- tolle Arbeit!

Ich bin gerade am Testen der reduceLogNbl funktion und möchte euch Feedback geben:
Folgende Werte hab ich erzielt:

Code Auswählen Erweitern

cmd: reduceLogNbl 426 average INCLUDE=HMS100TF%:temperature
result: Rows processed: 2931030, deleted: 2882204, updated: 48486, time: 12388.00sec
der nächste:
cmd: reduceLogNbl 426 average INCLUDE=RPI1_TempSensor:temperature
result: processed: 823290, deleted: 804200, updated: 19053, time: 3621.00sec

Interessant dabei die werte aus top vom fhem host:

Code Auswählen Erweitern

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
3174 fhem      20   0  331m 300m 3628 S  33.3 62.2  24:41.53 perl
2120 fhem      20   0 58724  32m 5464 S  12.0  6.7  95:21.68 perl
wobei pid 3174 der forked DbLog Task ist. grenzwertig ist die virt und res Zahl.
ich hab dann versucht das include etwas "weiter" zu fassen, dabei sind dann etliche 'cannot fork - out of memory' (von diversen tasks) gekommen.
Die letzte Zahl die ich gesehen habe war bei res: 400m, da sind dann freemem und swap schon sehr gegen null gegangen.

Environment: Fhem auf RPI-1, SQL Server auf QNAP419P
der sqldaemon (auf der QNAP) nimmt sich zw. 30 und 60% cpu während dem delete/update.
sql index hab ich den standart aus dblog. Gibts da noch Potential? ich hab da jetzt den Überblick im thread verloren....

l.g. erwin

[DS_Starter]

Hi Erwin,

herzlichen Dank für dein Feedback.
Ist wirklich interressant mal ein paar Zahlen "aus dem Leben" zu sehen.

Was mich mal interressiert .... wie war denn während der Laufzeit des reduceLogNbl  im Hintergrund (lief ja immerhin beim ersten Mal über 3 Stunden) das Reaktionsverhalten des FHEM auf dem RPi. Also lief alles andere noch gut ?
Wahrscheinlich ist es auf jeden Fall von Vorteil die DB auf einem anderen Server getrennt zu fahren. Denn der hat ja ordentlich CPU genommen während des Prozesses. Eine solche Umgebung habe ich ja ebenfalls, nur mit MariaDB auf Synology.
FHEM läuft jetzt mittlerweile auf einem NUC, das macht jetzt wirkich Freude 

Aber ich baue noch an meiner Synology rum, habe viele Updates nachzuholen und das läuft nicht so reibungslos.

Was die Indizes betrifft bin ich mir selbst noch nicht so eins mit mir. Zur Zeit habe  ich neben dem DbLog-Standardindex noch einen primary Key in der history und current (den nur zu Entwiclungszwecken) gesetzt und bilde mir ein dadurch Performancegewinn erzieht zu haben.
Den PK habe ich so angelegt:

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);
ALTER TABLE fhem.history ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);


Aber JoeAllb hat sich eine recht umfangreiche Testumgebung aufgebaut um verschiedene Index-Varianten zu testen.
Ich denke er kann dann noch Hinweise geben in welcher Konstellation er die besten Ergebnisse bei den verschiedenen DB's erziehlt hat.
Warten wir es mal ab.

LG
Heiko

[DeeSPe]

Hi Dan,

Da ist dir ein Hintergrund Prozess abgeschmiert.
Gib Mal ein Set reopen. Dann sollte sich das wieder fangen.

Grüße
Heiko

Moin Heiko,

konnte erst soeben Deinen Ratschlag testen.
Leider keine Änderung:

Code Auswählen Erweitern


2017-03-05 11:25:14 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:25:44 DbLog DbLog state: Commit already running - resync at NextSync
2017.03.05 11:25:55 3 : DbLog DbLog: Reopen requested.
2017.03.05 11:25:55 3 : DbLog DbLog: Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user root
2017.03.05 11:25:55 3 : DbLog DbLog: Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2017-03-05 11:25:55 DbLog DbLog state: connected
2017-03-05 11:25:55 DbLog DbLog CacheUsage: 5
2017-03-05 11:26:14 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:26:44 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:27:14 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:27:44 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:28:14 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:28:44 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:29:14 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:29:44 DbLog DbLog state: Commit already running - resync at NextSync
2017.03.05 11:30:07 3 : DbLog DbLog: Connection closed. Reopen requested in 10 seconds.
2017-03-05 11:30:07 DbLog DbLog state: closed for 10 seconds
2017-03-05 11:30:07 DbLog DbLog CacheUsage: 17
2017.03.05 11:30:17 3 : DbLog DbLog: Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user root
2017.03.05 11:30:17 3 : DbLog DbLog: Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2017-03-05 11:30:17 DbLog DbLog state: connected
2017-03-05 11:30:17 DbLog DbLog CacheUsage: 18
2017.03.05 11:30:17 3 : DbLog DbLog: Database connection reopen request finished.
2017-03-05 11:30:17 DbLog DbLog state: reopened
2017-03-05 11:30:17 DbLog DbLog CacheUsage: 19
2017-03-05 11:30:47 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:31:17 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:31:47 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:32:17 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:32:47 DbLog DbLog state: Commit already running - resync at NextSync

Hast Du noch eine Idee?

Gruß
Dan