Performanceprobleme in fhem Webdiensten

[betateilchen]

Ich nutze auf einem Android-Tablet die App webviewcontrol in Kombination mit der html-Ausgabe von 02_RSS.pm. Darin gibt es einen meta refresh, um die Seite regelmäßig (alle 20 Sekunden) zu aktualisieren. Bisher lief das völlig problemlos.

Seit ein paar Stunden funktioniert der refresh nur noch maximal 15 Minuten, danach erfolgt keine Aktualisierung mehr. Am Tablet wurde nichts geändert.

Inzwischen habe ich alle "Verdächtigen" durchprobiert:

• SSL abgeschaltet
• Refresh von 20 auf 60 Sekunden umgestellt
• alle plotAsPng() Aufrufe im RSS Layout deaktiviert, um SVG als Ursache auszuschließen
• Das von RSS gelieferte PNG per img-Tag in eine eigene Webseite auf Apache eingebaut

Hat alles nix genützt. Sobald per http auf Daten aus fhem zugegriffen wird, bricht irgendwann der Refresh ab, weil offenbar die Daten nicht schnell genug von fhem geliefert werden. Danach erfolgt logischerweise auch kein neuer refresh mehr.

Habe ich irgendeine Änderung in fhem in den letzten Tagen verpaßt, die für dieses Verhalten verantwortlich sein könnte?

webviewcontrol als Ursache kann ich ausschließen, denn ein Webseitenrefresh einer fhem-freien Webseite funktioniert einwandfrei.

[rudolfkoenig]

...weil offenbar die Daten nicht schnell genug von fhem geliefert werden

Nach dieser Theorie waere FHEM 15 Minuten lang schnell genug, aber danch nicht mehr (?).  Browser warten normalerweise relativ lange auf dem Server bevor sie aufgeben, das wuerde bedeuten, dass dein FHEM mehrere Minuten lang komplett blockiert ist.

webviewcontrol als Ursache kann ich ausschließen, denn ein Webseitenrefresh einer fhem-freien Webseite funktioniert einwandfrei.

Ich sehe die Logik hinter dieser Beweisfuehrung nicht. Ich wuerde es lieber andersherum testen wollen: hast du das Problem  auch mit einem "normalen" Browser auf einem "richtigen" Rechner?

Mir fallen keine Aenderungen in der letzten Zeit in fhem.pl/FHEMWEB ein, die sowas ausloesen koennten.

Kannst Du bitte:
- in /proc/<fhempid>/fd pruefen, ob jemand FD's nicht geschlossen hat
- messen, wie lange ein request dauert, bzw. ob Haenger zu sehen sind. Vmtl. reicht ein "attr WEB verbose 4" dafuer aus.

[betateilchen]

Ich weiß schon, das ist alles sehr unspezifisch geschrieben.

webviewcontrol hört (seit neuestem) einfach irgendwann auf, http-requests zu verschicken, sobald ein Zugriff auf fhem in der Webseite enthalten ist. Das Ganze hat viele Monate völlig störungsfrei funktioniert - ich habe einfach keinen Ansatz, wo ich suchen soll. Dass fhem wirklich "schuld" sein soll, kann ich mir irgendwie auch nicht vorstellen.

Im Moment stehe ich in der Brotbackstube und bin am Teig kneten. Vielleicht habe ich heute abend wieder Lust, an diesem Fehlerbild weiterzusuchen.

[Dr. Boris Neubert]

Ich habe in den letzten Wochen an RSS gebasteltet - bin mir aber im Moment nicht im Klaren, was ich davon eingecheckt habe. Einen Zusammenhang mit einem Update vom RSS-Modul kannst Du ausschließen?

Grüße
Boris

[betateilchen]

Hallo Boris,

die letzte Änderung an 02_RSS.pm war Mitte September. Ich rede von einem Problem, das ich erst seit 3 oder vier Tagen habe. Kann also m.E. nichts mit dem letzten 02_RSS Update zu tun haben, da ich von meiner Seite nichts an meinen RSS-devices geändert habe.

[Dr. Boris Neubert]

Hallo Udo,

ich kann auch nur ein paar Schüsse ins Dunkel abgeben, basierend auf meinen Erfahrungen mit langlaufenden Erstellungen von RSS-Seiten und den Schwierigkeiten, die ich bei der noch nicht abgeschlossenen Umstellung der Auslieferung von RSS-Seiten aus einem nebenläufigen Kindprozess heraus gemacht habe.

- Hinweise von Rudi, insbesondere die Zugriffs- und Antwortzeiten mit verbose 5 oder so loggen
- siehe dazu auch meinen Thread zu "Hänger finden" sowie den Eintrag zu Filedescriptoren von mir im fhemwiki.de
- apptime benutzen
- ausprobieren, ob Problem auch mit dem Browser am PC auftritt
- Ist absolut ausgeschlossen, dass sich das Control aktualisiert hat, welches Webseiten auf dem Tablet anzeigt?
- Verbindet sich das Tablet mit einem anderen, entfernteren Access Point, so dass die Datenrate zu gering ist?

Viele Grüße
Boris

[betateilchen]

Ich wuerde es lieber andersherum testen wollen: hast du das Problem  auch mit einem "normalen" Browser auf einem "richtigen" Rechner?

Ich kann das Fehlverhalten in Google Chrome auf meinem Macbook Air reproduzieren, das Problem tritt nach ca. 10 refreshs auf. Danach erfolgt kein weiterer refresh mehr. Mal schauen, wie Safari sich verhält.

Der "Standard-Browser" auf meinem Android Tablet zeigt das Fehlverhalten auch.

[betateilchen]

Nachtrag: auch auf Safari...

[betateilchen]

Genau so wie das Problem aufgetreten ist, hat sich der Spuk wieder verabschiedet. Seit gestern abend 19 Uhr läuft alles wieder problemlos durch. Und ich habe definitiv nichts geändert.

Auf der einen Seite bin ich ja froh darüber, aber irgendwie beunruhigt mich das Ganze doch.

[Dr. Boris Neubert]

... aber irgendwie beunruhigt mich das Ganze doch.

Mich beunruhigt Fhem auch. Heute morgen habe ich einen mehrminütigen Hänger gehabt, obwohl RSS gerade gar nicht aufgerufen wird. Bis ich die Diagnosewerkzeuge ausgepackt hatte, lief dann alles wieder. Irgendein socket read oder write... Ich bekomme meine Installation ums Verrecken nicht so stabil und geschmeidig wie ich es brauche. Die heterogene Struktur mit x verschiedenen Systemen und multiple points of failure ist wohl der limitierende Faktor.

[betateilchen]

Ich bekomme meine Installation ums Verrecken nicht so stabil und geschmeidig wie ...

... es noch vor ca. einem Jahr möglich war

[betateilchen]

Der Spuk ist wieder da...

[herrmannj]

lösch mal per Telnet alle FHEMWEB.* Instanzen. Funzt bei mir und war im Forum auch bei anderen usern schon erfolgreich. Doof allerdings: wenn der refresh "durch ist" wird es der laufenden webview wohl jetzt nichts mehr bringen ...

[betateilchen]

lösch mal per Telnet alle FHEMWEB.* Instanzen. Funzt bei mir und war im Forum auch bei anderen usern schon erfolgreich.

hab ich gelesen, ist aber bei mir nicht das Problem.

[herrmannj]

Wen hast Du im Verdacht ?

[betateilchen]

Ich habe keinen Verdacht, das ist ja gerade das Beunruhigende

[Dr. Boris Neubert]

Ich konnte das Anschwellen des Speichers bei meinem FHEM-Server heute morgen definitiv auf das RSS-Modul zurückführen und ich vermute ein Speicherleck/fehlende Garbage Collection. Wie sieht die Resident Set Size für Deinen fhem-Prozess aus?

Grüße
Boris

[betateilchen]

Code Auswählen Erweitern

fhem     29616 18.3  6.4 144048 132076 ?       R    09:41  13:47 /usr/bin/perl fhem.pl configDB

[rudolfkoenig]

Und hier meins ohne RSS (d.h. RSS-Modul)

Code Auswählen Erweitern

rudi      1620  0.1  1.4  89332 29300 ?        S    Nov12   6:34 perl fhem.pl fhem.cfg

@betateilchen: wieso benoetigt dein FHEM 18.3% CPU?

[betateilchen]

keine Ahnung, das schwankt immer zwischen 0,3% und 95%, die meiste Zeit liegt der Wert aber unter 2%

[Dr. Boris Neubert]

CPU-Auslastung ist bei mir ähnlich.

Wird bei mir periodisch immer dann hochgejubelt, wenn ECMD die Daten von meinem NetMon entgegennimmt. Dasselbe passiert auch bei der Entgegennahme von Daten vom OWSERVER und bei Auslieferung von Daten via FHEMWEB/RSS (beide Module derzeit jedoch inaktiv).

Ich mache mich auf die Suche nach dem Speicherleck. Darüber berichte ich in dem ENOMEM-Thread im Developer-Board.

Grüße
Boris

[betateilchen]

Heute funktioniert der Webzugriff auf fhem wieder exakt fünf Minuten, bevor der automatische Refresh komplett ausfällt...

[betateilchen]

Wen hast Du im Verdacht ?

Inzwischen HABE ich tatsächlich einen Verdacht:  Die Fritzbox hier im Netzwerk, zu der ich derzeit keine Alternative habe und die sich vor zwei oder drei TAgen automatisch ein Firmwareupdate gezogen hat. Dadurch habe ich hier noch ein paar ganz andere Probleme: Ich kann z.B. nicht mehr per SMB auf mein HiDrive bei Strato zugreifen, weil NETBIOS jetzt komplett gefiltert wird und alle im Internet zu findenden Tricks keine Abhilfe (mehr) schaffen.

Seit heute abend kann ich überhaupt nicht mehr auf mein fhem zugreifen, weder per Frontend noch per RSS, also alles was Webservices angeht. Telnet geht, aber das hilft mir nicht wirklich weiter.

[herrmannj]

komisch aber es gibt ja alles. Du und 'ne fb ? 

Von innen oder von außen? Telnet geht, http nicht ? Das die fb die Kommunikation zwischen WLAN Teilnehmern unterbinden kann brauch ich Dir vermutlich nicht zu sagen .
Sicher das Du nicht doch das delete FHEMWEB.* mal testen möchtest ?

vg
 

[betateilchen]

komisch aber es gibt ja alles. Du und 'ne fb ?

Als Unitymedia Kunde hast Du keine andere Wahl, Du kriegst das Ding einfach aufgezwungen.

Von innen oder von außen? Telnet geht, http nicht

Nur im lokalen Netz.

Das die fb die Kommunikation zwischen WLAN Teilnehmern unterbinden kann brauch ich Dir vermutlich nicht zu sagen .

Die Fritzbox wird von mir ausschließlich als Kabelmodem genutzt, alles andere (WLAN, DHCP etc) ist abgeschaltet.

Sicher das Du nicht doch das delete FHEMWEB.* mal testen möchtest ?

Es gibt nur zwei FHEMWEB.* Instanzen, und die sind beide vom Laptop und nicht vom betroffenen Tablet.

[betateilchen]

Ich habe nun temporär die vorherige Version von 02_RSS.pm in mein fhem kopiert. Nun ist zumindest das Frontend wieder erreichbar. Auf dem Tablet läuft der automatische refresh nun auch wieder seit 15 Minuten durch.

Als ich die RSS Seite mit der aktuellen Modulversion testweise im Laptop Browser aufgerufen hatte, musste ich erkennen, dass

• das Image in der Seite nicht vollständig geladen wurde (die Webseite selbst aber schon)
• das Laden der Webseite niemals endete - erkennbar am rotierenden Kringel im Browsertab, das einen Ladevorgang signalisiert.

Mit der alten Modulversion sind bisher beide beschriebenen Effekte verschwunden. Es scheint so zu sein, dass aus irgendwelchen Gründen die Auslieferung der Image-Daten aus dem RSS Modul scheitert. Und eine Seite, die nicht vollständig geladen ist, wird vom Browser offenbar nicht automatisch neu geladen.

[betateilchen]

zu früh gefreut

Ein "list TYPE=FHEMWEB" liefert:

Code Auswählen Erweitern


FHEMWEB:192.168.123.161:58608
FHEMWEB:192.168.123.161:58609
FHEMWEB:192.168.123.161:58610
FHEMWEB:192.168.123.161:58611
FHEMWEB:192.168.123.161:58612
FHEMWEB:192.168.123.161:58613
FHEMWEB:192.168.123.241:45654
FHEMWEB:192.168.123.241:45655
FHEMWEB:192.168.123.241:45675
FHEMWEB:192.168.123.241:45700
FHEMWEB:192.168.123.241:45725
FHEMWEB:192.168.123.241:45752
WEB


.161 = Laptop
.241 = der cubietruck, auf dem fhem läuft.

Ich vermute fast, dass das Laden der rss-HTML Datei irgendwann daran scheitert, dass für das Laden der URL des eingebundenen RSS-Bildes eine http-Verbindung aufgebaut wird, die aus irgendwelchen Gründen nicht wieder geschlossen wird. Ansonsten wüßte ich nicht, warum der cubietruck zu sich selbst eine Webverbindung aufbauen sollte.



Nachtrag:

Das gleiche Problem (Verbindung wird nicht geschlossen) tritt auch auf, wenn man rss-Images per wget aus fhem abholen möchte.

[herrmannj]

ja, das es so ist kann ich definitiv bestätigen. Gerade wenn ich am webif was stricke und oft reloade seh ich das andauernd. Löschen und weiter gehts.Ich wollte Dich auch vorhin schon fragen wieso Du nur zwei hast obwohl ja mehr clients dranhängen. Normal müsste man den eof des clients abfangen.

[betateilchen]

Es geht eben nach dem Löschen NICHT zuverlässig/dauerhaft weiter. Und das manuelle Löschen der fhemweb Instanzen kann ja auch keine Lösung sein.

Ausserdem ist das Fehlverhalten neu. Ich nutze ja mein Tablet und mein RSS nicht erst seit ein paar Tagen. Und es hat die vergangenen Monate (meistens) durchgängig funktioniert.

[herrmannj]

ja, hast recht. Vmtl zwei getrennte Erscheinungen.

[herrmannj]

axo, dauerhaft sowieso nicht. Das (die fhemweb instanzen) bauen sich ja wieder auf.

[betateilchen]

Es HAT aber schon sehr lange durchgängig (dauerhaft) funktioniert. Und ich habe in meinen Anwendungen selbst nichts verändert.

Es ist übrigens KEIN ssl-Problem.

[herrmannj]

ja, ja. Früher  Schrei nicht so, ich sag ja nicht das ichs weiß. Ich drück Dir die Daumen.

[betateilchen]

Inzwischen HABE ich tatsächlich einen Verdacht:  Die Fritzbox hier im Netzwerk, zu der ich derzeit keine Alternative habe und die sich vor zwei oder drei Tagen automatisch ein Firmwareupdate gezogen hat.

Dieser Verdacht erhärtet sich. Ich habe heute Abend mein Netzwerk hier vor Ort komplett umgebaut, sodass sich die Fritzkotz nun komplett ausserhalb des lokalen Netzwerkes befindet. Das scheint sich (zumindest bisher) extrem positiv auf das gesamte Netzwerkverhalten hier auszuwirken.

[betateilchen]

Seit 12 Stunden alles in Ordnung - keinerlei Ausfälle/Störungen bei Nutzung der fhem Webdienste innerhalb des lokalen Netzwerkes mehr.

[herrmannj]

interessant, fb hat Verbindung unterbrochen ?

[betateilchen]

jepp, so siehts aus.

Das Netzwerk intern läuft seit der Verbannung stabil. Aber der gesamte Traffic ins Internet ist nach wie vor ein Fiasko. Heute habe ich mit Unitymedia telefoniert, man will mir den Schrotthaufen vorzeitig gegen ein reguläres Kabelmodem ohne Schnickschnack tauschen.

[betateilchen]

Also das mit dem vorzeitigen Austausch des AVM Schrotthaufens gegen ein ordentliches Kabelmodem hat erwartungsgemäß nicht stattgefunden. Aber da ich zum 31.01. ohnehin eine Komplettkündigung bei Unitymedia eingereicht habe, war man plötzlich sehr verwundert. Zum ersten Februar soll ich nun also von der AVM Hardware befreit werden und ein anderes Kabelmodem bekommen. Ich harre der Dinge, die mich dann erwarten, das Cisco Modem, das ich ganz am Anfang meiner Kundenzeit bei UM hatte, gibt es jedenfalls dort nicht mehr

[betateilchen]

Seit Sonntag ist der neue Kabelmodem-WLAN-Router von Unitymedia hier in Betrieb und hat die Fritzbox abgelöst. Was soll ich sagen? Bisher keinerlei Netzwerkprobleme mehr und auch die Einbindung meines Strato Hidrive als Netzwerklaufwerk funktioniert wieder absolut reibungslos