Hallo Zusammen,
ich habe ein Android5-Wandtablet mit Webviewcontrol-App & Tablet UI als Client für mein fhem Rpi2, auf dem >100 Devices laufen. Das Wandtablet ist standardmäßig aus (Standby) und wird nur angestellt, wenn ich davorstehe. Dann synchronisiert es sich mit fhem.
Nun ist mir aufgefallen, dass der Load häufiger am Tag auf 1 geht (siehe Anhang) und das scheint zeitlich damit zu korrelieren, wann das Wandtablet angeht und synchronisiert. Auch die Netzwerktraffic-Kurve korreliert mit der Load-Kurve. apptime zeigt, dass unheimlich viele Events erzeugt werden (hier als Beispiel >1000 Events für ein einziges Mal starten des Wandtablets):
name function max count total average maxDly
WEBWandtablet_192.168.1.167_43730 FW_Read 199 1055 155081 147.00 0 HASH(WEBWandtablet_192.168.1.167_43730)
WEBWandtablet_192.168.1.167_43713 FW_Read 196 1046 156898 150.00 0 HASH(WEBWandtablet_192.168.1.167_43713)
WEBWandtablet_192.168.1.167_43726 FW_Read 193 990 151197 152.72 0 HASH(WEBWandtablet_192.168.1.167_43726)
WEBWandtablet_192.168.1.167_43721 FW_Read 192 1009 152891 151.53 0 HASH(WEBWandtablet_192.168.1.167_43721)
Ich habe zwar recht viele Readings auf meiner Tablet UI-Seite, aber 1000 Events pro Synchronisation finde ich doch sehr viel.
Außerdem frage ich mich, warum es mehrere WEBWandtablet_192.168.1.167-Einträge gibt (auf verschiedenen Ports?)
Hat das auch jemand bei sich beobachtet oder hat eine Idee, woran das liegen könnte?
Vielen Dank
Was bedeuten 1000 Events? Anfragen bei FHEM?
Ich würde mal auf einem Desktop Browser unter Netzwerkanalyse nachsehen, wie viele 'list' Kommandos an FHEM geschickt werden. Das hatte ich mal optimiert, dass nix doppelt abgefragt wird.
Wenn das Tablet aber mehrfach "online" Events bekommt, ist da noch Potential zum Optimieren. Dann dürfen nicht alle Events eine Voll-Synchronisation auslösen.
Laut apptime-Doku bedeutet count folgendes:
count: Anzahl der Aufrufe
Also über 1000 Aufrufe je Instanz und mind 4 Instanzen von WEBWandtablet.
Wenn ich die gleiche Tablet UI-Seite von meinem Desktop-Browser aufrufe ("WEB") gibt es das Problem nicht. Dann zeigt apptime nur ca. 10 Aufrufe der WEB-Instanz und auch nur eine WEB-Instanz....
Ich nehme an ein Aufruf ist ein Ajax-Request eines Readings?
Ja, letztes Mal als ich mit Tablet UI Debug getestet habe hat er etliche Male hintereinander ein online-Event angezeigt.
Wie kann ich in FHEM sehen, was Tablet UI an FHEM sendet (z.B. "list"-Komandos)?
ein "top" auf dem RPI zeigt > 95% CPU Auslastung von fhem über längere Zeit.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
12290 fhem 20 0 81832 76280 6968 R 95,7 8,0 38:02.32 perl
Kann man irgendwie sehen, womit fhem da beschäftigt ist (ausser mit apptime, was ich schon nutze)?
Hallo setstate,
habe mal mit tcpdump geschaut, was da so passiert. Das Wandtablet sendet hintereinanderweg ununterbrochen list-Kommandos an fhem mit den ganzen device-Namen und von verschiedenen Ports aus.
Mit debug eingeschaltet sehe ich bei Einschalten des Tablets, dass etliche "online"-events hintereinanderweg kommen.
Wenn ich das attr global verbose 5 einstelle, sehe ich auch tausende von list-Kommandos mit langen device-listen
WEBWandtablet_192.168.1.167_45882 GET /fhem/?cmd=list+...+&XHR=1&_=1454256645997; BUFLEN:0
(Ist das "BUFLEN:0" ok?)
und
Cmd: >list ....
wobei "..." ca. 30-50 devices aufzählt. Die kommen alle vom Tablet UI auf meinem Wandtablet...
Mein fhem Load-Problem scheint also davon zu kommen, dass fhem mit requests zugebommt wird ;)
Habe mal einen schnellen Fix eingebaut und damit scheint das Load-Problem bei mir behoben:
In fhem-tablet-ui.js folgendes angepasst (diff):
28,30d27
< /* setonlinefix */
< var lastsetOnline = 0;
<
125,136c122,127
< /* setonlinefix */
< var ltime = new Date().getTime() / 1000;
< if ((ltime - lastsetOnline) > 60){
< if (DEBUG) ftui.toast("Network connected");
< lastsetOnline = ltime;
< startShortPollInterval(500);
< if (!doLongPoll){
< doLongPoll = ($("meta[name='longpoll']").attr("content") == '1');
< if ( doLongPoll )
< startLongPollInterval(5000);
< }
< ftui.log(1,'FTUI is online');
---
> if (DEBUG) ftui.toast("Network connected");
> startShortPollInterval(500);
> if (!doLongPoll){
> doLongPoll = ($("meta[name='longpoll']").attr("content") == '1');
> if ( doLongPoll )
> startLongPollInterval(5000);
137a129
> ftui.log(1,'FTUI is online');
Vielen Dank, ich habe das so übernommen
Zitat von: FhemPiUser am 31 Januar 2016, 17:55:25
Habe mal einen schnellen Fix eingebaut und damit scheint das Load-Problem bei mir behoben:
In fhem-tablet-ui.js folgendes angepasst (diff):
28,30d27
< /* setonlinefix */
< var lastsetOnline = 0;
<
125,136c122,127
< /* setonlinefix */
< var ltime = new Date().getTime() / 1000;
< if ((ltime - lastsetOnline) > 60){
< if (DEBUG) ftui.toast("Network connected");
< lastsetOnline = ltime;
< startShortPollInterval(500);
< if (!doLongPoll){
< doLongPoll = ($("meta[name='longpoll']").attr("content") == '1');
< if ( doLongPoll )
< startLongPollInterval(5000);
< }
< ftui.log(1,'FTUI is online');
---
> if (DEBUG) ftui.toast("Network connected");
> startShortPollInterval(500);
> if (!doLongPoll){
> doLongPoll = ($("meta[name='longpoll']").attr("content") == '1');
> if ( doLongPoll )
> startLongPollInterval(5000);
137a129
> ftui.log(1,'FTUI is online');
Hallo, ich habe das gleiche Problem und möchte Deine Lösung gerne nutzen, kopiere ich jetzt einfach Deinen Code unten in die fhem-tablet.ui.js rein und es funktioniert? Oder wo kommt das genau hin?
Sorry bin leider Anfänger.
Danke
Das ist so in der aktuellen Version drin, da muss nix irgendwo rein kopiert werden. Du musst ein anderes Problem haben.
Ich habe sehr schlechte Performance bei FHEM auf dem Pi wenn ich das Frontend öffne und über APPTIME extreme hohe FW_READ Einträge ganz oben von meinem Wandtablet (IP).
Hört sich genauso an wie Euer Problem. Habe aber alles auf aktuellem Stand... komisch