Folgt https://forum.fhem.de/index.php/topic,41791.0.html
Moin,
ich muss vor der Verwendung des Attributes createGluedFile warnen, da dies eine enorm hohe Schreiblast erzeugen kann, wenn
- Geräte häufig Daten loggen
- diese in SVGs (Diagrammen) im Browser (ggf. sogar in mehreren Tabs, im Hintergrund über Nacht etc.) geöffnet sind
! Pro geloggtem Ereignis (Logzeile), werden pro angezeigter SVG (Diagramm) zwei Logs vollständig kopiert, also noch nochmal auf die Platte geschrieben.
Kommen also pro Sekunde neue Werte rein und umfasst ein Log 10 MB, werden pro Sekunde 2x 10 MB kopiert.Das kann insbesondere bei SSDs oder USB-Sticks ein Problem werden.
Dass createGluedFile nun temporäre Dateien erzeugt, hatte ich in der Ref kurz gelesen. Dass nun die SVG-Darstellung (Diagramme) diese Zusatzlast explodieren lassen, war ohne Codelesen und Tests nicht so deutlich/klar.
Das Problem tritt insbesondere auf, wenn logProxy mit der Option extend=1 (oder größer) aktiviert ist. (Ggf. auch, wenn endPlotNow aktiv ist?)
Das Problem tritt häufiger auf, wenn der Log(datei)wechsel statt gefunden hat, also ggf. ein täglicher Logwechsel statt findet.
Dies zur Information.
---
Nach der Erkenntnislage kann ich abwägen: Funktion ergänzen, verbessern, ersetzen oder Logwechsel wieder ändern.
Ich habe mich vorerst für letzteres entschieden.
Auf logProxy bzw. der Option extend zu verzichten, wäre auch eine Möglichkeit. Jedoch sind dann die SVGs (Diagramme) beim Tageswechsel zweideutig. (Gerät ausgefallen oder Log "kaputt"?)
Außerdem sind bei einem Monatswechsel höhere Performanceprobleme zu verzeichnen.
Gibt es denn aktuell eine ressourcenschonendere Überarbeitung? Ich habe zwischenzeitlich einige Ergänzungen gesehen, aber grundlegend?
Gibt es ggf. die Möglichkeit die temporäre Datei im Arbeitsspeicher zu erzeugen?
Ich hatte bei der Fehlerlösung kurz über das Verschieben des RESCAN-Gotos gedacht, so, dass tatsächlich das vorige Log erst geöffnet wird, wenn es benötigt wird...
Hintergrund:
Ich hatte wegen (notwendigem) höherem Logging mehrerer Geräte von Monats- auf Tageswechsel umgeschalten, um so das Laden der SVGs (Diagrammen) zu beschleunigen. Das hatte zunächst gut funktioniert.
Am nächsten Tag sehe ich jedoch in den SVGs (Diagrammen) nichts mehr.
Heraus kommt, dass logProxy mit der Option extend den Vortag, aktuellen und nächsten Tag abfragt.
Jedoch klebt createGluedFile nur das Log für den Vortag und für den nächsten Tag zusammen. D.h. der aktuelle Tag wird ignoriert. Die Ergebnismenge ist demnach leer.
Das Gegenstück wäre das Longpolling im Frontend zu deaktivieren oder von Mausbewegungen/Aktivitäten etc. abhängig zu machen.
Gruß, Robert
ZitatIch hatte wegen (notwendigem) höherem Logging mehrerer Geräte von Monats- auf Tageswechsel umgeschalten, um so das Laden der SVGs (Diagrammen) zu beschleunigen.
Das kann ich nicht nachvollziehen. Die Suche nach dem Tagesanfang wird per binaere Suche (wobei das Ergebnis gemerkt wird) erledigt. Aus Erinnerung: Zeitraubend ist das Einlesen/Splitten/Filtern der Daten (40%) und daraus ein SVG zu rechnen (60%), und nicht die Suche nach dem Tagesanfang in der Datei.
Ich verwende Jahreslogs, und habe deswegen keine Probleme.
Danke für die spannenden Zahlen. Du meinst ich sollte versuchen den Flaschenhals ausfindig zu machen.
(Wie schaffst du es deine Antworten kurz zu halten. Eigentlich wollte ich ja hier nur auf das Schreiblastproblem bei mehreren geöffneten SVGs hinweisen. :) )
ZitatGibt es ggf. die Möglichkeit die temporäre Datei im Arbeitsspeicher zu erzeugen?
Mir fiel gestern spontan ein STDIN/STDOUT zu missbrauchen... oder ich erzeuge die temp.-Datei in einer eigens dafür angelegten RAM-Disk (...). Vlt. gibt es jedoch noch etwas eleganteres? (Um das Attribut praxistauglich zu machen, da dieses doch von vielen häufig verwendet wird.)
ZitatDie Suche nach dem Tagesanfang wird per binaere Suche (wobei das Ergebnis gemerkt wird) erledigt.
Den Positionscache habe ich flüchtig gesehen. Wird dieser beibehalten, wenn sich die Datei ändert? Das Log wird doch vor der Suche immer wieder neu geöffnet, wenn ich das richtig gesehen habe?
Was hat es mit dem RESCAN auf sich? Das sah mir nach einem Fallback aus, wenn die Position zunächst nicht gefunden wird (und dort vlt. die gesamte Datei geladen wird?).
---
Es war festzustellen, dass beim Reload der SVGs zunächst gar nichts zu sehen war, anschließend die Punkte, Linien mit sichtbarer Verzögerung gezeichnet wurden.
Grundsätzlich ist mir die Ladeverzögerung nicht wichtig. Jedoch bei fortlaufend neuen Events ist letztlich von der SVG kaum etwas zu sehen, da diese permanent am Neuaufbauen ist.
Eine andere Idee war die SVG erst zu laden und dann zu tauschen (mit der alten).
Werden die Daten für das Zeichnen der SVGs mit einmal gesendet oder nach und nach? (...)
Auf welchen Zeitpunkt beziehen sich deine Performancedaten? April 2016? (r11274). Sonst beisze ich mich dort heute Abend mal durch das svn up und die Folgen... (Überprüfung eigene Anpassungen, eigene Module etc.)
ZitatJedoch bei fortlaufend neuen Events ist letztlich von der SVG kaum etwas zu sehen, da diese permanent am Neuaufbauen ist.
Verwendest du longpollSVG? Das war nur als demo gedacht, um zu zeigen dass das so nicht sinnvoll machbar ist, und das Ganze anders angegangen werden muss, mein Favorit waere eine SVG-Implementierung in JS. Daran baue ich alle 2 Jahre immer wieder ein bisschen, wenn meine TODO-Liste leer ist. :)
ZitatAuf welchen Zeitpunkt beziehen sich deine Performancedaten? April 2016?
Das ist eher/gefuehlt 4-5 Jahre her, als ich das zuletzt optimiert habe. Ich meine aber, dass sich seitdem nicht viel geaendert hat. Habe aber nichts gegen aktuelle Zahlen.
Du meinst, dass die SVG initial aufgebaut wird und anschließend nur noch mit den neuen Punkten nachversorgt wird.
Die Events kommen ja grundsätzlich reingeschneit in den Browser. Kann man ggf. zwei SVGs per JS mergen?