[wiregate] Neue Felder mit PL32 in Plugins - MBs - MBi - Ticks

[makki]

Vorab: Die sind vor allem für "Power-User" gedacht, Otto-Normal wird sich damit nicht beschäftigen müssen..

Ein Erklärungsversuch:

- MBs = MB die beim ersten Aufruf (s=start) hops gehen.
Das ist mit Vorsicht zu geniessen, denn wenn davor ein Plugin kommt, das LWP, XML etc "used" wird das nur dem ersten angerechnet, nicht dem 2+

- MBi = MB die bei subsequenten Aufrufen für immer hops gehen; i=increment, (Megabyte, also 8x1024x1024 Bit die es verbrät, weil Perl nunmal die Mutter der Speicherlecks ist) - kein Problem weil da passt mama monit auf und zieht den Stecker - aber mit aktuellen "Mega-Plugins" hat das etwas stark zugenommen.. Und das soll dazu dienen diese einfacher zu identifizieren..

- Ticks: = Wallclock-ticks, die ein Plugin verbrät, sollte man eher relativ zu anderen sehen. also das ist nicht die absolute ausführungszeit sondern wielange es dabei die CPU ärgert; das ist mehr ein Parameter, der mir/Profis helfen soll, Problemursachen zu finden..

Makki

[Fry]

@Makki:

kennst du den schon:

How can I find memory leaks in long-running Perl program? - Stack Overflow

Vielleicht wäre ein exec/exit-Mechanismus für Plugins besser als ein eval/return? Natürlich würde die Schnittstelle für plugin_info / knx_write usw. nicht ganz trivial...

Fry

[Fry]

...ansonsten bliebe als Krücke immer noch der Weg eines Zwangs-Neustart des wiregated.pl-Prozesses jede Nacht um 3.
VG,
Fry

PS. Für meine - und sicher die meisten anderen - Plugins ist übrigens ein persistentes %plugin_info nicht zwingend erforderlich. Da könnte Komplexität reduziert werden.

[makki]

Das kenne ich schon, ist aber einigermassen Freaky, ich kann (möchte) nicht für Plugins vom Anwender verlangen mit irgendwelchem Klassen-erstell-zerstör-Zeugs rumzumachen, ohne eval geht auch nicht, weil dann bei jedem Typo der daemon kachelt.
Und eine Änderung der Plugin-ABI ist mal schlicht nicht..
Es gibt dazu schon eine Idee: perlembed - perldoc.perl.org

Aber das betrifft aktuell nur eine handvoll "Power-Plugins", insofern ist es erstmal sinnvoller sich dieser anzunehmen und da halt die Zügel in die Hand zu nehmen..

...ansonsten bliebe als Krücke immer noch der Weg eines Zwangs-Neustart des wiregated.pl-Prozesses

Das passiert schon seit immer, das aktuelle Limit ist 96MB (nachdem der Speicherverbrauch der Basis von 48 auf <16MB reduziert wurde!), dann wird der Stecker gezogen und alles ist in 3sek wieder gut..
Wenns sich das gelegt hat, wirds vermutlich wieder auf 32-64MB angezogen.. Aber wir haben ja mehr als genug für die memleaks von Perl

PS. Für meine - und sicher die meisten anderen - Plugins ist übrigens ein persistentes %plugin_info nicht zwingend erforderlich. Da könnte Komplexität reduziert werden.

Ganz im Gegenteil, das persistente plugin_info kostet nichts - und macht kein Speicherleck
Statt dicker lokaler Datenstrukturen wäre es zielführender diese in plugin_info zu packen, dafür ist es da..
(Wobei ein globales %plugin_temp_var o.ä. das Problem auch entschärfen könnte aber wir stehen "kurz" davor, die Plugins richtig Multithreaded (also im Sinne von Threading, nicht im Sinne von dem was Perl da grob mit forking verwechselt..) zu bekommen, da wird man sich jetzt nicht ohne Not neue Altlasten schaffen..
Das muss man dann nämlich mit einer semaphore sperren, updaten, ... - da ist ein persistentes plugin_info (das eh bald sqlite oder dbd ohne das kaputte DB_File wird) in der ramdisk billiger!

Makki

[Fry]

Vorweg: die Annahme, MBi wäre Speicher, der "für immer verloren" ist, ist eine Annahme, oder? Kann es sein, dass Perl diesen Speicher doch wiederverwendet? (dann wäre es kein Leck)

Oder sind das kleinste Speicherstückchen, die per "free" freigegeben wurden und nie wieder verwendet werden, weil perl per "malloc" immer größere Speicherabschnitte anfordert? (dann wäre es strenggenommen auch kein Leck)

Aber das betrifft aktuell nur eine handvoll "Power-Plugins", insofern ist es erstmal sinnvoller sich dieser anzunehmen und da halt die Zügel in die Hand zu nehmen..

Weißt du definitiv, welche Arten von Programm- oder Datenstrukturen ein Plugin zum "Power-Plugin" (=Problem-Plugin) machen? Dann könnte man von diesen Strukturen in einem "Style Guide" entsprechend abraten. Ich lese so zwischen den Zeilen bei dir, dass du die Ursache in komplexen Datenstrukturen siehst, bspw. Hashes von Arrays, die wieder Hashes enthalten usw. Korrekt? Mir fällt das schwer zu glauben, auch wenn es vielleicht intuitiv naheliegt, denn Russound_RIO-Plugin "leaket" vergleichbar stark wie der Logikprozessor (mit aktuell 200 konfigurierten Logiken) - und die beiden Plugins sind doch intern sehr verschieden programmiert, so verzichtet Russound_RIO komplett auf eigene Datenstrukturen (verwendet dafür berechnete Gruppenadressen, was nicht unbedingt leserlich ist), während der Logikprozessor extensiven Gebrauch davon macht, enthält sogar Referenzen auf Programmcode (namenloses sub{}). EDIT: bitte das nicht als Kritik am Russound_RIO-Plugin sehen, ich finde es super und verwende es sehr gerne! es geht hier nur um die technische Diskussion.

Ich möchte jedenfalls nicht "ohne Not" auf elegante Datenstrukturen verzichten, wie auch auf die Indizierung des %eibgaconf nach Kuerzeln (danke dass du das übernommen hast, der nächste Schritt wäre dann, dass knx_write und knx_read auch direkt die Kuerzel statt der GA akzeptieren).

Das passiert schon seit immer, das aktuelle Limit ist 96MB (nachdem der Speicherverbrauch der Basis von 48 auf <16MB reduziert wurde!), dann wird der Stecker gezogen und alles ist in 3sek wieder gut..

Blick in die Logs - ein Wiregated-Restart geschieht bei mir aktuell auf die Minute genau (!) alle 8 Stunden. Als ob ein Timer dahinter stünde.

Statt dicker lokaler Datenstrukturen wäre es zielführender diese in plugin_info zu packen, dafür ist es da..

Gerne, sofort - allerdings müsste %plugin_info dann auch Datenstrukturen akzeptieren - aktuell nur Skalare. Das hat mich dazu gebracht, im Logikprozessor oder auch im Heizungsregler, wo ich lokal strukturierte Daten brauche (um den Code lesbarer zu machen und zu vereinfachen), jeweils eigene Hashes zu schaffen, die bei der Plugin-Initialisierung aus %plugin_info erzeugt werden und am Ende wieder dahin zurück zurückgeschrieben werden. Die Geschichte ist, soweit ich das überblicke, bug-free - und dass das Memleaks auslöst, sehe ich noch nicht bewiesen...

Zum Schluss: deine Abneigung gegen OO-Programmierung in Plugins teile ich! ich finde OO in _kleinen_ Projekten totalen Overkill (erstens braucht das viele Zeilen "Verwaltungs-Code", die das Plugin unleserlich machen, zweitens wofür braucht man starke Kapselung a la OO, wenn man max. 2-3 Datenstrukturen in einem <1000-Zeilen-Programm verwendet). Allerdings wäre es evtl. sinnvoll, per OO oder ähnlichem Mechanismus die Plugins gegeneinander zu kapseln....

VG, Fry

[Fry]

Ganz im Gegenteil, das persistente plugin_info kostet nichts

Na zumindest kostet es Übersicht, solange keine Garbage Collection existiert (ich habe mein Plugin Garbage_Collection.pl gerade ins SVN eingecheckt - USE AT YOUR OWN RISK!)

- und macht kein Speicherleck

...aber sicher doch... :-)

VG Fry

[makki]

ist eine Annahme

Klar das ist eine Annahme, es schaut einfach auf die ures vor und nach Ausführung des Plugins, wenns immer mehr wird ist das nicht so gut und daher nenne ich es einfach mal ein Leck

Weißt du definitiv, welche Arten von Programm- oder Datenstrukturen ein Plugin zum "Power-Plugin" (=Problem-Plugin) machen?

Nee, natürlich nicht, sonst würde ichs ja sagen.. Das ist teilw. ziemlich strange; aber dazu solls ja dienen, das etwas schneller und besser eingrenzen zu können.

allerdings müsste %plugin_info dann auch Datenstrukturen akzeptieren

Doch, kann man, obs so sinnvoll ist steht auf nem anderen Stern..
$plugin_info{$plugname."_complex"} = { 'test' => 'value' };
(so oder so ähnlich, mit welcher kranken \$%{irgendwas-syntax man darauf zugreift müsste ich erst ausprobieren)

Na zumindest kostet es Übersicht, solange keine Garbage Collection existiert (ich habe mein Plugin Garbage_Collection.pl gerade ins SVN eingecheckt

Gibts zwar schon aber..

Makki

[Fry]

Doch, kann man, obs so sinnvoll ist steht auf nem anderen Stern..
$plugin_info{$plugname."_complex"} = { 'test' => 'value' };
(so oder so ähnlich, mit welcher kranken \$%{irgendwas-syntax man darauf zugreift müsste ich erst ausprobieren)

Wirklich, das geht? Muss ich noch ausprobieren - irgendwie hatte ich (vielleicht irrtümlich) angenommen, dass das nicht ginge. (ich meine, ich hätte das sogar irgendwo von dir gelesen... aber ich irre mich vielleicht)

Zum Punkt "ob's sinnvoll ist": also da klingst du fast wie mein Doktorvater, der meinte auch immer, dass Fortran eigentlich für alles ausreichen würde und wofür ich nur C++ brauchen würde...

Zum Punkt "kranke \$%-Syntax": ja, die Syntax von Perl ist gewöhnungsbedürftig, aber sie hat (i) Historie (ii) Logik und (iii) Konsistenz. Und hinter moderner C++-Syntax muss sie sich bzgl. Lesbarkeit nicht verstecken, ich sag nur lambda und rekursive Templates...

Grüße,
Fry

[makki]

Wirklich, das geht?

Ja irgendwie geht das, wir hatten das vor Urzeiten auch schonmal, aber ich finds selber grad nichtmehr; irgendwas mit de/serialisieren evtl., aber es ging.

(ich meine, ich hätte das sogar irgendwo von dir gelesen... aber ich irre mich vielleicht)

Das kann gut sein, wenn wilde Konstruktionen aufkommen deren Syntax ich nicht aus dem Kopf erklären kann - ist die Standard-AW "geht nicht" durchaus denkbar
Für einfache Plugins machts auch keinen Sinn, es steht nur noch (menschlich) unlesbares in Plugin_info und es soll doch auch einfach und verständlich sein, auch für nicht-Programmier-Gurus..

Makki

[nipponichi]

Ich habe ein Script, da kann man beim Klettern der MBi fast zugucken. Gibt es Erfahrungswerte, was dies typischerweise verursacht oder begünstigt?

[makki]

Ich habs noch nicht näher untersucht, erstmal eingebaut..
Dachte mir: mit ein paar Beispielen werden wir wohl dahinterkommen

Makki

[nipponichi]

Ich habe ein Skript, das schafft etwa 25MBi/Tag, und enthält 28 mal folgende Deklaration, auf der dann mit einer Schleife und ein paar if-Abfragen umgerödelt wird. Macht etwa 15kB Schwund pro Aufruf.

push @Schaltzeiten, { name => "xy", DPT => 3, ga => '1/1/40', astro => 'u', ofs => 0,
                      Std_min => 18,  Min_min => 00,  Std_max => 22,  Min_max => 30, Wert => 0,
                      mo => 1, di => 1, mi => 1, do => 1, fr => 1, sa => 1, so => 1};

Nimmt man die Schleife raus (also jede Funktion, nur noch die Variablendeklaration bleibt drin), verringert sich der Schwund auf ein Viertel.
Schon erstaunlich, in Tcl kann man mit Megabyte große Listen und Arrays rumhantieren, das läuft wochenlang ohne besonderen Schwund.

[makki]

Was meist (nicht immer ) was bringt ist
@Schaltzeiten = (); # machs leer
# und
undef @Schaltzeiten; # delete bei einem hash

Die Zeilen müssen natürlich auch aufgerufen werden, könnte was bringen..

Makki

[nipponichi]

@Schaltzeiten = (); # machs leer
# und
undef @Schaltzeiten; # delete bei einem hash

Bringt was, nun 40MBi pro Tag statt 25MBi .

[makki]

Ich sagte ja auch könnte

Ehrlich, das ist würfeln, da gehts um internals wo ich auch aussteige, daher wurde es jetzt auch erstmal so implementiert das man es sehen kann weil wie in jedem Einzelfall die Lösung aussieht ist ein anderes Kapitel..

Makki