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

[DS_Starter]

Nee, nicht sicher. Der memCache hat auch eine direkt aufsteigende Reihenfolge. Das ist eine Anzeigesache. Damit habe ich schonmal gekämpft. Normal kann man mit

Code Auswählen Erweitern


sort {$a <=>$b} keys (%hash)


numerisch sortieren. Hatte aber für die Anzeige nicht geklappt. Aber kann es heute Abend nochmal versuchen.
Danke für den Patch ...  prima  baue ich so ein.

Grüße
Heiko

[JoeALLb]

Nachtrag:
Folgende Fehlermeldung erhalte ich noch in rauhen Mengen;
Die Ursache verstehe ich jedoch nicht, denn $UNIT wird in Zeile 2702 initialisiert...

Code Auswählen Erweitern

Use of uninitialized value $UNIT in string ne at ./FHEM/93_DbLog.pm line 2713.
Use of uninitialized value $unit in concatenation (.) or string at ./FHEM/93_DbLog.pm line 2716.
Use of uninitialized value $unit in concatenation (.) or string at ./FHEM/93_DbLog.pm line 2717.


sG
Joe

[JoeALLb]

Hallo Heiko,

ich habe meinen Patch nochmal verkürzt....

Code Auswählen Erweitern

1029,1030c1029
<       my @exdvs = devspec2array(AttrVal($name, "excludeDevs", ""));
<   for(@exdvs){s/\n/,/g}
---
>       my @exdvs = devspec2array( AttrVal($name, "excludeDevs", "") =~ s/\s*\n\s*/,/gr );



sG Joe

[DS_Starter]

Nabend Joe, @all,

ich habe meinen Patch nochmal verkürzt....

Ich auch  . Habe allerdings den Modifikator /r nicht verwendet weil er erst ab perl 5.14.0 eingeführt wurde. Nicht dass es dann an dieser Stelle Probleme gibt.

Desweiteren ist die addLog-Funktion umgebaut. Jetzt wird auch die Standard-Splittingfunktion für das Event verwendet in der dann auch DbLog_splitFn durchlaufen wird sofern sie vorhanden ist.
Der Aufruf hat sich dadurch geändert in:

Code Auswählen Erweitern


set <device> addLog <devspec>,<Reading>,[Value]


Value ist optional, kann aber gesetzt werden um einen spezifischen Wert zu setzen wenn gewünscht.
In der DB wird nur noch der Feldwert von "Event" auf "addLog" gesetzt. TYPE wird devspec-spezifisch geloggt.

Die Sortierung habe ich sogar auch so wie ich es in #240 schon geschrieben habe verbessern können. Weiß nicht wieso es mir bisher nicht gelungen war.

Bitte wieder die neue Version 2.16.1  testen ...

Grüße
Heiko

[Icebear]

Hallo,
ich hänge mich mal mit ran
Bevor ich den thread fand, hatte ich schon einen Beitrag gepostet.
Ich habe bei mir den Index erweitert um die Spalte "value".
Sinn des ganzen ist, das zumindest mal die Plot den Timestamp, device, reading und value brauchen.
Die ersten 3 sind im Index. ABer um den Value rauszufinden ist ein Tablejoin nötig. Das kostet Resourcen.
Indem Value im Index ist entfällt dieser Tablejoin und die Plots (gerade mit historischen zb. Jahresdaten) werden wesentlich schneller aufgebaut.
(siehe auch Explain befehl mit und ohne value im Index)
Ein Insert dauert natürlich ein klein bisle länger, da aber nicht 100te Datensätze pro Sekunde in die DB geschrieben werden dürfte das zu vernachlässigen sein.

Und noch ne anmerkung: Es gibt bei Mariadb/Mysql auch ein Replace Into. Ist unter manchen Umständen besser geeignet als ein insert into... on duplikate key
Grüße aus Dinslaken
Icebear

[JoeALLb]

Hallo icebear,

danke für dein Feedback und das Einbringen von Ideen, das ist immer sehr hilfreich!

Hast Du zu diesen Ideen auch nähere Informationen, bzw. hast Du auch Messungen durchgeführt??

Ich habe bei mir den Index erweitert um die Spalte "value".

Ich habe Benchmarks mit verschiedenen Datenbank/Indexkonfigurationen durchgeführt, dabei war auch ein "covering index", also indexe in denen der value auch enthalten war.
In Benchmarks hatte dies (nach den anderen Verbesserungen wie DB-Engine wechseln, ...) keinen messbaren Vorteil (mehr), selbst bei komplexen Abfragen die mehrere Minuten rechneten oder bei tausenden Abfragen auf eine kalte bzw. warme Datenbank.
Der Unterschied beim Lesen war nicht messbar, der negative Unterschied beim insert jedoch merkbar. (Die Inserts waren ca. 7% langsamer).
Lt. bisherigen Messungen fallen hier Einflussfaktorie wie Unicode, Tabellentyp (Aria vs. MyISAM vs. innoDB, ...).

Meine aktuell gemessen beste Konfiguration unter MariaDB habe ich in diesem Post:
https://forum.fhem.de/index.php/topic,65860.msg599526.html#msg599526
dokumentiert.

Und noch ne anmerkung: Es gibt bei Mariadb/Mysql auch ein Replace Into. Ist unter manchen Umständen besser geeignet als ein insert into... on duplikate key

Aktuell ist Replace into in Verwendung! Dies wird jedoch nur bei der current-Tabelle benötigt und hier ist aktuell zuvor immer eine insert-Prüfung notwendig, um fetszustellen, ob der Datensatz erstmalig eingefügt werden muss.

"into... on duplikate key" fügt diese zwei Schritte zu einem zusammen, und ist somit lt. Messung etwas performanter für diejenigen, die die current-Tabelle noch verwenden.

Solltest Du zu deinen Tests noch weitere Erkenntnisse haben, zögere bitte nicht, diese mit uns hier zu teilen! DbLog wird gerade
stark mordernisiert und aktualisiert und die Möglichkeiten hier begeistern mich sehr!

sG
Joe

[JoeALLb]

Hallo Heiko,

Ich auch  . Habe allerdings den Modifikator /r nicht verwendet weil er erst ab perl 5.14.0 eingeführt wurde. Nicht dass es dann an dieser Stelle Probleme gibt.

Verstehe und ist gut... aber ich mag /r im Zusammenhang mit regexp und mit diesen kenn ich mich wenigstens ein bisschen mehr aus als mit perl

Desweiteren ist die addLog-Funktion umgebaut. Jetzt wird auch die Standard-Splittingfunktion für das Event verwendet in der dann auch DbLog_splitFn durchlaufen wird sofern sie vorhanden ist.

Funktioniert! Hatte dies um Mitternacht schon erfolgreich getestet!

Die Sortierung habe ich sogar auch so wie ich es in #240 schon geschrieben habe verbessern können. Weiß nicht wieso es mir bisher nicht gelungen war.

Zum debuggen ein netter Zusatz, danke fürs umsetzen! Am Handy im kleinen SSH-Client ist die Sortierung für den Überblick recht wichtig!!

Code Auswählen Erweitern

$lv = "" if(!defined($lv));

Das nutze ich auf einem anderen Gerät das ich im Moment nicht updaten kann (bin nicht vor ort, kein Zugang).
Ich habs jedoch auf meiner Liste für den nächsten Besuch!


Noch eine Frage: Wie sollen wir mit splitFn und Devices zukünftig umgehen?
Sollen wir für Devices, die bisher nicht passend mit DbLog zusammenarbeiten, wie letztens beim ZWAVE-Modul, in den Code mit aufnehmen
oder sollen wir dafür einfach den valueFn-Code posten?
Aktuell teste ich den Code für das yowsup-Whatsapp-Modul...
Hier wird bei

Code Auswählen Erweitern

received from <number>
die Nummer in die Unit-Spalte geloggt.


Schöne Grüße
Joe

[Icebear]

Hallo,

gibt es ein Testscript was die Performance misst in den "üblichen" fhem konstellationen ?
Ich habe meine erkenntnisse vom sehen (aktualisieren von Plots) und durch die Erkenntnisse auf der Firma (Ziemliche grosse Buchhaltungsdatenbank die ich betreue und auch die Software für die Datenbank die ich entwickel).
Den Umschwung auf Ariadb find ich schonmal gut. Ich weiss im moment noch nicht warum Innodb die Defaultdatenbank geworden ist. Ariadb ist bei mir auf der Firma auch wesentlich performanter ...
Zum Replace Into: Warum ist vorab ein Insert Into nötig ? Replace Into macht genau das. Wenn der Pri Schlüssel trifft werden die Felder geupdatet ansonsten ein neuer Datensatz eingefügt ?!

[JoeALLb]

@Heiko:

Anbei etwas spezielleres, was mir heute aufgefallen ist. Ob das so nutzbar/übernehmbar ist, kann ich nicht entscheiden.

Anbei ein Patch, der die Routine DbLog_explode_datetime von der Benutzung mehrerer Splits zu einem Regex abändert.
Zusätzlich habe ich die Berechnung des Detaultwertes nur dann vorgenommen, wenn dieser auch tatsächlich benötigt wird.

Dabei erziehle ich folgendes Ergebnis:

Code Auswählen Erweitern

Ergebnis der bisherigen Routine: 2017-04-04_11:58:59 00:00:00
Ergebnis der neuen Routine:      2017-04-04 11:58:59
Ergebnis der neuen Routine:      2017-04-04 11:58:59
           Rate bisher_1  Test2_2  Test3_2
bisher_1 2271/s       --     -62%     -64%
Test2_2  6028/s     165%       --      -4%
Test3_2  6287/s     177%       4%       --

Die neue Variante ist lt. meinen Tests (Zeile1 vs. Zeile3) also um ca. 177% also fast 3x so schnell. Statt 2271/s Durchläufe schafft die neue Variante 6287.
Sie ist zudem auch flexibler, da sie mit dem Datum  '2017-04-04 11:58:59' als auch  '2017-04-04_11:58:59' umgehen kann.
Aktuell wird dazu per regex das "_" in " " ersetzt.

Um sicher zu gehen habe ich dafür auch eine Testroutine geschrieben, die auch die Laufzeiten misst.
Diese Datei befindet sich im Anhang und kann über

Code Auswählen Erweitern

./bench-regex2.pl  '2017-04-04_11:58:59' gestartet werden


sG
Joe

[DS_Starter]

Hi Joe,

Noch eine Frage: Wie sollen wir mit splitFn und Devices zukünftig umgehen?

Meiner Meinung nach sollte zukünftig die Implementierung der Device- bzw. modulspezifischen Funktion "DbLog_splitFn" in allererster Linie für das Splitting und die Bereitstellung der Units zuständig sein.
Tobias hatte sich auch schonmal so geäußert und wenn ich mich recht erinnere soll das Splitting im DbLog-Modul mehr und mehr entfernt werden.
Aber ich würde, wie letztens bei ZWAVE, das Splitting hier mit aufnehmen bis der entsprechende Modul-Maintainer die DbLog_splitFn implementiert hat.
Allerdings bin ich nicht der DbLog-Maintainer, auch wenn es sich momentan so anfühlt weil ich/wir in den letzten Monaten viel dafür getan habe/n.
Vielleicht äußert sich Tobias nochmal dazu.

Danke für den Patch Joe ... klingt interessant weil sich die Plot Erstellungszeiten wahrscheinlich verringern könnten. Aber wir würden direkt in den Plotprozess eingreifen.
Deswegen schlage ich vor den jetzigen Entwicklungsstand erstmal zu dokumentieren, finalisieren und euch zum finalen Test bereitstellen um ihn dann einzuchecken.
Deswegen hätte ich noch gern die Bestätigung ob die Änderung von

Code Auswählen Erweitern


$lv = "" if(!defined($lv));


sich wirklich positiv ausgewirkt hat. Sonst würde ich diese Änderung wieder auf Original zurücknehmen.

Danach können wir deinen Patch mal mit angehen um es wirklich intensiv zu testen ob / wie sich diese Änderung auswirkt, ok ?

Grüße
Heiko

[JoeALLb]

Code Auswählen Erweitern


$lv = "" if(!defined($lv));


Mir ist eingefallen, wie ich es testen kann, ob es zumindest dem bisherigen Ergebnis entspricht... aber heute nicht mehr, ist zu spät.

Gute Nacht, bis morgen!

[DS_Starter]

Gute Nacht Joe. Habe es auch gerade bei mir getestet.
Funktioniert nicht gut ... es gint dann Probleme mit dem MinIntervall.
Ich habe es wieder zurück auf Originalzustand gebracht.

Bis morgen..

Grüße
Heiko

[JoeALLb]

Danke für den Patch Joe ... klingt interessant weil sich die Plot Erstellungszeiten wahrscheinlich verringern könnten. Aber wir würden direkt in den Plotprozess eingreifen.
Deswegen schlage ich vor den jetzigen Entwicklungsstand erstmal zu dokumentieren, finalisieren und euch zum finalen Test bereitstellen um ihn dann einzuchecken.

Gerne! Um eben keine negativen Auswirkungen zu haben (hoffentlich), habe ich extra den kleinen Benchmark geschrieben, der auch unterschiedliche Eingaben und Versionen
prüfen und vergleichen kann. Es ist kein eiliges Thema, aber bei einem so zentralen Modul, das auf die  meisten Event reagiert, ist es sicherlich lohnenswert.

Hast Du noch eine Idee zum Ändern des Timestamps in valueFN, oder sollen wir diesbezüglich auch noch etwas warten?

schöne Grüße
joe

[Icebear]

hallo,
seh ich das richtig, das die Splitfunktion für die einzelnen Felder in die einzelnen Module verlegt werden soll?
Damit würde eventuell (endlich) das Chaos mit den verschiedenen Fehlerhaften Logging aufhören ..(Values die keine SInd usw ...)
Wie würde das mit Modulen aussehen, die von keinem mehr gewartet werden ?
(aktuell habe ich kleinigkeiten am Modul 19_Revolt gepacht, die aber nicht offiziell. Meine Frage ob das Modul noch jemand wartet liefen ins leere ..)
Ich würde das dann da übernehmen wollen (nachdem das ganze auf neuem Stand ist, weils wohl nicht mehr den Richtlinien entspricht) aber bräuchte da dann wohl Hilfe weils das erste Modul wäre was ich "offiziell" betreue ..
Aber das währe der falsche Thread hier
Grüße aus Dinslaken
Icebear ak Holger

[JoeALLb]

seh ich das richtig, das die Splitfunktion für die einzelnen Felder in die einzelnen Module verlegt werden soll?

Hallo Holger,

korrekt!
Näheres dazu findest Du unter:
https://wiki.fhem.de/wiki/DbLog#Bereitstellung_der_UNITS und
https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_DbLog_split

Module, die nicht mehr gewartet werden können mit dem neuen Attribut "valueFn" aus V2.16.1
von jedem selbst "korrigiert" werden, jedoch ist der ideale Weg sicherlich die Einbindung von SplitFn.

@Heiko:
Vielleicht wäre diese Ergänzung im Log hilfreich um weitere Maintainer dazu zu bekommen, ihre Module um splitFn zu ergänzen?

Code Auswählen Erweitern

718a719,721
>   else{
>     Log3($name, 3, "DbLog: The FHEM-Module for $device,$type does not support DbLog_splitFn. Please ask the Maintainer to fix it.");
>   }