SVG-Diagramme laden mit neuer DbLog-Datenbank nur unvollständig

[justme1968]

es liegt ja nicht nur an der reinen datenmenge. nach einem neustart geht ja alles. erst nach etwa 4 tagen fängt es an.

obwohl die datenmenge scheinbar schon mit rein spielt. es sind wie gesagt 7 readings die alle 20 sekunden in der db landen.

die hardware an sich sollte nicht das problem sein. das ist ein 8 core xeon mit 48gig hauptspeicher. und vor dem update (von einer sehr alten fhem version) gab es das problem ja nicht.

die symptome sind halt typisch für unsauberes forken.

wenn es das nächste mal auftritt werde ich versuchsweise erst mal den async mode abschalten. geht es im betrieb? einfach attribut löschen? oder lieber abschalten, neu starten und warten?

[DS_Starter]

geht es im betrieb? einfach attribut löschen?

ja, genau.

[fraggle777]

Hallo zusammen,

ich habe bei mir jetzt im FHEMWEB plotfork = 0 gesetzt (vorher war es nicht explizit gesetzt) und damit scheint das Problem jetzt erstmal behoben zu sein. Danke für Euren Input!

Grüße

Philip

[DS_Starter]

Ich kann das Prob bei mir zwar immer noch nicht provozieren, aber habe zum Test die Get-Routine, welche die Daten für SVG bereitstellt, für SQLITE minimal angepasst.
Die V läuft bei mir ebenfalls tadellos.

Testet die bitte mal bei euch (wen das Prob betrifft).
Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben:

Code Auswählen Erweitern


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


Danach sollte ein "reload 93_DbLog" ausreichen.

@Philip, es ist zwar schön dass plotfork = 0 bei dir hilft, aber hat die unangenehme Eigenschaft dass dein FHEM blockieren / verlangsamt werden könnte wenn deine Datenbank nicht antwortet oder eine schlechte Performance hat.

Es wäre schon gut wenn wir da eine Lösung finden. Finde es halt eigenartig, dass ich es bei mir nicht nachstellen kann. Vllt. ist es auch von der Perl Version abhängig, bei mir die 5.28.1

[fraggle777]

Ich hatte zuerst die 93_DbLog mit der neuen Get-Routine probiert und das hat nichts gebracht. Danach habe ich ein FHEM update + restart gemacht und nochmal deine 93_DbLog runtergeladen. Jetzt scheint es zu funktionieren.

[DS_Starter]

Beobachte es mal längere Zeit.
Hast du auch wieder plotfork = 1 gesetzt bzw. gelöscht ?

[fraggle777]

Ja, plotfork habe ich auf 1 gesetzt.

[DS_Starter]

Gibt es weitere Erkenntnisse bezüglich der Testversion ?
Bei gibt es nach wie vor keine Auffälligkeiten.

[justme1968]

noch nicht. die 4 tage sind gerade rum und es sollte demächst wieder anfangen. ich achte drauf.

[justme1968]

ich habe gerade bemerkt das es wieder anfängt.

die dblog version von oben mit reload nachgeladen hilft leider nicht.

ich habe auch danach noch die oben beschriebenen probleme und sehe die fehler im log.

asyncMode deaktivieren hilft ebenfalls nicht.

ein fhem neustart hilft.

hast du noch eine idee?

[DS_Starter]

Ich hätte mich tatsächlich auch gewundert wenn es etwas geändert hätte aber Versuch war es wert. fragle777 hat sich auch nicht wieder gemeldet. Vllt. läuft es ja bei ihm.

Was mich eben sehr wundert ist die beschriebene Zeitabhängigkeit zu der mir ehrlicherweise nicht einfällt woran so etwas liegen könnte.
Im DbLog kannst du mit den Attributen SQLiteJournalMode bzw. SQLiteCacheSize den WAL Mode ausschalten oder die Größe des WAL Cache verändern. Vllt. kannst du damit experimentieren und es ergibt ein Ergebnis mit einem veränderten WAL.

[justme1968]

grad eben gesehen das das problem wieder da ist. nach nur ein paar stunden laufzeit.

ich habe jetzt auf die schnelle mal auf die letzte version zurück gewechselt und neu gestartet. mal sehen ob es damit wieder länger dauert.

das nächste mal spiele ich mal mit den parametern.

[fraggle777]

Also bei mir läuft es nach wie vor ohne Probleme.

[DS_Starter]

Moin zusammen,

also hat die kleine Veränderung doch zumindest bei fraggle777 etwas bewirkt.
Aber grundsätzlich glaube ich nicht daran das es dafür nur eine einzelne Ursache gibt.

Die bisherigen Erkenntnisse mal zusammengefasst:

* von mindestens 352 Definitionen mit SQLite haben fraggle777, justme1968 und erwin von diesem Problem berichtet, 
   wobei erwin grafana benutzt und demzufolge SVG bzw. die Get-Funktion von DbLog bei ihm nicht involviert sind

* bei mir und der überwiegenden Mehrzahl der User (sonst gäbe es noch mehr Meldungen) läuft die eingecheckte v4.12.1 tadellos

* die neue Testversion v4.12.3  läuft bei mir ebenfalls klaglos und hat bei fraggle777 offensichtlich das Problem gelöst

* justme1968 hat mit beiden Versionen dieses Problem, wobei es sich nur nach einer Laufzeit von X Stunden oder
  Tagen zeigt


Die Get-Funktion im DbLog kann man hier m.M. nach nicht allein "verantwortlich" machen. Möglicherweise spielen hier noch Faktoren wie Perl- bzw. Datenbankversion mit hinein.
Zum Vergleich nachfolgend meine Angaben dazu.
Die Perl/DBI/DBD Versionen seht ihr wenn ihr im DbLog-Device ein

Code Auswählen Erweitern

set <> configCheck

ausführt, gleich ganz oben:

* Used Perl version: 5.28.1
* Used DBI (Database independent interface) version: 1.642
* Used DBD (Database driver) version SQLite: 1.62

Im BS "sqlite3 -version":

* SQLite Version: 3.27.2 2019-02-25 16:06:06 


Mir fehlt momentan die Fantasie für einen weiteren Ansatz. Vielleicht habt ihr bzw. Rudi noch eine Idee aus einer anderen Richtung.

LG,
Heiko

[rudolfkoenig]

Mir fehlt momentan die Fantasie für einen weiteren Ansatz. Vielleicht habt ihr bzw. Rudi noch eine Idee aus einer anderen Richtung.

Damit man die Suche etwas einschraenken kann, schlage ich vor eine Log-Zeile in DbLog.pm einzubauen, die PID, bestellten Zeitraum, Anzahl der von der DB zurueckgelieferten Zeilen und Zeitstempel des letzten Datensatzes enthaelt. Dieses Log kann man aktivieren, wenn die SVG-Probleme auftreten, und hilft zu entscheiden, ob DbLog richtig aufgerufen wurde, und ob die DB alles zurueckgeliefert hat. Ich wuerde zusaetzlich die Ausgabe des SQL-Befehls vor dem Absetzen ausgeben, damit kann man evtl. sehen, ob das Problem mit der Reihenfolge zusammenhaengt.