FHEMWEB in einen Child Prozess Forken?

Begonnen von Dirk, 14 Mai 2013, 19:37:39

Vorheriges Thema - Nächstes Thema

Dirk

Hi zusammen,

ich hatte heute ein eigenartiges Phänomen.
Während dem Zugriff auf das Frontend über eine öffentliche WLAN->VPN Verbindung brach das WLAN zusammen, so das FHEM die Antwort des laufenden Request nicht mehr an den Client ausliefern konnte.

Das hat dann natürlich den kompletten FHEM Prozess lahm gelegt. Und konnte erst durch einen Kill -9 und anschließenden Restart behoben werden.

Daher die Idee alle FHEMWEB aufrufe in einen Childprozess zu forken.
Natürlich betrifft das dann auch andere Web basierte Zugriffe wie Floorplan usw.

Das ganze macht sich übrigens auch bemerkbar wenn SVG Grafiken auf etwas schwächerere Hardware aufgebaut werden.
Z.B. im Room "all" wenn alle  SVG's aufgebaut werden (ich nutze hier grade einen RasperyPi) blockiert das FHEM schon mal für gut 30 Sekunden.

Ich möchte das hier erst mal zu Diskussion stellen. Was meint ihr dazu?
Ich melde mich auch freiwillig das Ganze zeitnah anzugehen falls Rudi das nicht machen möchte :)

Gruß
Dirk

rudolfkoenig

> Das hat dann natürlich den kompletten FHEM Prozess lahm gelegt.

Ich wuerde das Problem durch verlagern der "print $c, ..." aus FHEMWEB_Read in die fhem.pl select Schleife loesen, da muss man ein write-Fall bauen.

Probleme mit Fork:
- longpoll geht nicht (oder nur aufwendig).
- die browser glauben, dass der Server beliebig belastbar ist, und stellen gerne mehrere Anfragen (2-8) parallel: das kann den Hauptspeicher eines kleinen Servers schnell ueberlasten, s.u.


> ... wenn alle SVG's aufgebaut werden ... blockiert das FHEM schon mal für gut 30 Sekunden.

Dafuer gibt es auch "plotfork", auf meinem Server ist es aktiviert. Das fuehrte auf einem Fritzbox wg. Speichermangel zum FB-Crash, deswegen habe ich den default vor paar Jahren umgestellt.


Wenn Du willst, kannst Du schon mal ein select-write patch erstellen :)

Dirk

Das das ganze nicht mal Ebend so schnell dahin programmiert ist und ggf. jede menge Seiteneffekte auftreten bzw. zu beachten sind, bin ich mir bewusst.

Zitatlongpoll geht nicht (oder nur aufwendig).
Für den Longpollprozess bedarf es dann natürlich eine bidirektionale Kommunikation mit dem Hauptprozess.

Zitatdie browser glauben, dass der Server beliebig belastbar ist, und stellen gerne mehrere Anfragen (2-8) parallel: das kann den Hauptspeicher eines kleinen Servers schnell ueberlasten, s.u.
Das würde ich über eine Limitierung der Kindprozesse für FHEMWEB lösen. Ggf. auch nur einer für besonders "schwachbrüstige" Hardware.

ZitatDafuer gibt es auch "plotfork".
Auch für SVG-Plots? Ich dachte das betrifft nur die Erstellung der Plots durch gnuplot.

ZitatWenn Du willst, kannst Du schon mal ein select-write patch erstellen
Ich schau mir das mal an. Ggf. eine Übergangslösung.
Den Fork finde ich dennoch sinnvoll.

justme1968

die aktuelle plotfork implementierung verträgt sich nicht mit dblog. wenn man ähnliche probleme beim forken des kompletten web frontends vermeiden will wäre vermutlich einiges an funktionalität im haupt prozess zu lassen und recht aufwendig mit dem child zu kommunizieren. die frage ist ob man dann hier nicht genau wieder die gleichen potentiellen problemstellen einbaut die mit dem forken gelöst werden sollten. die select-write idee hätte dieses risiko nicht.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Dirk

Zitatdie select-write idee hätte dieses risiko nicht.
Das ist wohl erstmal die schneller umzusetzende Idee.
Mein Vorschlag:
Ich implementiere hier ein zusätzliches foreach für eine $writelist.
Dann können das andere Module ebenso verwenden.