Cannot fork: Cannot allocate memory | BlockingInformParent

popy · 28 Februar 2020, 12:47:35

Zitat von: yamaha1983 am 21 November 2018, 08:50:33
Hallo,

ich hatte bis gestern das gleiche Problem. Mein Perl war 5.24.1 und per Grafana habe ich meinen Speicherverbrauch mitgeloggt. Es war wie hier mehrfach schon beschrieben. Der Arbeitsspeicher lief voll, forken ging an einem punkt nicht mehr und selbst FHEM hat irgendwann die grätsche gemacht.

Über Perlbrew habe ich dann "mühselig" die Perlversion 5.20.3 neben meinem oben genannten Systemperl kompiliert.
Naja, ein direktes starten mit der alten Version war dann auch nicht möglich, weil dann erstmal etliche Module fehlten. Diese konnten per CPAN auch nachkompiliert werden. Nach gefühlten 10 Umstellversuchen habe ich jetzt alle Module beisammen .
Und ja, was soll ich sagen. Der Speicher ist seitdem absolut stabil bei 100MB. Im Anhang noch die Graphen.

Also probiert es ruhig aus. Klar ist es etwas Aufwand, aber mit perlbrew kann man nicht viel falsch machen.
Vielleicht noch als Tipp. Richtet perlbrew so ein, dass jeder Benutzer von den kompilierten Perlversionen profitieren kann. Ansonsten muss jeder Benutzer für sich alles kompilieren, wenn er etwas auf dem System davon nutzen möchte. Kostet Speicherplatz und vor allem Nerven und Zeit.

Dazu:
Zuerst Backup
Dann System auf den aktuellen Stand bringen:
per root folgendes in die Shell:
apt-get update
apt-get upgrade
Entwicklertools installieren:
apt-get install build-essentials
Nun Perlbrew installieren:
export PERLBREW_ROOT=/opt/perlbrew
mkdir /opt/perlbrew
cd /opt/perlbrew
curl -L https://install.perlbrew.pl | bash

Nach der schnellen Installation kann man diese prüfen mit
perlbrew init

Diese gibt dann nochmal den freundlichen hinweis, dass man in der .bashrc folgenden Eintrag hinzufügen muss:
Öffnen der Bashrc: vi ~/.bashrc
Einfügen der Zeile am Ende: source /opt/perlbrew/etc/bashrc

Zum Testen der Wirksamkeit einfach nochmal ausloggen und per SSH neu als Root einloggen. Dann sollte der befehl perlbrew per Autovervollständigen (TAB Taste) zur verfügung stehen und "perlbrew init" quittiert mit einem "perlbrew root (/opt/perlbrew)" is installed.

Nochmal als Hinweis. Wenn man nun später etwas an den anderen Perlversionen ändern möchte, geht das nur über den root benutzer, weil er jetzt der Besitzer von /opt/perlbrew ist. Alle weiteren Nutzer wie pi, oder fhem brauchen keine Besitzrechte an /opt/perlbrew um es zu nutzen.

Damit jetzt die anderen Nutzer wie pi und fhem auch perlbrew nutzen können müssen folgende zwei Zeilen hinzugefügt werden.
Als pi Benutzer einloggen: vi ~/.profile
export PERLBREW_ROOT=/opt/perlbrew
source /opt/perlbrew/etc/bashrc

Bei meinem FHEM-Installation (unter /opt/fhem) mit dem Benutzer fhem gibt es leider keine .bashrc und diese wird auch nicht verwendet, wenn man diese erstellt. Aber die Datei .profile wird ausgewertet.
Daher einloggen als Benutzer fhem: vi ~/.profile
export PERLBREW_ROOT=/opt/perlbrew
source /opt/perlbrew/etc/bashrc

Jetzt sind die Benutzer dafür eingerichtet perlbrew zu benutzen. Das kann ebenfalls mit einem Neueinloggen in die Shell mit dem Benutzer geprüft werden. Hier wieder perlbrew init ausführen.

Nun geht es an das erstellen der alten Perlversion 5.20.3. Einloggen als root!
Ersteinmal kann geprüft werden, was perlbrew alles an perlversionen kompilieren kann. Dazu der Befehl
perlbrew available. Hier sieht man auch direkt, das wesentlich neuere Versionen verfügbar sind, als mit raspbian ausgeliefert werden. Ob diese funktionieren, weiß ich nicht. Daher bleiben wir erstmal bei 5.20.3. Alles weitere könnt ihr ja später selbst probieren .

Damit das Perl nun kompiliert und für perlbrew verfügbar wird, muss man nun den Befehl
perlbrew install perl-5.20.3
absetzen. Perlbrew läd sich selbstständig die sourcen für perl runter und fängt an diese zu kompilieren. Das dauert jetzt eine ganze weile und die Shell darf nicht geschlossen werden, da sonst der Prozess beendet wird. Daher empfiehlt es sich eigentlich, den Prozess mit nohup zu starten:
nohup perlbrew install perl-5.20.3
Habt ihr aber schon gestartet und wollt diesen Prozess nachträglich von der session abkoppeln gibt es noch einen Trick:
Nach der Eingabe von perlbrew install perl-5.20.3 kommt die shell nicht zum prompt zurück.
Drückt hier einfach STRG+Z, dann steht in der Shell "Angehalten". anschließend gebt ihr "bg" ein. Nun arbeitet der Prozess im Hintergrund weiter, ist aber noch mit der Shell verheiratet und würde beim schließen mitsterben. Daher muss der Prozess noch abgehangen werden. Das geht mit dem Befehl disown %1 (wenn ihr keine weiteren Hintergrundprozesse durch BG erzeugt habt, ist es die 1, ansonsten die job id prüfen).

Während des Kompilierens wird sämtlicher output nach /opt/perlbrew/build.perl-5.20.3.log geschrieben. Ist perlbrew fertig wird am Ende des Logfiles die Meldung "##### Brew Finished #####" geschrieben.
Prüft dann nach, ob dem so ist mit dem Befehl:
perlbrew list
Hier sollte nun die perlversion zu sehen sein.
gebt ihr nun ein perl -v ein, seht ihr dass noch die alte System Perlversion zur Verfügung steht.
Der temporäre Wechsel erfolgt über den Befehl: perlbrew use perl-5.20.3
Jetzt nochmal perl -v eingeben und man sieht dann die Version 5.20.3 in der Ausgabe.

Jetzt kommt der etwas unangenehme Teil. Jetzt benötigt ihr noch sämtliche Module. FHEM ist ja nett und schreibt alles brav ins Log, wenn ein Modul fehlt. Hier kann in der FHEM Log nach @INC gesucht werden und ihr bekommt dann die entsprechenden Hinweise. Um es auch aber etwas zu erleichtern, habe ich die Module die ich brauchte hier mal zusammengetragen:

JSON
Device::SerialPort
URI::Escape
RPC::XML
IO::Socket::SSL
Crypt::CBC
Switch
Net::WebSocket::Server::Connection
Crypt::Cipher::AES
Crypt::Rijndael_PP
LWP::Simple
MIME::Base64
SOAP::Lite

Wenn ihr nun diese Module installiert haben wollt, dann geht das einfach über das cpan tool.
Bitte vorher mit perlbrew use perl-5.20.3 in das perlbrew perl wechseln und dann einfach
cpan JSON
...
cpan SOAP::Lite
eingeben.
Oder einfach alles in eine Zeile
cpan JSON Device::SerialPort URI::Escape RPC::XML IO::Socket::SSL Crypt::CBC Switch Net::WebSocket::Server::Connection Crypt::Cipher::AES Crypt::Rijndael_PP LWP::Simple MIME::Base64 SOAP::Lite

Kleiner Nachtrag hier: Für das SSL Modul muss zwingend noch vorher das Paket libssl-dev installiert sein, da er sonst beim kompilieren abbricht. Also per root:
aptitude install libssl-dev

Für dblog benötigt man noch eine weitere lib:
aptitude install libmariadb-dev

Diese dann so als root mit aktiven perl-5.20.3 installieren:
cpan -T DBD::mysql DBD::MariaDB

Zweite Methode hat den Nachteil, dass man nicht sieht, wenn etwas schiefgeht. Manche Module erfordern auch eine Eingabe (die aber immer mit einem enter quittiert werden kann). Hier nutze ich persönlich gerne das Programm "screen". Damit kann man ein virtuelles Terminal erzeugen und sich jederzeit wieder darauf connecten.

Nutzt ihr auch MySQL/Maria DB müsst ihr mit root noch folgendes Paket installieren:
aptitude install libmariadb-dev
Dann lassen sich auch folgende Perlmodule erfolgreich kompilieren:
cpan DBD::mysql DBD::MariaDB

Wenn ihr es bis hier geschafft habt, dann habt ihr das Schlimmste hinter euch.
Loggt euch nun wieder als fhem ein. Killt euren FHEM Prozess.
perlbrew use perl-5.20.3
perl fhem.pl fhem.cfg (wenn nicht configDB)

Schaut jetzt unbedingt in euer FHEM Log. Sollten euch Module fehlen, wird FHEM diese euch klar benennen. Dann einfach per CPAN nachkompilieren!

Um generell zu prüfen, ob FHEM nun auch mit 5.20 läuft, einfach oben auf der FHEM Seite in das Feld folgendes eingeben;
{`perl -v`}
jetzt sollte die alte Version 5.20.3 zu sehen sein.

Hinweis: perlbrew use setzt die perlversion nur temporär für die aktuelle Session (und deren Kinder natürlich). Bei einem abmelden und neuem anmelden ist die System perlversion 5.24 wieder aktiv.
Ich habe daher in meinem Startskript von FHEM (bei mir /etc/init.d/fhem) folgendes oben nach dem Header hinzugefügt:
export PERLBREW_ROOT=/opt/perlbrew
source /opt/perlbrew/etc/bashrc
perlbrew use perl-5.20.3

Damit startet das FHEM dann immer brav mit der alten Version.

Es ist auch möglich perlbrew permanent als Standardperl für alle Sessions des Benutzers zu setzen. Das geht über
perlbrew switch perl-5.20.3

Das mag ich persönlich aber nicht, weil ich immer selbst und selektiv entscheiden möchte, was ich verwende.

Habt ihr mit perl use eine Version in Benutzung erkennt man das auch, wenn man perlbrew list eingibt. Dann ist dies mit einem Stern gekennzeichnet. Wollt ihr in dieser Session wieder zurück zum Systemperl ohne aus und einloggen, dann geht es über perlbrew off.

Ich persönlich finde perlbrew ganz cool und gibt einem mehr Freiheiten beim rumprobieren mit den Perlversionen. Daher denke ich das sich der Aufwand lohnt. Das Speicherproblem ist damit erstmal Geschichte.

Hallo Zusammen.

Habe seit dem bei mir das Problem vor ~1,5 Jahren Auftrat die Perl Version 5.20.3 laufen.
Mit 5.24 hatte ich genau das gleiche Speicherloch wie jeder hier.
Bin noch auf rapsbian stretch und erwäge ein Update auf buster + perl Update,
die Perl Speicherloch Geschichte hält mich aber davon ab...

Habe die letzten Seiten gelesen und gesehen dass 5.28 das Problem nicht mehr haben sollte bzw. ein modifiziertes HTTPMOD im Umlauf ist.

Wie ist da jetzt der Stand der Dinge?

Ist das regex Thema behoben? kann ich wieder auf eine neuere Perl Version?
Oder muss auch die distro upgdated werden?

Danke
pOpY

mumpitzstuff · 28 Februar 2020, 14:15:28

Es wird dir niemand sagen können, ob du nach einem Upgrade Probleme haben wirst oder nicht. Ich würde dir deshalb raten, eine Kopie deiner SD Karte zu erstellen, dann das Upgrade durchzuführen und bei Problemen zurück auf die Kopie zu gehen.

popy · 29 Februar 2020, 17:49:56

Sorry, falsch formuliert

Hat jemand aktuelles fhem mit buster und perl 5.28 ohne dem RAM Thema am laufen und hatte mit der gleichen Konfiguration, stretch und perl 5.24 den memory leak?

Danke

MadMax-FHEM · 29 Februar 2020, 18:08:50

Stretch und "altes" fhem: Speicherproblem. V.a. Testsystem mit echodevice-Modul.
Auf meinem Hauptsystem auch (bewusst noch ohne echdevice-Modul) aber nicht so schlimm...
fhem aktuell (mit "Fix" schon vor einiger Zeit bzgl. Regex glaub ich) und Stretch schon deutliche Besserung (inkl. echodevice-Modul mittlerweile) und mit Buster ebenfalls gut, ob (deutlich) besser kann ich jetzt nicht sagen...

Aber wie du dem Thread (und anderen) entnehmen kannst, hängt es wohl von vielen Faktoren ab...

Andere hatten z.B. keinerlei Probleme mit dem echodevice-Modul und Stretch...

Daher: wird auch das nicht wirklich beantwortet werden können...

Aber: irgendwann (demnächst) steht (bzw. sollte, meine Meinung) eh ein Umstieg auf Buster an...
...warum nicht jetzt!?

Gruß, Joachim

popy · 29 Februar 2020, 18:27:11

Danke Joachim.
Beim stretch mit perl 5.20.3 ist es eine gerade linie bei mir,
Sprich kein Memory leak.
Wie schaut das RAM Diagramm bei dir bei Buster (perl 5.28) über paar Stunden bzw. Tage aus?

Werde den Schritt auf buster wagen...

Danke

MadMax-FHEM · 29 Februar 2020, 18:47:58

Über Stunden ist nichts zu erkennen, über einige Tage schon aber fhem läuft problemlos über mind. 1 Monat (und verm. [deutlich] länger)...

Meist mach ich aber vorher eh "irgendwas" ("programmieren", update, etc.) und dann ist es ja wieder gut...

EDIT: aber auf alle Fälle nicht schlimmer als zuvor mit Stretch...

EDIT2: wenn keine Speicherprobleme da sind, ist der Umstieg doch noch nicht "zwingend"!? Ich dachte du hast Probleme...

Gruß, Joachim

popy · 01 März 2020, 13:05:33

Zitat von: MadMax-FHEM am 29 Februar 2020, 18:47:58
Über Stunden ist nichts zu erkennen, über einige Tage schon aber fhem läuft problemlos über mind. 1 Monat (und verm. [deutlich] länger)...

Meist mach ich aber vorher eh "irgendwas" ("programmieren", update, etc.) und dann ist es ja wieder gut...

EDIT: aber auf alle Fälle nicht schlimmer als zuvor mit Stretch...

EDIT2: wenn keine Speicherprobleme da sind, ist der Umstieg doch noch nicht "zwingend"!? Ich dachte du hast Probleme...

Gruß, Joachim

Nein, habe keine Probleme mit stretch + dem alten perl 5.20.3.
Wollte halt ev. mal das uralt perl in Rente schicken

Aber du hast recht, wahrscheinlich sollte ich des dabei belassen.
Muss nochmal drüber nachdenken.

pOpY

popy · 07 März 2020, 16:16:36

Hallo, habe jetzt auf buster & testweise perl 5.28 getestet.
Ich glaube ich bleib beim alten perl

buster + perl 5.28 nach reboot:

05.03.2020 08:30 - 306,70 MB
06.03.2020 08:30 - 354, 31 MB
07.03.2020 08:30 - 365,64 MB
07.03.2020 15:30 - 367,66 MB

buster + perl 5.20.3 nach reboot:

02.03.2020 20:29 - 297,53 MB
03.03.2020 09:09 - 322,16 MB
03.03.2020 19:35 - 311,08 MB
04.03.2020 20:24 - 326,56 MB
05.03.2020 08:30 - 326,26 MB

pOpY

holle75 · 13 März 2020, 18:56:28

Ihr Lieben, habe den Thread seit Monaten verfolgt und vor ein paar Wochen das Update von Uralt-Jessie auf Buster auf dem RPI3 angegangen.
Das, um das einzige Poblem welches ich mit fhem hatte (ein gemäßigter RAM Anstieg über 1-2 Wochen bis unresponsiv) zu eliminieren.

Jetzt habe ich noch ca 4 Tage bis wenig bis Nichts mehr geht.

Was ist zu tun? Weiter oben habe ich etwas von LibXXX 1.44 gelesen .... und der Installation über CPAN.

Ist das die Lösung? Irgendwo mal gelesen, dass man es vermeiden sollte über Apt installierte Pakete mit CPAN drüberzubügeln? Ihr seht, kein Linux-Versteher, der Holle

Hat denn jemand Buster mit "perl:5.028001" (und was weiß ich welchen Perl Komponenten-Versionen) ohne das Problem am Laufen? Das wurde noch nicht definitiv beantwortet.

Danke euch
H.

MadMax-FHEM · 13 März 2020, 19:11:11

Jep, 2 fhem auf Buster...

Keine Probleme nicht...
...aber besser als zuvor mit Stretch.

Wobei bei meinen Speicherfressern die letzten fhem-Änderungen eine Verbesserung gebracht haben...

Bei mir läuft fhem auf PI 3 mind. 3-4 Wochen...
Dann ginge sicher noch was aber ich starte da dann mal durch...

Wenn nicht eh schon vorher wegen Änderungen oder einem Update...

Gruß, Joachim

popy · 13 März 2020, 19:19:07

Zitat von: holle75 am 13 März 2020, 18:56:28
Ihr Lieben, habe den Thread seit Monaten verfolgt und vor ein paar Wochen das Update von Uralt-Jessie auf Buster auf dem RPI3 angegangen.
Das, um das einzige Poblem welches ich mit fhem hatte (ein gemäßigter RAM Anstieg über 1-2 Wochen bis unresponsiv) zu eliminieren.

Jetzt habe ich noch ca 4 Tage bis wenig bis Nichts mehr geht.

Was ist zu tun? Weiter oben habe ich etwas von LibXXX 1.44 gelesen .... und der Installation über CPAN.

Ist das die Lösung? Irgendwo mal gelesen, dass man es vermeiden sollte über Apt installierte Pakete mit CPAN drüberzubügeln? Ihr seht, kein Linux-Versteher, der Holle

Hat denn jemand Buster mit "perl:5.028001" (und was weiß ich welchen Perl Komponenten-Versionen) ohne das Problem am Laufen? Das wurde noch nicht definitiv beantwortet.

Danke euch
H.

Ich bin seit dem Anfang bei dem Thema dabei.
Bis jetzt hat bei mir immer nur ein downgrade von perl auf 5.20.3 geholfen. Aber das ist sicher von Konfiguration zu Konfiguration (verw. Module) unterschiedlich.

Hatte mit stretch 5.24 5.26 und mit buster 5.28 durch, am besten geht das perl 5.20.3 mit perl brew installiert, siehe folgenden link :

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

Gutes gelingen
pOpY

holle75 · 13 März 2020, 21:19:14

Zitat von: xenos1984 am 28 Dezember 2019, 21:59:12
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).

@MadMax .... welche XML::XPath Vers. läuft bei dir?

@popy .... mmh, irgendwie nach dem Großputz jetzt so weit downzugraden würde mir schwer fallen. Wenn ich dich richtig verstehe, hast du aber trotzdem noch (wenn auch zeitlich freundlicher) das Problem?

MadMax-FHEM · 13 März 2020, 21:33:10

Was immer mit Buster mitkommt...

Wie krieg ich das raus?

EDIT: wobei die Verbesserung NICHT von irgendwelchen OS-Änderungen kam, sondern von fhem-Änderungen... Also bei mir...

Gruß, Joachim

holle75 · 13 März 2020, 22:09:01

das würde mich auch interessieren. Ich fragte nur weil ich dachte du weißt vielleicht

MadMax-FHEM · 13 März 2020, 22:28:53

Also auf meinem Hauptsystem (Buster) läuft: libxml-xpath-perl 1.44-1 Raspbian:stable

EDIT: auf meinem Stretch Testsystem läuft 1.40-1 / aber auch da hatte ich VOR den fhem-Änderungen ein Speicherproblem mit dem echodevice-Modul, ebenso (nicht ganz so schlimm) auf meinem Buster Testsystem. Dann wurde in fhem und im echodevice-Modul was geändert und es wurde deutlich besser! Sonst wäre das echodevice-Modul NIE auf mein Hauptsystem gekommen...

Gruß, Joachim