Neue Version von HTTPMOD mit neuen Features zum Testen

amenomade · 14 Oktober 2019, 19:20:59

Zitat von: scp am 14 Oktober 2019, 10:50:57
Hi, danke für deine Antwort.
Welche Informationen müsste ich noch Posten ? Habe im Anhang nochmal das angelegte HTTMOD Modul und einen Ausschnitt aus meinem Sensor .

wenn ich für meinen Replacement-Value eine Zahl eingebe wird %%Value%% durch diese Zahl erfolgreich ersetzt. Wenn ich anstatt einer Zahl bei dem Replacement Value dann aber eine Variable eingebe geht das nicht. Z.B. : {Value("MeineVariablev1")}
Dann erscheint in meinem zu sendenden "data" einfach der Wert: 0ue

Falls noch mehr Informationen notwendig sind könnt Ihr mir bitte sagen welche. Evtl. irgendein Log etc.

Vielen Dank

Normalerweise postet man ein "list" vom betroffenen Device zwischen Code Tags (das # Zeichen im Edit Menü)
Somit kann man gut lesen, und kann man auch copy/paste machen, um zu erklären und korrigieren.

Im 2. Bild hat es doch funktioniert: er hat out112=%%value%% durch out11=$Meinevariablev1 ersetzt.
Für so ein Replacement brauchst Du eher replacementMode reading

Was soll replacement02Value bedeuten?

Poste mal ein "list" von deinem HTTPMOD und dann kann ich direkt deine Parameter verbessern, ohne das ganze wiede eintippen zu müssen.

StefanStrobel · 14 Oktober 2019, 20:34:31

Hallo Hardlife und Marco,

mit der vollen Konfiguration von Hardlife (inkl. Readingsgroup) konnte ich den Speicheranstieg jetzt nachvollziehen.
Seit Sonntag früh ist der belegte Speicherplatz von 67 auf 71 MB gestiegen.
Jetzt versuche ich es noch weiter einzugrenzen und die Readingsgroup wegzulassen.
Was die Bibliotheken angeht, so nutzt HTTPMOD zunächst nur recht wenig:

Code Auswählen


use Time::HiRes qw(gettimeofday);    
use Encode qw(decode encode);
use HttpUtils;
use SetExtensions qw/ :all /;

weitere werden nur bei Bedarf dazugeladen (z.B. JSON und XML).
Bei reinem RegexParsen sollte das nicht der Fall sein.

Gruss
Stefan

mumpitzstuff · 16 Oktober 2019, 22:51:04

Ich kann den speicheranstieg bei mir nachvollziehen. Falls es eine Version mit erweiterten debugausgaben gibt, kann ich die gern testen.

StefanStrobel · 18 Oktober 2019, 22:52:19

Hallo,

Nachdem Rudi gerade ein Speicherloch in HttpUtils_gethostbyname gefixt hat, sollten wir erst mal updaten und dann erneut testen, ob das Problem sich dadurch erledigt hat.
Siehe https://forum.fhem.de/index.php/topic,84372.675.html

Gruß
Stefan

mumpitzstuff · 18 Oktober 2019, 22:59:03

Wenn ich das TV Device einbinde, habe ich mit und ohne dnsServer einen Anstieg (nach dem Patch ebenfalls). Schalte ich das Httpmod Device auf disable bleibt die Speicherauslastung gleich. Reduziere ich die Anzahl der Regex Attribute, wird der Anstieg weniger steil. Wenn ich das Intervall verkleinere wird der Anstieg größer.
Ich werde jetzt noch mal alle Regex löschen und gucken, ob allein durch die http Abfragen der Speicherverbrauch steigt.

StefanStrobel · 20 Oktober 2019, 00:22:21

Hallo,

ich kann den Speicheranstieg mit der vollen TV_Programme-Konfiguration bestätigen und versuche ebenfalls ihn weiter einzugrenzen.

Zum Testen habe ich das angehängte HTTPMOD etwas erweitert:

Das Attribut dumpBuffers speichert für jede gelesene Response den Buffer in eine eigene Datei mit fortlaufender Nummer (buffer1.txt, buffer2.txt etc.). So kann man diese später wieder schneller abrufen ohne jedes Mal den eigentlichen Server zu belästigen und man ist unabhängig von Netzwerk-Requests etc. Dem Attribut gibt man einen existierenden relativen Pfad für die Dateiablage. Ich habe z.B. /opt/fhem/dumps/ angelegt und das Attribut auf dumps gesetzt.

Das Attribut memReading erzeugt ein Reading mit Namen Fhem_Mem und belegt dieses bei jedem Read mit dem VmSize-Wert aus dem Proc-Filesystem für den Fhem-Prozess. Dann hat man den Plot gleich in Fhem:

Code Auswählen


attr TV_Programme memReading 1
attr TV_ProgrammePT memReading 1
define FileLogMemDebug FileLog ./log/MemDebug.log TV_Programme:Fhem.*
define FileLogMemDebug2 FileLog ./log/MemDebug2.log TV_ProgrammePT:Fhem.*
define SVG_FileLogMemDebug_1 SVG FileLogMemDebug:SVG_FileLogMemDebug_1:CURRENT

Um dann die Dateien wieder zu lesen verwende ich ein Replacement:

Code Auswählen


define TV_Programme HTTPMOD file://dumps/buffer%%n%%.txt 5
attr TV_Programme replacement01Mode expression
attr TV_Programme replacement01Regex %%n%%
attr TV_Programme replacement01Value (defined($hash->{BufCounter}) ? ($hash->{BufCounter} > 90 ? ($hash->{BufCounter} = 0) : $hash->{BufCounter}++)  : ($hash->{BufCounter} = 0))

Den Vergleich >90 muss man anpassen. Bei mir sind es 90 Dateien, die ich der Reihe nach wieder einlese. Dann beginnt es von vorn.
Gerade prüfe ich nochmal alles ohne readingsGroups durch. Die scheinen einen Einfluss zu haben. Mal sehen wie es sich entwickelt.

Gruss
Stefan

mumpitzstuff · 20 Oktober 2019, 23:30:33

Ich habe mal alle Regex Attribute in dem Httpmod Device gelöscht und der Speicherverbrauch ist jetzt gleichbleibend. Ich vermute deshalb das Problem in dem Teil des Moduls, in dem die Regex Ausdrücke auf die Webseite losgelassen werden. Ich werde jetzt mal die Testversion installieren...

mumpitzstuff · 21 Oktober 2019, 10:28:53

Ich habe es seit gestern laufen (nur das TV_Programme Device) und man sieht deutlich den Anstieg. Davor gab es keinen Anstieg, dort waren die regex Attribute gelöscht.

mumpitzstuff · 21 Oktober 2019, 21:42:45

Habe jetzt 86 Dateien und kann diese wie beschrieben alle 5s einlesen. Pro Vorgang werden rund 4mb mehr RAM belegt. Nach ein paar Minuten ist der RAM komplett weg.

Ich würde jetzt gern ein paar Dinge im Modul raus nehmen, um das Problem einzugrenzen. Kannst du mir vielleicht ein paar Funktionen nennen bei denen ich ansetzen kann? Ich würde mich nur ungern in fremden Code einlesen müssen.

StefanStrobel · 21 Oktober 2019, 22:11:37

Hallo,

Da muss ich mich auch erst tiefer reindenken.
Wichtig wäre auf jeden Fall zunächst alle Geräte drum herum aus der Konfiguration zu entfernen.
ReadingGroups, doifs, notify, statistics, average und was sonst noch die Events weiterverarbeitet kann die Messungen verfälschen.
Eventuell komme ich morgen Abend dazu mir das genauer anzusehen.

Gruß
Stefan

mumpitzstuff · 21 Oktober 2019, 23:06:26

Da läuft sonst nix drauf was die besagten Dinge angeht. Es werden nur ein paar Sensoren eingelesen, die kann ich aber nicht abschalten, die sind wichtig für meine Steuerung. Ansonsten komme ich hoffentlich morgen dazu ein wenig rum zu spielen und Dinge Stück für Stück rauszunehmen. Ich fange beim untersten Lvl an (setzen der Readings) und arbeite mich dann hoch.

StefanStrobel · 22 Oktober 2019, 08:30:27

4MB je Vorgang sind auf jeden Fall immens.
Das kann ich auf meinem System nicht nachvollziehen.
Ich muss wohl noch einen separaten Pi nur für diesen Test aufsetzen.
Leider bin ich diese Woche zu viel unterwegs um das machen zu können.
Daher bin ich gespannt was bei Dir herauskommt.

Gruß
Stefan

mumpitzstuff · 22 Oktober 2019, 23:28:42

Ich denke ich habe was gefunden. Sobald ich diese Zeile (1915 in deiner angehängten Datei) auskommentiere gibt es keinen Anstieg mehr:

Code Auswählen

@matchlist = ($buffer =~ /$regex/);

Um sicherzugehen das es nicht mit der weitergehenden Verarbeitung zu tun hat, habe ich weiter unten die folgenden Zeilen:

Code Auswählen

    my $match = @matchlist;
    if ($match) {

so umgeschrieben:

Code Auswählen

    my $match = 0; #@matchlist;
    if (0) {

Dadurch wird der Code unten nicht mehr ausgeführt. Ist jetzt die Zeile 1915 drin, steigt der Speicherverbrauch massiv an. Ist sie draussen ist Ruhe.

Darüber hinaus habe ich festgestellt, das die zuvor erzeugten Dateien buffer<zahl>.txt mit einer Fehlermeldung überschrieben worden sind: Buffer0.txt nicht gefunden. Das wiederum bedeutet, das es keine Matches gegeben hat. buffer0.txt wird auch nie erzeugt, sondern es wird immer mit buffer1.txt angefangen.

Muss ich das Attribut dumpBuffers eigentlich löschen bevor ich die Request an die Webseite auf die erzeugten Dateien umstelle oder wie verhindere ich, das die einmal erzeugten Dateien wieder überschrieben werden?

mumpitzstuff · 23 Oktober 2019, 21:21:39

Problem gefunden und gelöst. Kurze Beschreibung siehe hier:

https://forum.fhem.de/index.php/topic,84372.msg986397.html#msg986397

Bei Bedarf kann ich weiter Infos liefern.

StefanStrobel · 24 Oktober 2019, 18:32:37

Hallo mumpitzstuff,

zunächst mal vielen Dank für Dein Engagement.
Jetzt wissen wir schon mal dass es ein Perl-Bug ist, der leider nicht auf allen Systemen und von mehreren Faktoren abhängig zuschlägt. Ich würde die weiteren Details der sinnvollsten Problemlösung im Memory-Leak-Thread weiter diskutieren und eine neue Version einchecken, sobald ich eine Lösung habe, die ich komplett durchschaut habe und bei der ich sicher bin, dass sie keine anderen Seiteneffekte hat.

Gruss / Thanx
Stefan