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

[fraggle777]

Hallo zusammen,

ich hatte meine Frage zunächt im Frontend-Bereich gepostet (https://forum.fhem.de/index.php/topic,120217.0.html), aber vielleicht ist das dort gar nicht so gut aufgehoben und ich habe eher ein Problem mit meiner Datenbank. Daher die Frage nochmal an dieser Stelle.

Ich habe seit einer Weile Probleme mit meinen SVG-Plots. Wenn ich eine Seite mit SVG-Plots aufrufe, werden nicht immer alle Daten angezeigt. Wenn ich die Seite mehrfach aktualisiere, sind irgendwann alle Daten da. Die Daten sind alle in einer SQlite DbLog Datenbank abgelegt und die Probleme haben in dem Moment begonnen, als ich meine alte, total zugemüllte Datenbank gegen eine neue, leere Datenbank ausgetauscht habe.

Hat irgendwer eine Idee, woran das liegen könnte?

Viele Grüße

Philip

[justme1968]

ich habe keine idee, aber nach einem update vor kurzem das gleiche problem. sobald es mehr als einen plot auf der web seite gibt werden in den meisten plots nicht mehr alle kurven vollständig gezeichnet. manchmal die plus weiter unten sogar garnicht. meist kurven mit vielen daten. wenn ich den entsprechenden plot auf einer seite alleine öffne gibt es das problem nicht.

[erwin]

Hi,
hab auch keine Ahnung warum, die Symptome sind wie von justme1968 beschrieben, allerdings NICHT mit svg-plots,
sondern mit Grafana-plots (die werden mittels weblink- iframe eingebunden) , grafana macht die sql-queries und die generierung des html-seite,
daher geht meine Vermutung eher in Richtung Datenbank -  wo ich nix geändert habe. (DbLog- und SVG-Modul sind m.E. nicht involviert)
Es passiert allerdings nicht reproduzierbar und relativ selten, nach einem reload der page funktionierts (meist).
Könnte allerdings auch ein Browser-Problem sein (js? / mem?)
l.g. erwin

[rudolfkoenig]

Was SVG betrifft: ich habe "unlaengst" die Voreinstellung auf plotfork (bzw. plotembed=2, was plotfork beinhaltet) geaendert, wenn der FHEM Server mehr als eine CPU hat, damit holen mehrere Prozesse die Daten parallel aus der DB. Es waere ein Test wert, ob mit plotfork 0 das Problem immer noch auftritt.

Grafana holt Daten auch parallel (ein Prozess pro Grafik, mehrere pro Dashboard, aehnlich wie FHEMWEB), man kann die Anzahl der Arbeiterprozesse pro DB eingrenzen.

[DS_Starter]

Betreffend SVG bzw. FHEM-Bordmittel ... könnte ein evtl. zu klein definierter Wert im global attr blockingCallMax damit zusammenhängen ? Bin mir unsicher ob blockingCallMax hier eine Rolle spielt.
Für Grafana ist das natürlich außen vor.

[rudolfkoenig]

Betreffend SVG bzw. FHEM-Bordmittel ... könnte ein evtl. zu klein definierter Wert im global attr blockingCallMax damit zusammenhängen ?

Ja, aber nur dann, wenn:
- plotfork explizit auf ein Wert ungleich 0 gesetzt ist UND
- plotEmbed explizit auf 0 gesetzt ist oder man hat nur ein CPU oder das OS ist nicht Linux.

Ich muss irgendwannmal die vielen SVG/plotfork Varianten zusammenstreichen.

[justme1968]

ich versuche es mir genauer anzuschauen.

blockingCallMax hätte aber nur auf die anzahl der plots einfluss. d.h. es könnte die fehlenden plots unten auf der seite erklären.

das sollte aber alles nichts mit fehlenden werten in einem plot zu tun haben. nicht mit den fehlen von teilen einzelner kurven innerhalb eines plots.

was ich gerade ebene bemerkt habe weil ich einen screenshot machen wollte: direkt nach einem fhem neustart sind alle plots komplett. wenn fhem länger gelaufen ist fehlen teile.

[DS_Starter]

das sollte aber alles nichts mit fehlenden werten in einem plot zu tun haben. nicht mit den fehlen von teilen einzelner kurven innerhalb eines plots.

Das konnte ich bei mir bisher nicht beobachten (MySQL)
Ich habe mal eine Seite mit vielen Plots zusammengestellt und probiert ... kein Mangel zu sehen.

blockingCallMax = 15 eingestellt.

[justme1968]

hab mich nicht gemeldet weil nach einem neustart erst mal alles ok ist. nach jetzt 4 tagen fängt es langsam wieder an. es fehlen einzelne oder alle kurven einzelner plots wenn es mehrere plots auf einer seit gibt. bei jedem neuladen der steine etwas anders. je mehr punkte eine kurve hat um so wahrscheinlicher wird es scheinbar. am problematischsten ist meine strom seite mit den pv und verbrauchs werten. der haupt plot hat aktuell 6 kurven und werte alle 20 sekunden.

im ersten screenshot sieht man wie es aussehen sollte, in der anderen vieren vier zufällige varianten nach einem reload der seite.

andere plots bzw. kurven darin reißen zu unterschiedlichen zeitpunkten ab.

ich hatte auch schon die anzahl der offen browser tabs bzw. das limit der gleichzeitigen verbindungen vom browser zum server in verdacht. zumindest erstes macht aber keinen unterschied und letzteres sollte sich nur auf komplette plots und nicht einzelne kurven innerhalb eines plots auswirken.

hast du eine idee wie wir dem problem auf die spur kommen ?

[DS_Starter]

Hallo Andre,

eine Idee habe ich momentan nicht und kann nur mit Vergleichen dienen.
Ich habe jetzt vermuted es liegt vllt. an der Anzahl Linien innerhalb der Plots.
Habe zwei Testchats mit jeweils 7 Werten aus der DB. Das obere Chart ist mit MySQL, das untere mit SQLite.
Beide sind ohne Befund.

Im FHEMWEB habe ich eingestellt:

plotEmbed = 2
plotfork     = 1

Im global habe ich testweise sogar nur

blockingCallMax = 6

eingestellt.

Mehr kann ich leider nicht dazu beitragen bzw. hab keine Idee dazu.

[rudolfkoenig]

Im FHEMWEB habe ich eingestellt:
plotEmbed = 2
plotfork     = 1

Auf einem "normalen" Mehrkern-Rechner ist das die Voreinstellung, und blockingCallMax ist (wie vorhin geschrieben) irrelevant.

@justme1968: Wie sind diese Attribute bei Dir eingestellt?
Ich wuerde als naechstes im "kaputten" Zustand jeweils die beiden anderen Versionen testen:
- plotembed=2 und plotfork=1  => FHEMWEB liefert die Seite ohne SVG aus, JavaScript laedt die SVGs in parallel, bis zu 5 auf einmal
- plotEmbed=0 und plotfork=0  => die Seite wird mit allen SVG seriell berechnet und ausgeliefert
- plotEmbed=0 und plotfork=1 => die SVGs auf der Seite werden mit BlockingCall parallel berechnet, die HTML-Seite wird komplett mit SVG ausgeliefert. Wenn die Berechnung mit dieser Einstellung laenger als 90 Sekunden dauert, wiederholt Chrome den Request, was zu Chaos fuehrt.

[justme1968]

die anzahl der kurven in einem plot hat nichts damit zu tun. wenn es anfängt passiert auch bei plots die nur zwei kurven haben. es scheint eher mit der gesamt menge aller daten auf einer seite zu tun zu haben.

ich habe eben diverse Kombinationen von plotEmbed und plotFork probiert. plotEmbed scheint keinen einfluss zu haben, es tritt aber auf sobald plotFork auf 1 gesetzt ist. setze ich es auf 0 kann ich das problem nicht mehr reproduzieren.

was mir eben erst auffällt ist das es im log db fehler gibt wenn das problem auftritt:
meist

Code Auswählen Erweitern

2021.04.19 09:38:59 1: PERL WARNING: DBD::SQLite::st fetch failed: database disk image is malformed at ./FHEM/93_DbLog.pm line 3671.manchmal auch

Code Auswählen Erweitern

2021.04.19 09:38:53 1: PERL WARNING: DBD::SQLite::st execute failed: database disk image is malformed at ./FHEM/93_DbLog.pm line 3626.
das db image ist aber definitiv in ordnung. beim einfügen und wenn ich plotFork ausschalte gibt es keine solche meldung. auch wenn beim refresh die seite zufällig komplett aufgebaut wird (oder wenn der plot alleine auf der detail seite zu sehen ist) gibt es keine meldung.

ich tippe auf ein timing problem oder einen anderen seitenefekt der nur beim forken auftritt.


edit: ich habe fhem eben neu gestartet. danach sind alle plots ok und es gibt keine meldung im log.

das timing scheint also auch noch durch die laufzeit beeinflusst.

[rudolfkoenig]

Fuer parallele read/write Zugriffe verlaesst sich SQLite auf Filesystem-Locks, die in deinem Fall womoeglich nicht perfekt sind.
Ich wuerde mit WAL Mode experimentieren: https://sqlite.org/wal.html

[justme1968]

ich fürchte so einfach ist es nicht. wal mode wird von dblog aktiviert und ist an. vor dem update auch schon und da haben die plots funktioniert.

auch im asynchronous mode der aktuell aktiv ist haben wir ja nur einen writer und mehrere reader. dieser fall sollte funktionieren.

ich glaube eher das irgendetwas dazu führt das beim fork filedescriptoren nicht oder falsch geschlossen werden und sich parent und child in die quere kommen.

[DS_Starter]

Wollte deine Beobachtung jetzt mal provozieren und habe ein SQLITE-Plot sieben mal kopiert und alle 8 Plots mit jeweils 7 Wertelinien in einen Raum platziert.
Auch jetzt konnte ich kein Problem feststellen. Scheint für mich kein allgemeines Problem zu sein.
Mein FHEM ist aktuell.