Vorkompilieren von WG-Plugins, möglicher Fix für bisherige Memleaks

[XueSheng]

Viele haben ja bereits eine positive Rückmeldung zu den vorkompilierten Plugins gegeben. Nach vier Wochen Testen (4 von 30 Plugins umgestellt) ziehe ich auch ein positives Fazit.

Der Speicherverbrauch häufig aufgerufener Plugins ist sehr deutlich zurückgegangen (nach mehreren Wochen nur wenige 100kb Speicherbedarf, anstatt mehrere MB).

Die Ausführgeschwindigkeit der Plugins ist durch reines vorkompilieren nicht wesentlich schneller geworden (kann aber auch mit dem Pluginaufbau zusammenhängen). Jedoch hat die Umstellung auf %plugin_cache deutliche Geschwindigkeitsvorteile gebracht (bislang nutze ich %plugin_info in einigen Plugins sehr intensiv, auch für Daten, die nicht persistent sein müssen).

Gibt es mittlerweile eine Entscheidung, ob "Vorkompilieren" und "%plugin_cache" in ein offizielles Update einfließen werden?
Ich möchte ungern alle Plugins umstellen und das Risiko eingehen, zukünftig bei jedem Update händisch nachbessern zu müssen (immerhin ist das Wiregate ein zentraler Bestandteil der Haussteuerung).

[XueSheng]

Kein Licht ohne Schatten: wenn man Plugins "kompilierbar" schreiben will, muss man eine Regel beachten, die damit zusammenhängt, dass das Plugin am Ende eine Subroutine wird und Perl benannte Subroutinen innerhalb von anderen Subroutinen eigentlich nicht kennt.

Die einzige konkrete Auswirkung dieses Umstandes, die mir einfällt: Subroutinen innerhalb von kompilierten Plugins können NICHT mehr auf Variablen im Haupttext des Plugins zugreifen. (Sie können aber wie bisher auf ihre eigenen lokalen ("my") Variablen zugreifen und auch auf die Variablen des Daemons, zB %msg und $fh, oder auch %plugin_subscribe).

Ich verwende in manchen Plugins eine Variable "my $debug;", um bequem verschiedene Loglevel einstellen zu können. Diese Variable übergebe ich natürlich nicht explizit an Funktionen/Subs, sondern verwende diese global.

Wie von Fry erwähnt, funktioniert dies natürlich nicht mehr mit Anwendung des Patches. Als Alternative zu den genannten Beispielen habe ich diese Variable nun mit "our $debug;" anstatt "my $debug;" deklariert, so dass diese global zur Verfügung steht. Dies scheint auch zu funktionieren.

Spricht etwas gegen die Verwendung von "our" in diesem Zusammenhang?

[Fry]

Ich habe keine Erfahrung mit "our" und verwende es nicht. Kannte bisher nicht einmal dieses Perl-Schlüsselwort.
Was du schreibst, klingt aber gut. Es sollte auch funktionieren, warum denn nicht.
VG, Fry

[dombn]

Meine Erfahrungen sind weiterhin sehr positiv.

@StefanW könnt ihr zur Frage: Aufnahme in Standard-Wiregate schon irgendetwas sagen?

[ctr]

Ich wollte auch gerade mal testen, setze aber nur ungern komplette Ersatz-Dateien ein, sondern wollte den wiregated.pl patchen. Das ist leider (vermutlich aufgrund von zwischenzeitlich erfolgten anderen Änderungen) im geposteten patch-format nicht möglich. Könntst Du bitte nochmal einen unified diff drüberlaufen lassen und hier einen aktuellen Patch posten? Vielleicht reicht auch schon ein unified diff gegen den alten wiregated.pl, da im unified Format Änderungen in anderen Teilen nicht so dramatisch sind und der Patch (dann mit Offsets) trotzdem noch angewendet werden kann.

Danke!

EDIT: Habe mich mal selbst daran versucht, da ich keinen alten wiregated.pl mehr hatte, mußte ich aber aus dem diff/patch manuell die Änderungen darin auch rausnehmen, hoffe ich habe alle gefunden, also gerne mal testen.
Wenn das beim Anwenden des Patches noch Offsets gibts, liegt es vermutlich daran, dass ich im wiregated.pl auch noch die Änderungen aus dem anderen Thread drin habe.

[ctr]

Also ich habe den Patch seit 3.10 im Einsatz und gerade eben festgestellt, dass ich seitdem keine RRD-Updates mehr aus für eine Quelle habe.
Diese kommt aus einem WG-Plugin (berechnet Durchschnittstemperatur aller Räume) und ein anderes WG-Plugin (rrd_graph) schreibt es dann weg.

In der WG Plugin Doku steht schon drin, dass man vorsichtig mit Plugins wegen Locking sein sollte, aber bis vor dem Patch hatte das fuktioniert... Ideen?

[Fry]

Hmmm ist natürlich schwierig zu beurteilen, weil du ja deinen eigenen Patch gebastelt hast. Ehrlich gesagt bezweifle ich aber, dass das Vorkompilieren mit den RRDs zusammenhängt.

Werden denn die beiden von dir beschriebenen Plugins überhaupt vorkompiliert? (steht irgendwo COMPILE_PLUGIN im Code?)

VG, Fry

PS. habe >>100 RRDs, die meisten schreibt der Logikprozessor weg. Kein Problem.

[ctr]

Ich denke nicht, dass es am RRD liegt, sondern der Tatsache, dass ein Plugin ein anderes aufruft.

Ich schreibe im rrd_graph auch ca. 20 Werte in RRDs. Seit 3.10 geht genau dieses eine nicht mehr. Unterschied: Alle anderen Werte kommen von Busteilnehmern, der Wert vom RRD was nicht mehr aufzeichnet kommt aus einem anderen Wiregate-Plugin.
Das andere Wiregate-Plugin funktioniert weiterhin:

# groupreadresponse local:/tmp/eib 0/0/64
Send request
Read from 1.1.251
Response from 1.1.251: 0C 23

Nur das entsprechende RRD wird nicht aufgezeichnet:

update_rrd("Temp_0_0_43","",knx_read("0/0/43",60,9));
update_rrd("Temp_0_0_64","",knx_read("[B]0/0/64[/B]",60,9));
update_rrd("Regen","",knx_read("0/0/66",60,9));
update_rrd("Windstaerke","",knx_read("0/0/67",60,9));
update_rrd("Strom_Kueche1","",knx_read("3/5/11",60,7));

Mir ist durchaus bewußt, dass sich dies auch anders lösen lässt (das werde ich jetzt auch tun), ich wollte hiermit nur auf das Problem hinweisen, da dies mit einem "plain" wiregated.pl kein Problem war.

[XueSheng]

Grundsätzlich wird vom wiregated.pl ein Plugin nach dem anderen abgearbeitet. Wenn Du nun in einem Plugin eine Leseabfrage absetzt und die Antwort nur von einem anderen Plugin kommen kann, funktioniert dies nicht. Das hast Du ja im Prinzip auch schon selbst geschrieben.

Als Leseanfrage verwendest Du z.B. 'knx_read("0/0/64",60,9)', d.h. dass die Antwort maximal 60 Sekunden alt sein darf. Nun stellt sich die Frage, wie häufig dein anderes Plugin aufgerufen wird und ob dieses andere Plugin auf den Bus schreibt oder antwortet. Evtl. ist es nur so, dass es zufälligerweise bislang funktioniert hat, weil die Aufrufzyklen der beiden Plugins zusammengepasst haben und die Antwort aus dem Cache kam. Nach Umstellung auf PLUGIN_COMPILE musste wiregated.pl ja neugestartet werden. Evtl. passt nun die Reihenfolge der Plugins nicht mehr. Wobei es bislang Zufall gewesen sein muss, dass es überhaupt funktioniert hat!

Umgehen kannst Du das ja ganz einfach indem Du aus dem Cache liest, also z.B.: 'knx_read("0/0/64",0,9)'. Du musst nur sicherstellen, dass das andere plugin in entsprechenden Zyklen Werte auf den Bus schreibt.

[ctr]

Diese Problematik ist mir wie bereits eingangs erwähnt durchaus bewußt.
Nun es ist aber so, dass diese Konstruktion über ein Jahr wunderbar funktioniert hat und seit 3.10 (seitdem ich die Patches zum Vorkompilieren und den anderen Patch von Fry drin habe) eben nicht mehr. Wie ich das Problem als solches beheben kann weiß ich (ich lasse jetzt einfach das Plugin zur Durchschnittsberechnung den Wert ebenfalls ins Plugin-Info schreiben und lese es dort mit dem rrd_graph aus) mir ging es bei meinem Posting einzig und allein darum klarzustellen, dass durch die Patches (welchen auch immer, wahrscheinlich eher https://knx-user-forum.de/code-schni...ller-sein.html jetzt kann ich aber den Post auch nicht mehr verschieben) ein anderes Verhalten zu beobachten ist als vorher... ich dachte genau darum ging es hier.

[XueSheng]

[...] mir ging es bei meinem Posting einzig und allein darum klarzustellen, dass durch die Patches [...] ein anderes Verhalten zu beobachten ist als vorher... ich dachte genau darum ging es hier.

Ob es einen Zusammenhang mit den Patches gibt, wäre schon interessart zu wissen. Allerdings fehlen zu viele Details, um das beurteilen zu können. Wir kennen nun mal Deine Plugins nicht! Ebenso ist unklar, ob Dein manuell erstellter Patch wirklich fehlerfrei implementiert wurde.
Auf die Anmerkung/Frage von Fry bist Du nicht eingegangen. Auf meine Vermutung bist Du auch nicht weiter eingegangen.

Wenn Du das Problem für Dich gelöst hast, ist ja auch alles in Ordnung. Falls Du doch noch die Ursache für das "Problem" herausfinden willst, müsste man das Szenario Schritt für Schritt durchgehen.

[ctr]

Mein Patch stand hier jetzt seit einem Monat unkommentiert, da er selber nur ein angepasster Diff aus dem wiregated.pl von Fry gegen den Release wiregated.pl und keine Funktionen hinzufügt sollte es eigentlich relativ leicht sein dies zu verifizieren.
Unnötig zu erwähnen, dass ein Diff aus dem resultierenden wiregated.pl gegen den hier von Fry geposteten lediglich in den zwischenzeitlichen Änderungen des original wiregated.pl besteht.

Zu Fry's Anmerkung: (COMPILE_PLUGIN) ist in beiden fraglichen Plugins nicht enthalten (außer die Benutzung in anderen Plugins hat auch noch Auswirkungen die ich bis jetzt nicht überblickt habe), deswegen tippe ich inzwischen eher auf den "Speedfix" (while anstatt if), kann aber wie gesagt meinen ursprünglichen Post nicht in den anderen Thread verschieben, wenn ihr lieber dort weiterdiskutieren möchtet, gern.

Zu Deiner "Vermutung" kann ich schlecht Stellung beziehen, aber es mit "Zufall" abzutun ohne sich mit der Problematik auseinanderzusetzen finde ich etwas zu einfach. Ich weiß gar nicht wielange ich das Wiregate jetzt habe, aber zwei Jahre sind es bestimmt, ich habe selber einige Plugins geschrieben und einige im Repo erweitert oder korrigiert. Mir ist die Funktionsweise des Wiregates durchaus bewusst. Aber um es nochmal zu verdeutlichen: Diese Konstruktion (auch wenn sie nicht optimal ist, habe ich aber auch sofort hinzugeschrieben) ist bei mir seit geraumer Zeit im Einsatz, seitdem sind viele Plugins gekommen und gegangen, das Wiregate mehrfach neugestartet, nur die Berechnung der Durchschnittstemperatur war immer im Graphen. Ich gehe nicht davon aus, dass innerhalb der letzten Monate "zufällig" immer die Visu (jemand anderes greift außer dem rrd_graph nicht auf die GA zu) innerhalb der letzten 60sek darauf zugegriffen bevor rrd_graph gelaufen ist. Insofern bleibt bei objektiver Betrachtung der Tatsachen nur der Schluß, dass durch die genau an diesem Tag gemachten Änderungen (nämlich Anpassung des wiregated.pl um precompile und speedfix Funktionen) das veränderte Verhalten hervorgerufen wird.

Ich finde beide Änderungen (precompile und if/while Speedfix) sehr gut und interessant, sonst würde ich sie nicht testen. Trotzdem (gerade weil darum gebeten wurde sie in den "Original" wiregated.pl aufzunehmen) würde ich um eine kritische Betrachtung von solchen Fehlerreports bitten und mich nicht wie einen Anfänger abzutun, wir sind hier nicht bei IT Crowd (did you turn it off and on again?).

[XueSheng]

Trotzdem (gerade weil darum gebeten wurde sie in den "Original" wiregated.pl aufzunehmen) würde ich um eine kritische Betrachtung von solchen Fehlerreports bitten und mich nicht wie einen Anfänger abzutun, wir sind hier nicht bei IT Crowd (did you turn it off and on again?).

Gerade deswegen wurde um mehr Infos gebeten. Du kennst Deine Plugins, wir nicht. Daher gibt es bislang auch nur Vermutungen. Ich finde es gut, dass Du schon so lange das Wiregate im Einsatz hast und viele Plugins geschrieben hast... allerdings hilft uns das nicht bei der Fehlerfindung. Die Aussage

Nun es ist aber so, dass diese Konstruktion über ein Jahr wunderbar funktioniert hat und seit 3.10 (seitdem ich die Patches zum Vorkompilieren und den anderen Patch von Fry drin habe) eben nicht mehr.

ist eben nicht ausreichend, um das Problem einschätzen zu können.

Wenn Du Dich durch meinen Kommentar angegriffen gefühlt hast, war das sicherlich nicht meine Absicht. Da meine Hilfe hier offensichtlich nicht mehr von nöten ist, bin ich aus der Diskussion erst mal raus. Bis denne...

[frankenChris]

Ich hab den geänderten wiregated nun auch mal ausprobiert, und dank des Tipps mit "our", was einwandfrei zu funktionieren scheint, statt "my" hielt sich der Änderungsaufwand auch sehr in Grenzen - kann das also nur empfehlen.

[XueSheng]

Ich bin über ein Problem mit COMPILE_PLUGIN gestolpert.

Kurzfassung:
Wenn man in einem Plugin mit aktiviertem COMPILE_PLUGIN eine Funktion deklariert, die mit gleichem Namen bereits in einem anderen Plugin existiert, ist diese Funktion nicht mehr eindeutig. Eines der beiden Plugins ruft dann die Funktion des anderen Plugins auf.

Langfassung (Beispiel):
1. Zwei Plugins erstellen, z.B. "Plugin_A.pl" und "Plugin_B.pl" mit gleichem Inhalt (wichtig ist, dass je eine Funktion mit gleichem Namen deklariert wird):

#COMPILE_PLUGIN
$plugin_info{$plugname.'_cycle'} = 30;

plugin_log($plugname, "Main Code");
do_something();
plugin_log($plugname, "The End");

return;

sub do_something {
   plugin_log($plugname, "Hello World");
   return;
}

2. Plugins ausführen und Wiregate-Log beobachten. Folgendes Resultat ist zu sehen (Plugin_A in diesem Beispiel mit cycle=60 und Plugin_B mit cycle=30):

2014-07-04 13:10:06.609,Plugin_A.pl,compiled in 0.0s
2014-07-04 13:10:06.612,Plugin_A.pl,Main Code
2014-07-04 13:10:06.613,Plugin_A.pl,Hello World
2014-07-04 13:10:06.613,Plugin_A.pl,The End
2014-07-04 13:10:30.490,Plugin_B.pl,Main Code
2014-07-04 13:10:30.490,Plugin_B.pl,Hello World
2014-07-04 13:10:30.491,Plugin_B.pl,The End
2014-07-04 13:10:49.715,Plugin_B.pl,compiled in 0.0s
2014-07-04 13:10:49.718,Plugin_B.pl,Main Code
2014-07-04 13:10:49.718,Plugin_B.pl,Hello World
2014-07-04 13:10:49.718,Plugin_B.pl,The End
2014-07-04 13:11:07.162,Plugin_A.pl,Main Code
[B][COLOR=Red]2014-07-04 13:11:07.162,Plugin_B.pl,Hello World[/COLOR][/B]
2014-07-04 13:11:07.162,Plugin_A.pl,The End
2014-07-04 13:11:19.767,Plugin_B.pl,Main Code
2014-07-04 13:11:19.767,Plugin_B.pl,Hello World
2014-07-04 13:11:19.768,Plugin_B.pl,The End

Wie man sehen kann, ruft Plugin_A.pl den Code aus Plugin_B.pl auf. Bei deaktiviertem PLUGIN_COMPILE ist dieses Verhalten nicht zu beobachten.

Ich ärgere mich schon seit ein paar Tagen mit zwei Plugins rum und habe mich gewundert, warum immer eins der beiden Spinnt (je nachdem welches ich zuletzt abgespeichert hatte). Da beide Plugins fast den selben Namen besitzen, war mit der fehlerhafte Funktionsaufruf erst garnicht aufgefallen.

Fry, kannst Du dieses Verhalten so nachvollziehen?