Cannot fork: Cannot allocate memory | BlockingInformParent

[rudolfkoenig]

Einiges: https://svn.fhem.de/trac/log

[Burny4600]

Das war einiges was sich geändert hat.
Jedenfalls sieht es jetzt sehr gut aus. Kein Speicheranstieg ist bemerkbar.
Ich habe die Perl Version nie geändert, sondern nur die FHEM Updates von Zeit zu Zeit durchgeführt.
Damit dürfte das Problem jetzt beseitigt sein.

[Gunther]

Ich hoffe, dass ich hier richtig bin. Ich sehe den Wald vor lauter Bäumen nicht.

Bisher dachte ich, dass das Unifi-Modul mein FHEM einfriert. Zumindest die Ausführungszeiten deuten nicht darauf hin.

Folgende Fehlermeldung taucht immer wieder in meinem Log auf:

Code Auswählen Erweitern

BlockingInformParent (BlockingStart): Can't connect to localhost:7072: IO::Socket::INET: connect: Connection timed out
Was kann das sein und wie gehe ich damit um?

[rudolfkoenig]

Dieses Problem hat vmtl. nichts mit dem hier behandelten (Speicherloch in FHEM) zu tun, sondern wird durch eine Blockierung des "eigentlichen" FHEM Prozesses verursacht (aka FHEM hängt). Ich wuerde das Problem mit einem "attr global verbose 5" log lokalisieren, andere verwenden das apptime Befehl in FHEM.

[Gunther]

danke, habe global mal auf verbose 5 gesetzt. Mal sehen

[xenos1984]

Schon eine Weile habe ich mich über den Speicherverbrauch von FHEM gewundert, und jetzt habe ich zufälligerweise mal diesen Thread gefunden. Vielleicht lässt sich mein Problem auf diesem Wege auch lösen.

Die Symptomatik: Der Speicherverbrauch wächst bei mir innerhalb von einigen Tagen / 1-2 Wochen von anfänglich unter 70MB in den GB-Bereich.

Das System:

Code Auswählen Erweitern

Ubuntu Bionic (18.04.3 LTS)
Perl v5.26.1
FHEM neueste SVN 20827
libxml-parser-perl                    2.44-2build3
libxml-twig-perl                      1:3.50-1
libxml-xpath-perl                     1.42-1
libxml-xpathengine-perl               0.14-1

Im Verdacht habe ich HTTPMOD und XML / XPath - davon habe ich einige Geräte definiert. Ich habe einmal testweise das mit der höchsten Abfragerate (5 Sekunden, Ziel der Abfrage ist ein Mediaplayer, zwecks Anzeige von Status und "Now Playing") auf disable = 1 gesetzt, um zu testen, ob es dann immer noch so schnell ansteigt.

[xenos1984]

Nun habe ich einige Testergebnisse:

• Wenn ich alle HTTPMOD Geräte (und testweise auch Weather) auf disable=1 setze, bleibt der Speicherbedarf praktisch konstant (zumindest über eine Nacht, aber das sollte reichen als Test, s.u.).
• Wenn ich die HTTPMOD Geräte wieder aktiviere, steigt der Speicherbedarf "sofort" wieder an, in dem Fall um ca. 5MB / Stunde.
• Wenn ich das HTTPMOD mit der höchsten Abfragerate rausnehme, ist der Anstieg deutlich langsamer, aber immer noch vorhanden.

Hier ist ein list aller Geräte, insbesondere das erste scheint zu einem schnellen Anstieg zu führen:
https://gist.github.com/xenos1984/dd5245db4804c1b4cd48fb0495179855

[MadMax-FHEM]

Ist dein fhem aktuell!?

Gruß, Joachim

[xenos1984]

Ja, also vom Stand gestern. Ich habe extra vor dem Test noch mal ein Update durchgeführt.

Code Auswählen Erweitern

System Info
ConfigType: configFile
SVN rev: 20831
OS: linux
Perl: 5.26.1

[MadMax-FHEM]

Ok, wollte ich nur sicherstellen.
Wurde ja einiges gemacht und seither ist bei mir der Speicherverbrauch (inkl. echodevice-Modul und HTTPMODs) wieder ok.

Zwar steigend aber im Rahmen: Laufzeit (weit) über 1 Monat auf einem PI mit 1GB...

Gruß, Joachim

[xenos1984]

Ja, ich habe das Thema einigermaßen verfolgt (bzw. den Verlauf hier zum Teil gelesen) und festgestellt, dass Speicherlecks scheinbar ein "altbekanntes Problem" sind, auch wenn wohl schon einige davon behoben wurden. Wenn auch vermutlich nicht alle...

Letztlich habe ich auch vor, FHEM auf einem RPi laufen zu lassen - gerade deshalb ist FHEM auch mein Favorit, weil es doch relativ wenige Ressourcen braucht. Zum Testen habe ich es erst einmal auf meinem Heimserver installiert - der hat 16GB, deshalb ist mir der Speicherverbrauch zuerst gar nicht aufgefallen, bis ich zufällig mal ein htop habe laufen lassen.

[rudolfkoenig]

@xenos1984: kannst Du bitte den Inhalt von http://deimos:8080/requests/status.xml bereitstellen?

[xenos1984]

@rudolfkoenig: Hier sind gleich zwei Versionen davon, einmal während nichts abgespielt wird:

https://gist.github.com/xenos1984/e5c9195595aa90ed7017ae4d9ab9c499

Und hier während der Wiedergabe:

https://gist.github.com/xenos1984/0d248e2c91ead85c51b0e2f43a560361

Den Whitespace habe ich bewusst so gelassen, wie er vom Server kommt.

[rudolfkoenig]

Ich wuerde gerne das Problem eingrenzen:

Ob das Abholen der Daten ein Problem ist, koennte man so testen:

Code Auswählen Erweitern

fhem> { for my $i1 (0...1000) { HttpUtils_NonblockingGet({ url=>"http://deimos:8080/requests/status.xml", callback=>sub(){ } }) } }
Dabei vorher/nachher Speicherverbrauch pruefen.

Ob das Parsen/Weiterverarbeiten ein Problem ist, koennte man so testen:
- das Ergebnis des Requests erreichbar fuer FHEM in eine Datei ablegen (z.Bsp. /tmp/deimos_on.xml)
- folgende Funktion in 99_myUtils.pm (oder vgl.) einfuegen:

Code Auswählen Erweitern

sub
HTTPMOD_testFile($$)
{
  my ($hash, $fn) = @_;
  my $data = "";
  open(FH, $fn) || return "Can't open $fn: $!";
  $data = join("", <FH>);
  close(FH);
  $hash->{REQUEST}{type} = "update";
  HTTPMOD_Read($hash, undef, $data);
}
- erst testen:

Code Auswählen Erweitern

{ HTTPMOD_testFile($defs{deimos_vlc}, "/tmp/deimos_on.xml") }- wenn keine Fehlermeldung kommt, dann:

Code Auswählen Erweitern

fhem> { for my $i1 (0..1000) { HTTPMOD_testFile($defs{deimos_vlc}, "/tmp/deimos_on.xml") } }

Auch in diesem Fall vorher/nachher pruefen, ob der Speicherverbrauch waechst.

[xenos1984]

@rudolfkoenig: Das scheint schon mal gut zu laufen. Ergebnisse:

• Abholen der Daten: Beim ersten Aufruf der 1000-Get-Schleife hat der Speicher um 7MB zugenommen (ich hatte vorher die HTTPMOD deaktiviert und FHEM neu gestartet, um einen "sauberen Ausgangszustand" zu haben). Aber danach war der Speicher unverändert, wenn ich den Vorgang wiederholt habe. Ich vermute, dass hier etwas initialisiert wurde.
• Parsen der Daten: Das scheint der Knackpunkt zu sein. Hier steigt beim Aufruf der Schleife der Speicher reproduzierbar jedes Mal um ca. 25MB.