SVG mit dblog extrem langsam

[DS_Starter]

Ich habe dir eine Version im contrib zur Verfügung gestellt.
Umgestellt ist die configCheck Funktion.

Für alle Checks wird die DB-Verbindung nur einmal zu Beginn aufgebaut.
Es wird jetzt auch die benötigte Zeit für den Verbindungsaufbau gemessen und ausgegeben:

Code Auswählen Erweitern


Available Drivers in your system

DBD::DBM, DBD::ExampleP, DBD::File, DBD::Gofer, DBD::Mem, DBD::Pg, DBD::Proxy, DBD::SQLite, DBD::Sponge, DBD::mysql

Result of version check

Used Perl version: 5.28.1
Used DBI (Database independent interface) version: 1.642
Used DBD (Database driver) version mysql: 4.050
Used DbLog version: 5.5.10.
Your local DbLog module is modified.
Recommendation: You should update FHEM to get the recent DbLog version from repository ! Your DBD version fulfills UTF8 support, no need to update DBD.

Result of configuration read check

Connection parameter store type: file
Connection parameter: Connection -> mysql:database=fhemtest;host=192.168.2.44;port=3306, User -> fhemtest, Password -> read o.k.

Result of connection check

Connection to database fhemtest successfully done.
The time required to establish the connection was 0.0017 seconds
Recommendation: settings o.k.
......


Zum Download in der FHEMWEB Kommandozeile inklusive der Anführungszeichen angeben und danach FHEM restarten:

Code Auswählen Erweitern


"wget -qO ./FHEM/93_DbLog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbLog.pm"


Wenn meine Therie stimmt, wirst du eine 20 s Verzögerung feststellen (die auch ausgegeben wird), aber nach dieser Zeit ein Ergebnis angezeigt bekommen.
Du siehst im Vergleich dazu braucht meine MariaDB 0.0017 Sekunden für den Verbindungsaufbau.

[RockThisParty]

Hi!
Vielen Dank!!
Du hast recht. configCheck sagt

Code Auswählen Erweitern

Available Drivers in your system

DBD::DBM, DBD::ExampleP, DBD::File, DBD::Gofer, DBD::MariaDB, DBD::Mem, DBD::Pg, DBD::Proxy, DBD::SQLite, DBD::Sponge, DBD::mysql

Result of version check

Used Perl version: 5.28.1
Used DBI (Database independent interface) version: 1.642
Used DBD (Database driver) version Undefined
Used DbLog version: 5.5.10.
Your local DbLog module is modified.
Recommendation: You should update FHEM to get the recent DbLog version from repository !

Result of configuration read check

Connection parameter store type: file
Connection parameter: Connection -> mysql:database=fhem;host=192.168.178.2;port=3306, User -> fhem, Password -> read o.k.

Result of connection check

Connection to database fhem successfully done.
The time required to establish the connection was 20.0187 seconds
Recommendation: The time to establish a connection is much too long. There are performance problems that hinder operation.

Result of encoding check

Encoding used by Client (connection): UTF8
Encoding used by DB fhem: UTF8
Recommendation: settings o.k.

Result of insert mode check

Insert mode of DbLog-device logdb is: Array
Recommendation: Setting attribute "bulkInsert" to "1" may result a higher write performance in most cases. Feel free to try this mode.

Result of plot generation method check

WARNING - at least one of your FHEMWEB devices has attribute "plotfork = 1" and/or attribute "plotEmbed = 2" not set.

WEB: plotfork=1 / plotEmbed=2
WEB_refresh: plotfork=1 / plotEmbed=2
WEBapi: plotfork=0 / plotEmbed=0
WEBhook: plotfork=0 / plotEmbed=0

Recommendation: You should set attribute "plotfork = 1" and "plotEmbed = 2" in relevant devices. If these attributes are not set, blocking situations may occure when creating plots. Note: Your system must have sufficient memory to handle parallel running Perl processes. See also global attribute "blockingCallMax".


Result of table 'history' check

Column width set in table history: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by device logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: settings o.k.

Result of table 'current' check

Column width set in table current: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by device logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: settings o.k.

Result of check 'Search_Idx' availability

Index 'Search_Idx' exists and contains recommended fields 'DEVICE', 'TIMESTAMP', 'READING'.
Recommendation: settings o.k.

Result of check 'Report_Idx' availability for DbRep-devices

At least one DbRep-device assigned to logdb is used, but the recommended index 'Report_Idx' is missing.
Recommendation: You can create the index by executing statement 'CREATE INDEX Report_Idx ON `history` (TIMESTAMP,READING) USING BTREE;'
Depending on your database size this command may running a long time.
Please make sure the device 'logdb' is operating in asynchronous mode to avoid FHEM from blocking when creating the index.
Note: If you have just created another index which covers the same fields and order as suggested (e.g. a primary key) you don't need to create the 'Report_Idx' as well !

Ich mache mich mal dran, die Empfehlungen durchzuarbeiten.

[DS_Starter]

Hi,

die Empfehlungen durchzuarbeiten wäre der 2. Schritt.
Das Hauptproblem ist die Zeit um einen Connect herzustellen. Hier würde  ich dir empfehlen im Synology Forum zu recherchieren bzw. evtl. an den Support zu schreiben.

Was hast du für eine Syno ?
Ich glaube mich zu erinnern, dass ich selbst mal Probleme mit Syno hatte bzgl. der Login-Daten Prüfung die ewig dauerte.
Vllt. finde ich ich noch wie ich das damals gelöst hatte.

Ich bin jetzt dabei die Datenlieferung an SVG umzustellen.
Das funktioniert aber nur mit plotfork = 0. Wenn plotfork = 1 gesetzt ist, brauche ich immer einen neuen Connect zur DB und du hast dann diese Verzögerung bei dir.

[RockThisParty]

Hi!
Ich habe gerade mal in einem frischen Container ein zweites frisches FHEM aufgesetzt und nur DBLog mit Zugriff auf dieselbe Datenbank definiert.
ConfigCheck und SVG völlig problemlos.
Ich denke, im nächsten Step übernehme ich mal die komplette Konfig ins neue FHEM.
Mal sehen ...

[RockThisParty]

Nachtrag: Damit ist ja die DB an sich erstmal raus, DNS-Probleme nicht unbedingt ...

[DS_Starter]

Ich habe jetzt gerade eine Version in mein contrib geladen, welche die Datenlieferung bei dem Attr plotfork = 0 optimiert.
Mit dieser Version und plotfork = 0 wirst du nur beim ersten SVG Aufruf die Verzögerung spüren, dann nicht mehr.

Trotzdem solltest du versuchen dein Problem zu lösen.  -> Sorry, dein Post kam gerade zuvor 

Auf jeden Fall ist mit dieser V die Connect Verwaltung für SVG's mit plotfork = 0 optimaler, wobei User mit schnellem DB Verbindungsaufbau keinen Unterschied merken werden.

[RockThisParty]

Super, vielen Dank!
Die Verbesserung mit plotfork=0 kann ich wie von Dir erwartet bestätigen.
Ich werde berichten, wie meine Tests weitergehen und Dir zeitnah mehr als einen Kaffee ausgeben!

[DS_Starter]

  viel Erfolg !

Bis später ....

[RockThisParty]

So, nun sage ich mal wieder gute Nacht für heute 
Wenn reichlich irritiert. Habe meine komplette Konfig in den neuen Container kopiert und der Fehler tritt nicht mehr auf.
Habe noch nicht ganz alle Details durch, aber
a) Port ist anders. Aber: Änderung des Ports am "Original" verscheucht den Fehler nicht.
b) Fehler tritt mit alter dblog-Version und neuer in der neuen Umgebung nicht auf. Ebenso haben alle sonstigen Updates nichts verändert.

Zwei drei kleinere Änderungen fehlen noch zwischen den Containern. Morgen mal sehen ...

[Wernieman]

Was mir auf die schnelle Einfällt ...
in was für ein Netzwerkmodus betreibst Du die Docker-Container?

[RockThisParty]

Moin!

Ich bin gestern nicht mehr dazu gekommen, da weiter zu machen und heute wird es wohl auch nicht viel.

Aber über die Frage Netzwerk-Modus habe ich auch schon nachgedacht.

Mein "Originaler"-FHEM-Container mit dem Problem läuft im Host-Mode, da ich bei der Einrichtung das für irgendeinen Dienst brauchte. Mir ist nur noch nicht wieder eingefallen, was das mit ?Multicast? war.

Die Test-Kopie ohne Probleme läuft im Bridge-Mode. Das will ich noch testen.

[DS_Starter]

Jetzt weiß ich wieder wo ich schonmal über ewig lange login-Zeiten gestolpert bin. ->
https://forum.fhem.de/index.php/topic,105714.msg1194447.html#msg1194447

Lösche doch mal die Datei

           /tmp/login_fail.list

Sofern vorhanden (auf der Syno).

[RockThisParty]

Aaaalso:

• login_fail.list gibt es nicht. Das kann es also schon mal nicht sein.
• NAS Neustart hat nichts geändert.
• Test Bridge Mode folgt.

[RockThisParty]

So, ich kann jetzt bestätigen, dass das Problem eindeutig nur auftritt, wenn der Container im HOST-Mode läuft.

Nun habe ich aber leider tatsächlich keine Idee mehr, wie ich es verscheuchen kann.

Wenn nicht noch jemand von Euch einen besseren Vorschlag hat, schaue ich mal, dass ich mein produktives FHEM in den Bridge-Mode überführe (was ja nicht so schwer ist ... ich bin nur noch unsicher welche neuen Probleme oder Einschränkungen ich mir einhandele ... brauche ich für HUE, Deconz, HMIP Multicast? Ich glaube eigentlich nicht?)

[RockThisParty]

Ich schulde Euch noch eine Auflösung ... sorry, dass das so lange gedauert hat. War wenig Zeit.

Total blöd: Das ganze Problem / Fehlerbild war nach einem Neustart der Fritz!Box verschwunden. Es lang offenbar an irgendwelchen DNS-Hängern/-Altlasten in der Box.

Drauf gekommen bin ich irgendwann bei der Testerei, weil an einer Stelle systematisch URLs zu FHEM nicht aufgelöst wurden, mit IP statt Name ging es dann.

Ärgerlich. Tut mir leid, dass ich damit so viel Aufruhr erzeugt habe. Danke für alle Unterstützung!! ... Für mich kann ich festhalten, dass ich mal wieder viel über FHEM gelernt habe und nebenbei einige Dinge aufgeräumt / verbessert habe.