Hallo zusammen,
ich habe FHEM auf einem INTEL NUC i5 mit einem Ubuntu 18.04 laufen. Daran ist ein Zwave Stick angeschlossen - sonst sind alle Geräte per LAN/WLAN angeschlossen.
Seit einiger Zeit habe ich das Gefühl, dass die Website von FHEM sehr träge ist. Habe dann mal im EventMonitor geschaut was so alles los ist, und konnte sehen, dass es viele Einträge von der INFLUXDB und MQTT2 Devices gibt.
Nach etwas nachlesen im Forum habe ich dann das INFLUXDB Modul von .* auf "nur Wichtige" Werte gesetzt und auch bei den MQTT Devices das attribut event-on-change-reading gesetzt.
Im Eventmonitor sieht es auch schon viel besser aus, aber die Website von FHEM ist immer noch träge. Wenn ich einen Raum anklicke, dauert 3-4 Sekunden bis die Seite vollständig geladen ist, obwohl dort nicht viele Geräte enthalten sind.
Folgende Module habe ich in FHEM noch aktiv:
- Homematic Gateway
- MAX CUL
- ROKU Server
- MQTT2 Server
- Harmony Geräte
- Chromecast Geräte
- Shelly Geräte als (MQTT Devices)
- habe DOIF durch mSwitch ersetzt
Die Auslastung des Systems liegt auch bei "null".
Wo könnte ich denn noch schauen warum das Frontend so langsam ist?
Das tritt auch bei verschiedenen Browsern auf.
Danke für eine Hilfestellung.
Gruß
Hermann
Hallo Hermann,
setz doch mal das Modul freezemon ein, um evtl. "Bremsen" ausfindig zu machen. Im ersten Schritt müsstest Du bereits mit dem Standardsetup die ersten Anhaltspunkte finden können.
Grüße Markus
Ist global dnsServer gesetzt?
Ciao, -MN
(Viele) Plots mit vielen Daten (evtl. noch aus "vor-event-on-change-reading-Zeiten")?
plotfork etc. entsprechend gesetzt!?
Gruß, Joachim
Und dann noch entsprechend große "altlogfiles" ...
Zitat von: Wernieman am 03 Februar 2020, 13:03:09
Und dann noch entsprechend große "altlogfiles" ...
So war's gemeint ;)
Gruß, Joachim
@Joachim,
@Wernieman,
ich nutze noch filelogs und suche nach einer Motivation auf DbLog umzusteigen.
Derzeit habe ich 32 Diagramme incl. Tabellen.
Würde es nach Umstellung spürbar schneller gehen alle Diagramme zu laden?
Viele Grüße Gisbert
Zitat von: Gisbert am 03 Februar 2020, 16:24:08
@Joachim,
@Wernieman,
ich nutze noch filelogs und suche nach einer Motivation auf DbLog umzusteigen.
Derzeit habe ich 32 Diagramme incl. Tabellen.
Würde es nach Umstellung spürbar schneller gehen alle Diagramme zu laden?
32 Diagramme auf einer Seite??
Als ich damals auf DBLog umgestellt habe war es spürbar schneller (war glaube ich noch auf dem 1er oder 2er Raspi). Plotfork etc... hast du gesetzt?
ZitatWürde es nach Umstellung spürbar schneller gehen alle Diagramme zu laden?
Haengt davon ab, was alles in den FileLog Dateien gespeichert wird.
Finden der aktuellen Position in der Datei ist schnell, die DB kann aber vmtl. schneller nach den benoetigten Zeilen filtern.
Wenn die FileLog Datei mehr oder weniger optimal ist, dann wird bei der Erstellung etwa 40% im FileLog und 60% in der SVG-Code verbracht.
Zitat von: KernSani am 03 Februar 2020, 16:57:33
32 Diagramme auf einer Seite??
Als ich damals auf DBLog umgestellt habe war es spürbar schneller (war glaube ich noch auf dem 1er oder 2er Raspi). Plotfork etc... hast du gesetzt?
Hallo KernSani,
Hallo Rudi,
32 Diagramme, Tabellen, Wetterdaten nur dann auf einer Seite, wenn ich
alles lade.
plotfork kann ich leider nicht auf dem Handy setzen, da ich den flex style nutze - und da geht aus Gründen, die ich nicht verstehe, plotfork nicht, bzw. die Diagramme sehen sonst richtig Sch... aus.
Auf dem Handy lade ich natürlich nicht alles auf einmal, sondern nur einzelne Räume, aber das dauert auch einige Sekunden für ein halbes Dutzend Diagramme.
Am PC habe ich plotfork, dann geht das Laden des Textes schneller, bis alle Diagramme geladen sind, dauert es dort auch.
Ich nehme das als Motivation um auf DbLog umzustellen, aber eins nach dem anderen - die Wiki-Seite dazu ist ja nicht gerade kurz.
Viele Grüße Gisbert
Schau lieber erstmal, ob es nicht helfen würde, die Logfiles auszudünnen (event-on-change ggf. mit Threshold).
Kurz, weil mobil
Hallo KernSani,
Ausdünnen der log-files erscheint der richtige Tipp zu sein, werde das beherzigen; vermutlich habe ich bei meiner Sammelwut übertrieben.
Viele Grüße Gisbert
Und auch nachsehen, ob alle Diagramme sinnvoll sind. Je mehr Datenpunkte in einem Diagramm, desto langsamer
@Gisbert Such Dir eine Motivation etwas zu machen was Spaß macht, ich würde lieber wandern gehen oder so etwas. :D
Aber wegen der Darstellungsgeschwindigkeit von FileLog auf DbLog umzustellen - auf der gleichen Maschine - davon rate ich wirklich ab. Vor allem denke nicht dran alte Datenbestände in die Datenbank zu migrieren. Ich will nicht sagen, dass das alles nicht geht oder nichts bringt.
Ich meine: Ein saubere FileLog ist in der Darstellung genauso schnell wie eine saubere Datenbank.
Ungünstige Daten Strukturen (so in der Art T: 23 H: 56 D: 27) werden bei DbLog sogar langsamer als bei FileLog dargestellt.
Also wenn Du willst, bau ein DbLog auf und experimentiere damit und stell dann vielleicht das Logging um. Aber ich rate: migriere nicht wegen der Darstellungsgeschwindigkeit.
Aber wir haben jetzt den Thread gekapert? :o
geht denn grafana mit FileLog? Deshalb bin ich damals zu DbLog gewechselt.
Gesendet von iPad mit Tapatalk Pro
Hi,
ich habe mein Problem gefunden.
Ich habe noch 2 LaCrosseGateways per WLAN angeschlossen (WEMOSD1). Diese waren wohl nicht richtig mit FHEM verbunden. Nach einen reboot beider Gateways war wieder alles schnell.
Noch zu Info: Ich habe in FHEM keine Plots. WIe schon beschrieben habe ich alle in eine INFLUXDB geschrieben und lasse mir die Daten mit Grafana anzeigen (über NODERED). Das klappt wunderbar.
Hat die DBLog Vorteile?
Ich habe dblog mal bei meiner ersten Installation von FHEM gehabt. Lief auch....aber da gab es noch keine Schnittstelle zu Grafana.
Vielen Dank für die Hinweise zum beheben meines Problems.
Gruß
Hermann