Cannot fork: Cannot allocate memory | BlockingInformParent

Begonnen von Burny4600, 14 Februar 2018, 10:33:06

Vorheriges Thema - Nächstes Thema

rudolfkoenig

ZitatParsen der Daten: Das scheint der Knackpunkt zu sein. Hier steigt beim Aufruf der Schleife der Speicher reproduzierbar jedes Mal um ca. 25MB.
Kannst Du bitte dieses Experiment auch mit dem folgenden "leeren" fhem.cfg wiederholen:
attr global logfile -
attr global modpath .
define WEB FHEMWEB 8084 global
define deimos_vlc HTTPMOD http://deimos:8080/requests/status.xml 3600
attr deimos_vlc disable 1
[...alle anderen deimos_vlc Attribute]
Ich kann bei mir damit kein Speicherverbrauch feststellen.

xenos1984

Hm... Das ist seltsam / interessant. Bei mir passiert auch mit der "leeren" fhem.cfg genau das gleiche. Direkt nach dem Start braucht FHEM ca. 33MB. Wenn ich
{ HTTPMOD_testFile($defs{deimos_vlc}, "/tmp/deimos_on.xml") }
ausführe, kommen knapp 30MB dazu, und das reproduzierbar jedes Mal, wenn ich den Befehl wiederhole.

Vielleicht ein Unterschied in der Perl-Version, oder einem der XML-Parser Module?

Perl v5.26.1
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

rudolfkoenig

Ich habe kein Problem mit perl 5.18, 5.24 und 5.30.

Die Versionen der Perl-Module fuer 5.18 kann ich nicht mehr sagen, fuer die beiden anderen ist es XML::XPath 1.44, und XML::Parser 2.46 (da gerade eben installiert).

xenos1984

Scheint, als hätten wir den Schuldigen gefunden. Nach einem Update von XML::XPath von 1.42 auf 1.44 verläuft der Test (1000 Mal parsen) ohne Speicherzuwachs. Im Moment lasse ich wieder den "Normalbetrieb" laufen, aber bisher habe ich auch hier nur einen geringen Speicheranstieg seit Start von FHEM, und seitdem bleibt er konstant (kein weiterer Anstieg alle 5 Sekunden wie vorher).

Danke für die Hilfe! :)

shamal2008

Hallo zusammen,

da ich seit einigen Tagen auch das Problem hatte und meine Fehler mal mit Abschalten des gesamten Presence-Dienstes einigermaßen geringer (=bessere Laufzeit bis Absturz) geworden sind, hätte ich folgende Frage:

- Wie habt ihr Perl samt den Zusatzmodulen auf diesen Stand gebracht? - mit apt-get update und upgrade erklärt mein Raspi, er ist auf aktuellstem Stand und lt. perl --version bin ich auf 5.24.1

Wie komme ich zu den Ständen, speziell x-path-perl (das scheint ja die Wurzel des Übels zu sein):
Perl v5.26.1
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


Danke,
shamal
FHEM auf RasPiI 3+, MapleCUL 868+433MhZ, MAX! via CUL, LD686 LED-Controller, GHoma Plugins,, Shelly, ConbeeII + IKEA + Xiaomi, div. Infodienste & Google Assistant via FHEM;

KölnSolar

Spekulation: veraltetes Raspbian und nicht buster ?
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

mumpitzstuff

cpan install XML::XPath

Versuchs mal damit. Mit apt bekommst du immer nur alte Bibliotheken.

xenos1984

Zitat von: shamal2008 am 21 Januar 2020, 22:01:53Wie habt ihr Perl samt den Zusatzmodulen auf diesen Stand gebracht?
Unter Ubuntu hatte ich geschaut, ob es von den jeweiligen Bibliotheken aktuellere deb-Pakete gibt (aus einer neueren Ubuntu-Version), die mit den bisher installierten (Ubuntu Bionic) kompatibel sind. Im konkreten Fall brauchte ich nur eine aktuellere Version von libxml-xpath-perl.

shamal2008

Zitat von: mumpitzstuff am 22 Januar 2020, 01:39:53
cpan install XML::XPath

Versuchs mal damit. Mit apt bekommst du immer nur alte Bibliotheken.

Danke mumpitzstuff für den sachdienlichen Hinweis. Die Lib ist jetzt 1.44, damit sollten die Presence Module über Ping ja auch wieder gehen, oder habe ich hier den Faden völlig in einen Knäuel verwoben?

lg Shamal

@KölnSolar: Mann kann es auch als veraltetes Raspian bezeichnen... das letzte Update mit apt-get (angeblich ja die empfohlene Methode) wurde unmittelbar vor dem FHEM Update am 19.1. gemacht...
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch


Aber der Raspi4 ist gerade heute vom Regenwald zu mir geflattert...
FHEM auf RasPiI 3+, MapleCUL 868+433MhZ, MAX! via CUL, LD686 LED-Controller, GHoma Plugins,, Shelly, ConbeeII + IKEA + Xiaomi, div. Infodienste & Google Assistant via FHEM;

KölnSolar

Aktuell ist halt buster.  ;) Aber stretch ist noch OK.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

MadMax-FHEM

Zitat von: shamal2008 am 22 Januar 2020, 16:24:53
Aber der Raspi4 ist gerade heute vom Regenwald zu mir geflattert...

Zitat von: KölnSolar am 22 Januar 2020, 17:44:10
Aktuell ist halt buster.  ;) Aber stretch ist noch OK.

Nicht mehr, wenn der PI4 da ist ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

osid-timo

Hallo,
die Euphorie kann ich leider noch nicht teilen, bei mir ist immernoch ein Speicherverbraucher aktiv
es läuft buster mit Perl 5.28.1
XML::XPath is up to date (1.44) und auch FHEM wird wöchentlich aktualisiert.

ohne den nächtlichen FHEM Restart bei einer Speicherauslastung >24% ist FHEM nicht mehr erreichbar.

wer hat noch eine Idee wie ich den Verschwender finden kann.

Gruß osid-timo
FHEM Pi3: 1* CUL, 30* Homematic, 10* EnOcean
FHEM Pi3: IR-Lesekopf, BT->SMA
FHEM Pi3: ZHK, 1-wire, 1* VBus   Resol DeltaSol BS

mumpitzstuff

Konfiguration sichern und dann immer 5 Geräte löschen und beobachten (ohne Save zu drücken). Wenn der Verbrauch weiter steigt , dann mach ein shutdown restart (dann sind die gelöschten Geräte wieder da) und lösche die nächsten 5. so kannst du dich erst mal ran tasten.

e_brandt

Ich hatte jetzt das gleiche problem, keine Ahnung was ich geändert habe das es dazu kam. Ich habe 2 identische SD Karten, eine ging nun auf einmal nicht mehr.
Durch besagten Fehler lief der Raspi nur noch ca 4 Stunden. Nun habe ich mir gedacht ich kopiere die Aktuelle Fhem.cfg mal auf die andere Karte und alles läuft wieder.
Das ging nicht...nun hatte ich auf beiden  Karten den gleichen Fehler.  Ich habe erstmal das eine System auf aktuellen Stand gebracht (Fhem auf 6.0 und Raspian auf Buster) auf einer Karte, das hat auch nichts gebracht. Jetzt haben wir mal die Demo cfg genommen.Damit war erstmal ruhe. Jetzt haben wir angefangen nach und nach die  Geräte aus der Fhem.cfg zu löschen. Nach der Hälfte war das leck auch gefunden, habe ich gedacht....

Wir haben dann nach und nach wieder alles rein kopiert, und komischer weise geht es jetzt ohne einen wirklichen Fehler gefunden zu haben. Das gleiche Spiel musste ich auf der anderen Karte auch machen. Ich konnte nicht einfach die Fhem.cfg von dem einen funktionierenden Raspi auf den anderen kopieren.

Geht das grundsätzlich nicht? Ich habe leider nicht so viel Ahnung von Fhem / Linux. Ich würde aber gern wissen was ich falsch gemacht habe?

e_brandt

Habe gestern bei meiner 2 Karte ein Update auf Buster gemacht und heute morgen war fhem wieder fest und der Speicher voll. Ich habe dann die fhem.cfg gelöscht und mit der Demo ersetzt. Danach in Teilen eingefügt bis ich alles wieder drin hatte und es läuft wieder.

Was soll das sein?

Gesendet von meinem MHA-L29 mit Tapatalk