Freezes: wie stelle ich fest, dass ein Modul blocking bzw. non-blocking ist?

[MadMax-FHEM]

Hallo,

nachdem ich etwas Zeit habe, habe ich mich mal der Performance meines fhem angenommen

Ausgehend von hier: https://forum.fhem.de/index.php/topic,117075.msg1114300.html#msg1114300
habe ich schon mal versucht alles (was mir ohne zu großen Aufwand: Aufwand/Nutzen muss schon passen   ) mit NOTIFYDEV zu "versehen".

Die nachfolgend genannten Module sind nur beispielhaft (weil ich sie nutze und u.U. freezes gemeldet bekam oder mir vorstellen könnte, dass sie Freezes verursachen könnten [z.B. wegen Abfrage vieler "Dinge"]) und evtl. falsch "verstandenen" bzw. falsch "interpretierten" Dinge mögen mir die jeweiligen Modul-Autoren BITTE NACHSEHEN!!
Ich bin weit weg Perl richtig zu verstehen (obwohl ich schon einige Dinge in C/C++/JavaScript/C# usw. programmiert habe / ich aber auch da schon finde/gefunden habe: unübersichtlicher Code [und die gibt es in den genannten Sprachen auch: C-Code-Einzeiler, die "alles mögliche auf einmal machen"] ist nicht unbedingt "performanter" und allemal schlechter "wartbar"   ).
Auch wenn Modulautoren hier als "blocking-Implementer" "geoutet" werden: bitte nachsehen! Ich verstehe warum und hätte/würde es erst mal auch so gemacht haben

Mir geht es hier eher darum: WIE SEHE ICH EINEM MODUL AN, DASS ES (potentiell) BLOCKIERT (blockieren kann/könnte)...

Dann bin ich gemeldeten FREEZES (freezemon) nachgegangen und habe beim SMARTMON-Modul (das ist [für mich] noch "übersichtlich") festgestellt, dass dort alles blocking abgearbeitet wird.
Da meine Datenplatte normalerweise "schläft" braucht die Prüfung auch schon mal so 6s
Gut nur so 1x am Tag aber trotzdem.
Daher habe ich einen "Patch" eingereicht, indem ich auf BlockingCall umgebaut habe
https://forum.fhem.de/index.php/topic,30491.msg1117481.html#msg1117481


Dann gibt es einen Thread wo Martin (martinp876) PRESENCE auf non-Blocking umbaut: https://forum.fhem.de/index.php/topic,117007.msg1113644.html#msg1113644
Hmm, ich hab in den Code geschaut und eigentlich BlockingCall gefunden, dachte also: ok, ist doch schon non-blocking?
Gut für lan-BT wird dann wohl blocking irgendwas mit DevIO genutzt!!?
(was ich ja schon mal nicht verstehe / gut könnte nat. weiter im Code kramen und mich [auch noch] in die Modulentwicklung einarbeiten / naja so viel Zeit ist dann auch nicht   )
Für mich nicht schlimm (denke ich). Habe nur 1 BT-Dongle mit lepresenced.
Und wenige (aktuell 5 aber eigentlich nur 3 die ich wirklich brauche) lan-ping...
...die ja BlockingCall nutzen und daher ja non-blocking sind.
Aber nat. für jeden lann-ping einen fork machen (wie geschrieben: für mich nicht schlimm -> passt [für mich])...


Dann habe ich mir das echodevice-Modul angesehen.
Gut das nutzt HttpUtilsNonBlockingGet, sollte also passen...
...ABER: für login/login_refresh usw. werden dann doch "System-Funktionen" aufgerufen (wenn ich das richtig interpretiert habe), welche ja potentiell blocken können...
Auch wenn das Attribut "browserSaveData" gesetzt ist werden "Systemaufrufe" genutzt, auch wenn ein mkdir (Beispiel) sicher im normalfall "schnell geht"...
Näher habe ich nicht geschaut... -> Zeit...
Zumindest meldet freezemon hier immer wieder Freezes...
Die ich aber wegen: es wird ja HttpUtilsNonBlockingGet verwendet mit: "Fehlalarm" abgetan habe... -> richtig oder falsch?



Dann nutze ich noch das DENON_AVR-Modul.
Gut ebenfalls HttpUtilsNonBlockingGet. Aber irgendwo steht auch: use "old method blocking"...
So wie kriege ich als (nicht wirklich Perl-Programmierer und Regex-Legasteniker   ) raus was denn nun?


Usw. und so fort...

Und ja es wird HttpUtislNonBlockingGet verwendet -> also nix blockiert. ABER: wie ist das implementiert? Kommt man damit (wieder) in die "Bedrängnis" zu viele Blocking-Forks zu erzeugen (ich vermute: nein / aber wissen tue ich es nicht)...


Wäre es nicht "nett", wenn irgendeo im jeweiligen commandref-Abschnitt ein Hinweis stehen würde?
Also damit zumindest der Anwender relativ schnell sieht, dass es potentiell blockieren kann (und man also weiß was man "riskiert", wenn man das Modul nutzt) oder eben, dass es (komplett) non-blocking implementiert ist!!?


Vielen Dank, Joachim

[KölnSolar]

Hallo Joachim,

Wäre es nicht "nett", wenn irgendeo im jeweiligen commandref-Abschnitt ein Hinweis stehen würde?
Also damit zumindest der Anwender relativ schnell sieht, dass es potentiell blockieren kann (und man also weiß was man "riskiert", wenn man das Modul nutzt) oder eben, dass es (komplett) non-blocking implementiert ist!!?

Dass es non-blocking ist, gehört meines Erachtens nicht in die commandref, da das für mich selbstverständlich ist. Bewusst blockierendes Verhalten sollte vermerkt sein(werden)

Zu Deinen potentiell Verdächtigen: Dem echodevice haben wir ja grundsätzlich mal vor Monaten gemeinsam das blockierende Verhalten abgewöhnt. Ob vielleicht die npm-Methode blockiert, kann ich nicht beurteilen, da ich ja die Cookie-Methode bevorzuge.
Zu den anderen genannten Modulen kann ich nichts sagen.

Kommt man damit (wieder) in die "Bedrängnis" zu viele Blocking-Forks zu erzeugen (ich vermute: nein / aber wissen tue ich es nicht)...

Könnte passieren, wenn es zu viele werden. Bei mir konnte ich aber bisher keinerlei Probleme beobachten.

Grüße Markus

[MadMax-FHEM]

Hallo Markus,

danke für die Antwort!

Dass es non-blocking ist, gehört meines Erachtens nicht in die commandref, da das für mich selbstverständlich ist. Bewusst blockierendes Verhalten sollte vermerkt sein(werden)

Ja, auch das würde schon reichen

Bzw. wäre es besser als aktuell...
Aber:

es steht nichts dabei -> alles gut ODER "vergessen" zu "melden"

Zu Deinen potentiell Verdächtigen: Dem echodevice haben wir ja grundsätzlich mal vor Monaten gemeinsam das blockierende Verhalten abgewöhnt. Ob vielleicht die npm-Methode blockiert, kann ich nicht beurteilen, da ich ja die Cookie-Methode bevorzuge.

Ja, ich weiß.
Drum habe ich sie ja auch erst mal "excluded" beim freezemon...
...aber ich hab mir gedacht nachdem ich mich tapfer durch andere Module gekämpft habe kann ich ja da auch noch mal schauen.
Und da sind mir eben einige Dinge aufgefallen, die wohl potentiell blocken können...

Ja bei meiner Installation könnte ich durchaus auf Cookie umstellen aber ich habe noch eine andere Installation mit nicht ständigem Zugriff und da muss möglichst alles passen, sonst kriege ich "Beschwerden" und dann kann ich nicht mal was tun

Zu den anderen genannten Modulen kann ich nichts sagen.

Ja klar, ich auch nicht

Könnte passieren, wenn es zu viele werden. Bei mir konnte ich aber bisher keinerlei Probleme beobachten.

Wie geschrieben denke ich auch, dass die Nutzung von HttpUtilsNonBlockingGet nicht problematisch ist bzw. konnte ich auch noch nichts feststellen...

Gruß, Joachim

[KölnSolar]

...und um es sportlich zu betrachten: mein fm_freezeThreshold steht auf 0.3
Damit bekomme ich so dicker Daumen ca. 20 freezes/Tag gemeldet, die seltenst 1s überschreiten. 

Grüße Markus

[rudolfkoenig]

Wäre es nicht "nett", wenn irgendeo im jeweiligen commandref-Abschnitt ein Hinweis stehen würde?

Eines der Probleme damit ist, dass ein Modulautor erstmal froh ist, dass das Modul funktioniert, und ihm nicht bewusst ist, dass es unter Umstaenden, im Fehlerfall, das Modul das komplette FHEM blockieren kann => er wird nicht auf die Idee kommen, es zu dokumentieren.
Ein anderes Problem ist, dass es gar nicht so einfach ist, generell durch Code-Lesen zu sagen, ob da nicht irgendwo Blockierungspotential drin ist. Wenn ich mich recht erinnere, ist das sogar theoretisch unmoeglich.
Weiterhin koennen "eigentlich unschuldige" Module FHEM ausbremsen, wenn die Menge der bearbeiteten Daten gross ist, und die Algorithmen nicht entsprechend dafuer optimiert sind. Sowas gilt in meinen Augen auch als Blockieren.

Natuerlich kann man in der Doku auf solche Probleme hinweisen, wenn sie bekannt und nicht geloest sind.

[MadMax-FHEM]

...und um es sportlich zu betrachten: mein fm_freezeThreshold steht auf 0.3
Damit bekomme ich so dicker Daumen ca. 20 freezes/Tag gemeldet, die seltenst 1s überschreiten. 

Grüße Markus

Ganz so sportlich bin ich (aktuell) nicht, steht bei 0.75

Hatte aber auch schon mal eine zeitlang 0.5

Gruß, Joachim

[MadMax-FHEM]

Eines der Probleme damit ist, dass ein Modulautor erstmal froh ist, dass das Modul funktioniert, und ihm nicht bewusst ist, dass es unter Umstaenden, im Fehlerfall, das Modul das komplette FHEM blockieren kann => er wird nicht auf die Idee kommen, es zu dokumentieren.
Ein anderes Problem ist, dass es gar nicht so einfach ist, generell durch Code-Lesen zu sagen, ob da nicht irgendwo Blockierungspotential drin ist. Wenn ich mich recht erinnere, ist das sogar theoretisch unmoeglich.
Weiterhin koennen "eigentlich unschuldige" Module FHEM ausbremsen, wenn die Menge der bearbeiteten Daten gross ist, und die Algorithmen nicht entsprechend dafuer optimiert sind. Sowas gilt in meinen Augen auch als Blockieren.

Natuerlich kann man in der Doku auf solche Probleme hinweisen, wenn sie bekannt und nicht geloest sind.

Hallo Rudolf,

danke!

Ja, hatte ich befürchtet...

Aber vielleicht wird hierdurch ja wenigstens (noch mal) sensibilisiert...

Ich werde einfach noch ein wenig durch meine verwendeten Module gehen und schauen wo ich sie einordne

Ich fahre ja eh "2-stufig": also erst mal ab auf's Testsystem! Und wenn es bzgl. Installations-/Betriebsvoraussetzungen "ok" ist und erst wenn es sich dort "gut verhält" (auch bzgl. Speicher / ist ja das andere "große" Thema) und ich denke es macht Sinn es zu nutzen, dann kommt es auch auf das "Hauptsystem"...

So schließe ich schon mal die schlimmsten Dinge (hoffentlich) aus...

Gruß, Joachim