Cannot fork: Cannot allocate memory | BlockingInformParent

[fhemxperte]

Gute Analysefunktion rudolfkoenig, werde ich mir merken, ggf. auch für die anderen interessant.

Ich werde nun allerdings erstmal die Woche durchtesten (und bei einer gleichbleibenden Version bleiben).

• 2-3 Tage ohne dsnServer Eintrag in global
• 2-3 Tage nochmal die Gegenprobe mit dem dnsServer Eintrag

Danach werde ich updaten und prüfen was HttpUtils intern cached.

[fhemxperte]

Update:

Folgende Tests habe ich nun durchgeführt (allerdings hat pro Test ein Tag ausgereicht).

• 2-3 Tage ohne dnsServer Eintrag in global
• 2-3 Tage nochmal die Gegenprobe mit dem dnsServer Eintrag

Im Anhang sieht man das Ergebnis:

1.) In diesem Teil des Diagramms habe ich das Attribut dnsServer aus global gelöscht und laufen lassen -> Eine konstante Gerade
2.) In diesem Teil des Diagramms habe ich das Attribut dnsServer mit dem Value 127.0.0.1 auf meinen lokalen Pi-Hole wieder in global erstellt und laufen lassen -> Eine Gerade die linear ansteigt

Andere Änderungen habe ich zwischen diesen Tests nicht durchgeführt.


Jetzt werde ich Fhem updaten und die neue Analysefunktion des DNS Caches aus den HTTPUtils testen.

[mumpitzstuff]

Das kann ich bei mir leider nicht bestätigen. Ich habe durch 1 httpmod device eine steigende Gerade und hatte dort das dnsServer Attribut gesetzt. Dieses habe ich mit delete gelöscht und danach keine Änderung im Anstieg feststellen können. Vielleicht ist das einfache Löschen aber auch nicht ausreichend gewesen.

[StefanStrobel]

Ein paar Zwischenergebnisse von meiner Seite:

mit der vollen HTTPMOD-Konfiguration für die TV-Programme von Hardlife sehe ich auch einen kontinuierlichen Anstieg im Speicherverbrauch. Auch wenn ich die readingsgroups entferne ist dieser über einen Tag hinweg sichtbar.

Wenn ich den aktuellen HTML-Content von der abgefragten Website als Datei speichere und die HTTPMOD-Konfiguration so ändere, dass die Daten nicht von der Original-Website sondern als file:// gelesen werden, ist kein Anstieg sichtbar. Natürlich ändert sich der Inhalt dann nicht mehr, aber das Parsen von HTTPMOD wird dennoch ständig neu gemacht.

Um ganz sicher zu sein habe ich jetzt HTTPMOD zum Testen so erweitert, dass der Content nach jedem Seitenabruf in einer eigenen Datei gespeichert wird.
Nach einem Tag plane ich dann alle Seiten der letzten 24 Stunden aus den jeweiligen Dateien lesen zu lassen. So müsste sich klären lassen, ob der Leak irgendwo beim Parsen der Seiten passiert oder beim Abruf per HTTP.

Ich berichte wenn ich ein Ergebnis habe.

Gruss
   Stefan

[rudolfkoenig]

@Hardlife: Falls Du eventTypes definiert hast, und die beiden HTPMOD Definitionen nicht auf dem ignoreList sind, dann waere das eine (teilweise?) Erklaerung des Speicheranstiegs.

[mumpitzstuff]

Bei mir ist der Anstieg desto höher, je mehr Regex Ausdrücke im Httpmod Device vorhanden sind. Da gibt es meiner Meinung nach einen Zusammenhang. Die Readinggroup konnte ich als Ursache ebenfalls ausschließen.

Ein paar Zwischenergebnisse von meiner Seite:

mit der vollen HTTPMOD-Konfiguration für die TV-Programme von Hardlife sehe ich auch einen kontinuierlichen Anstieg im Speicherverbrauch. Auch wenn ich die readingsgroups entferne ist dieser über einen Tag hinweg sichtbar.

Wenn ich den aktuellen HTML-Content von der abgefragten Website als Datei speichere und die HTTPMOD-Konfiguration so ändere, dass die Daten nicht von der Original-Website sondern als file:// gelesen werden, ist kein Anstieg sichtbar. Natürlich ändert sich der Inhalt dann nicht mehr, aber das Parsen von HTTPMOD wird dennoch ständig neu gemacht.

Um ganz sicher zu sein habe ich jetzt HTTPMOD zum Testen so erweitert, dass der Content nach jedem Seitenabruf in einer eigenen Datei gespeichert wird.
Nach einem Tag plane ich dann alle Seiten der letzten 24 Stunden aus den jeweiligen Dateien lesen zu lassen. So müsste sich klären lassen, ob der Leak irgendwo beim Parsen der Seiten passiert oder beim Abruf per HTTP.

Ich berichte wenn ich ein Ergebnis habe.

Gruss
   Stefan

[rudolfkoenig]

Ich kann auf einem OSX Rechner einen Bug nachvollziehen, was hier: https://rt.cpan.org/Public/Bug/Display.html?id=123520 beschrieben ist.
Das Problem betrifft alle TLS Verbindungen (nicht nur HTTPS oder HttpUtils). Hardlife waere auch betroffen, da http://www.klack.de nach https umleitet.
Ein Update von IO::Socket::SSL auf 2.066 und Net::SSLeay auf 1.88 hilft nicht, getestet mit perl 5.18 bzw. 5.28.

Auf debian buster (perl 5.28) oder auf ubuntu 14.04 (perl 5.18) hat das gleiche Programm _kein_ Speicherloch.
Seufz.

[mumpitzstuff]

Ich habe buster mit Perl 5.28. Aber es könnten auch hier wieder mehrere Dinge zusammen spielen.

[Hardlife]

@Hardlife: Falls Du eventTypes definiert hast, und die beiden HTPMOD Definitionen nicht auf dem ignoreList sind, dann waere das eine (teilweise?) Erklaerung des Speicheranstiegs.

Hmmm.
Ok, ich hatte zwar noch nie ein ignorelist-Attribut beim eventtypes-Device, aber ich versuche es mal.
Soll ich ALLE HTTPMOD-Devices, welche RegEx beinhalten auf die ignorelist setzten?
Und was würde das bewirken/unterbinden?

Danke,
Hardlife

[rudolfkoenig]

Und was würde das bewirken/unterbinden?

eventTypes sammelt alle Events von jedem Geraet, damit man diese in Wizards (Hilfen im Benutzerinterface, wie z.Bsp. bei notify oder FileLog) verwenden kann.
Zahlen, HTML(?), lange Texte und etliches mehr werden ignoriert, nicht aber Sendungsnamen.
D.h. immer neue Sendungen koennen bei eventTypes zu einem "unendlichen" Archiv fuehren.

Aber ich sehe gerade: Anzahl der gespeicherten Events pro Device ist auf 200 begrenzt.

Bei FHEM Start wird eine Meldung ausgegeben: "eventTypes: loaded X events from Y".Falls X ungewoehnlich gross ist, sollte man handeln.

[StefanStrobel]

Hallo,

Als ich gestern begonnen habe, alle HTTP-Responses, die bei der Konfiguration von Hardlife eingehen, in Dateien zu sichern, habe ich auch das globale Attribut dnsServer gelöscht und danach Fhem neu gestartet.

Jetzt wäre ich also bereit, alles mit Dateien zu testen, aber die Speicherüberwachung hat für die letzten 24h keinen Anstieg mehr aufgezeichnet. Es geht zwar zwischendrin mal hoch, dann aber auch wieder runter. Damit haben sich die weiteren Tests eher erledigt.
Für mich sieht es so aus, als liegt es nur am dnsServer-Attribut.

Ich werde es mal noch einen weiteren Tag beobachten ...

Gruss
    Stefan

[Hardlife]

Bei FHEM Start wird eine Meldung ausgegeben: "eventTypes: loaded X events from Y".Falls X ungewoehnlich gross ist, sollte man handeln.

Ahh, danke für die Erklärung.

Code Auswählen Erweitern

...
Server started with 1039 defined entities
...
eventTypes: loaded 9421 events from ./log/eventTypes.txt
...

... kommt mir in Relation gesehen nun nicht ganz so abnormal vor...

Für mich sieht es so aus, als liegt es nur am dnsServer-Attribut.

-> Diese Attribut habe ich leider gar nicht in Verwendung und trotzdem den Anstieg...


LG,
Hardlife

[fhemxperte]

Hallo,

Als ich gestern begonnen habe, alle HTTP-Responses, die bei der Konfiguration von Hardlife eingehen, in Dateien zu sichern, habe ich auch das globale Attribut dnsServer gelöscht und danach Fhem neu gestartet.

Jetzt wäre ich also bereit, alles mit Dateien zu testen, aber die Speicherüberwachung hat für die letzten 24h keinen Anstieg mehr aufgezeichnet. Es geht zwar zwischendrin mal hoch, dann aber auch wieder runter. Damit haben sich die weiteren Tests eher erledigt.
Für mich sieht es so aus, als liegt es nur am dnsServer-Attribut.

Ich werde es mal noch einen weiteren Tag beobachten ...

Gruss
    Stefan

So ist es bei mir auch mit den Ups and Downs, das sollte aber je nach Last usw normal sein. Die Personen, die das DNSServer Attribut nicht gesetzt haben, haben wahrscheinlich noch ein weiteres mögliches Leck entdeckt.


Im Anhang enthalten ist mein neuer Graph mit der letzten Fhem Version und gesetztes DNSServer Attribut (die Zahl 1 im Graph kennzeichnet den Anstieg seit Update). Zudem habe ich das Auslesen des DNS Caches der HttpUtils getestet, allerdings sind hier keine Anzeichen eines Speicheranstiegs zu erkennen. Der Cache bleibt gleich befüllt.


16.10.2019 11:38:
api.luftdaten.info       TS: 2019-10-16 11:35:50   TTL:  1121   ADDR: 81.169.180.11
api.openweathermap.org   TS: 2019-10-16 11:36:02   TTL:  1907   ADDR: 37.139.20.5
api.telegram.org         TS: 2019-10-16 11:36:06   TTL:   328   ADDR: 32.1.6.124.4.232.240.4.0.0.0.0.0.0.0.9
api.wunderground.com     TS: 2019-10-16 11:35:50   TTL:    20   ADDR: 23.211.10.129
data.sensor.community    TS: 2019-10-16 11:35:50   TTL: 12028   ADDR: 42.1.2.56.66.241.51.0.235.174.86.156.201.88.223.56
htpcpi2-sz.fritz.box     TS: 2019-10-16 11:37:59   TTL:     9   ADDR: 192.168.20.27
htpcpi2-wz.fritz.box     TS: 2019-10-16 11:37:59   TTL:     9   ADDR: 192.168.20.45
htpcpi3-bl.fritz.box     TS: 2019-10-16 11:37:59   TTL:     9   ADDR: 192.168.20.35
www.allergie.hexal.de    TS: 2019-10-16 11:36:36   TTL:  3600   ADDR: 134.119.224.159
www.verkehrsinfo.de      TS: 2019-10-16 11:35:50   TTL:   101   ADDR: 217.160.0.27



17.10.2019 21:10:
api.luftdaten.info       TS: 2019-10-16 11:35:50   TTL:  1121   ADDR: 81.169.180.11
api.openweathermap.org   TS: 2019-10-17 20:39:04   TTL:   918   ADDR: 82.196.7.246
api.telegram.org         TS: 2019-10-17 21:10:04   TTL:   189   ADDR: 32.1.6.124.4.232.240.4.0.0.0.0.0.0.0.9
api.wunderground.com     TS: 2019-10-17 21:05:59   TTL:    20   ADDR: 23.211.10.129
data.sensor.community    TS: 2019-10-16 11:35:50   TTL: 12028   ADDR: 42.1.2.56.66.241.51.0.235.174.86.156.201.88.223.56
htpcpi2-sz.fritz.box     TS: 2019-10-17 21:09:13   TTL:     9   ADDR: 192.168.20.27
htpcpi2-wz.fritz.box     TS: 2019-10-17 21:09:47   TTL:     9   ADDR: 192.168.20.45
htpcpi3-bl.fritz.box     TS: 2019-10-17 21:09:47   TTL:     9   ADDR: 192.168.20.35
www.allergie.hexal.de    TS: 2019-10-17 20:36:38   TTL:  3600   ADDR: 134.119.224.159
www.verkehrsinfo.de      TS: 2019-10-17 20:05:58   TTL:  3600   ADDR: 217.160.0.27


Kann ich noch etwas beisteuern um das Problem einzugrenzen? Installierte Versionen diverser CPAN Bibliotheken? Oder Erstellung einer Fhem Konfiguration die bei jedem funktioniert zur Nachanalyse (kann ich natürlich nicht garantieren, aber probieren)?

[rudolfkoenig]

Für mich sieht es so aus, als liegt es nur am dnsServer-Attribut.

Ich habe ein Speicherloch in HttpUtils_gethostbyname bei gesetztem dnsServer mit debian/buster, perl 5.28 gefunden und gefixt.
Evtl. tritt das Problem auch mit anderen Perl-Versionen auf, das habe ich aber nicht verifiziert.
Es hat ca 10kb pro Lookup verloren, wenn die IP nicht im Cache war. Das bedeutet ca 1MB pro Tag und Adresse, wenn TTL auf 900s gesetzt ist, wie bei www.klack.de
Ich tippe auf einem perl Bug, es ist mir aber zu kompliziert, um es nachzuweisen.

[Wernieman]

Auch wenn es jetzt OT (und ich nicht betroffen):
Ich muß Dir (und allen die dabei geholfen haben) mal ein DANKE für Bugsuche und Fixing aussprechen!