Blocking functions: BlockingCall, SubProcess, CoProcess, HttpUtils_NonblockingGe

Begonnen von KölnSolar, 08 Januar 2020, 10:22:17

Vorheriges Thema - Nächstes Thema

DS_Starter

Ich habe jetzt meine erste Implementierung mit SubProcess.pm in DbLog vorgenommen  (https://forum.fhem.de/index.php/topic,130588.0.html)

Das funktioniert sehr gut bisher und ich komme gut voran.

Eine Frage bewegt mich allerdings.
In SubProcess wird in run() ein einmaliger fork vorgenommen. D.h. der neue Perl Prozess hat den gleichen RAM-Verbrauch wie der Eltern Prozess zu dem Zeitpunkt.

Kann man es irgendwie bewerkstelligen dass der Subprozess nur mit einer "Minimal-Version" startet und dementsprechend wenig RAM verbraucht ?
Ich vermute eher nicht wenn ich die Grundlagen, die hier im Thread erläutert werden, richtig verstanden habe.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

rudolfkoenig

ZitatD.h. der neue Perl Prozess hat den gleichen RAM-Verbrauch wie der Eltern Prozess zu dem Zeitpunkt.
Ich versuchs etwas genauer: Der allozierte Speicher besteht aus (4k?) Bloecken, diese werden beim Fork als "Copy-On-Write" markiert.
D.h. ein Block wird erst dann kopiert, wenn einer der beiden versucht was in diesem Block zu aendern. Im "Normalfall" muss man wenig kopieren, deswegen erlaubt der Kernel auch dann den fork(), wenn nicht genuegend Speicher zum kopieren aller Bloecke zur Verfuegung steht (Stichwort overcommit, die Voreinstellung ist 50% und man kann es aendern).
Wenn sich rausstellt, dass doch nicht genuegend Speicher zur Verfuegung steht, dann wird einer beiden Prozesse abgeschossen(!).

ZitatKann man es irgendwie bewerkstelligen dass der Subprozess nur mit einer "Minimal-Version" startet und dementsprechend wenig RAM verbraucht ?
Ja, schnell nach dem Programmstart forken. Koennte klappen, indem man DbLog direkt nach global definiert, und im DefineFn den fork() ausfuehrt.
Oder exec ausfuehren z.Bsp. fhem.pl mit einer mini-config. Bei dieser Methode muss die Kommunikation angepasst werden(!).

DS_Starter

Zitat
...  indem man DbLog direkt nach global definiert ...
Die Reihenfolge der Definitionen in der fhem.cfg (um erstmal bei der Datei zu bleiben) kann ich aber als Modulautor nicht festlegen , oder ?
Wäre mir zumindest neu bzw. eine diesbezügliche Steuerung war für mich noch nicht nötig und ich bin deswegen noch nicht darüber gestolpert.   
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

rudolfkoenig

ZitatDie Reihenfolge der Definitionen in der fhem.cfg (um erstmal bei der Datei zu bleiben) kann ich aber als Modulautor nicht festlegen , oder ?
Z.Zt. nicht.
Gespeichert werden die Definitionen sortiert nach $hash->{NR}, beim "sich nach vorne draengeln" muss man aber vorsichtig sein.
Mein Vorschlag war eher fuer den Endanwender gedacht.

DS_Starter

Danke für die Erläuterungen Rudi.
In der Praxis wird der User irgendwann mal auf die Idee kommen DbLog einsetzen zu wollen und eine Definition anlegen.
Die wird dann u.U. weit hinten liegen.
Den SubProcess gleich in der DefFn zu initialisieren werde ich vorsehen, aber die Definition des Devices gleich nach global aufzurufen lässt sich momentan wahrscheinlich eher nur durch Zufall realiseren.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

rudolfkoenig

Den Zufall kann man beeinflussen, wenn man $defs{...}{NR} zum eigenen Gunsten umnummeriert :)