Cannot fork: Cannot allocate memory | BlockingInformParent

[rudolfkoenig]

Code Auswählen Erweitern

Danke, werde jetzt mal das aktuelle 3.28 testen.

Wenn Du 5.28 meinst: das ist zwei Jahre alt.
Aktuell waere 5.32.1 oder 5.33.6

[popy]

Ja, genau  5.28.1.
Hmm, das hat er mir mit "sudo apt-get upgrade" gemacht!?

Sollte ich bei der bleiben oder (wie?) eine neuere installieren?

[rudolfkoenig]

Sollte ich bei der bleiben oder (wie?) eine neuere installieren?

Wenn Du schon so fragst , dann empfehle ich den buster-eigenen 5.28.1 zu nehmen.
Ansonsten gibt es perlbrew. Selbst zu uebersetzen erfordert auch keine tieferen Kenntnisse, hoechstens Geduld.

[popy]

Ahh ok, hatte das 5.20 mit perlbrew installiert.
Dachte es gibt für linux/debian ev. schon eine bessere Möglichkeit 
Dann bleibe ich mal bei 5.28.1.

Danke

[Homalix99]

Hallo,

heute ist es mir auch passiert. Ab 01:14 Uhr stand fhem fast still. Logfile mit der besagten Fehlermeldung  zugemüllt.
Stand: RPi 3 , Deb. stretch, perl (v5.24.1).
Perl VM Logsize chart nachgesehen. Speicherzuwachs ab 19.3., nach 15:00 Uhr konstant.
Was war passiert? Habe als Objekt einen 2. HM-CFG-LAN Adapter definiert, aber nicht angeschlossen, da dieser scheinbar defekt ist. Das Interface war die ganze Zeit auf "closed" und somit keine Probleme.
Nach einem Fhem Neustart (wegen einem anderen Thema), waren delays im fhem- Handling festzustellen.
Wenn das HMLAN Device nicht explizit disabled wird, verursacht es scheinbar delays => Massenweise Perfmon: possible freeze ... Meldungen mit delays von jeweils knapp 3 Sek.
Habe dann erstmal mit apptime nach dem Verursacher gesehen und dann war klar, dass es das HMLAN war. Das Interface des Teils dann mit set close geschlossen und die delays waren weg. Keine Perfmon Logeinträge mehr.
ABER: Seit dem Zeitpunkt wuchs der Speicherverbrauch des perl-Prozesses konstant an (siehe Anhang). Und heute nacht war es dann soweit. Nur ein RPi restart hilft da weiter.

Vielleicht ist das ein nützlicher Hinweis oder diese Art des Problems ist schon bekannt.

VG

Alex

[popy]

Bei 5.24 hatte ich auch massive Speicherprobleme (damals stretch).
Nach downgrade auf 5.20 (perlbrew) lief die Kiste stabil wie nie.
Nach buster upgrade habe ich 5.20 belassen.
Bin grad am testen von 5.28 (auf buster), schaut soweit gut aus:

08.03 VM Akt 348.00
09.03 VM Akt 358.00
09.03 AB Akt  353.84
10.03 VM Akt 354.80
10.03 AB Akt  358.27
11.03 VM Akt 339.48
12.03 M   Akt 358.88
13.03 M   Akt 368.00
14.03 M   Akt 350.00
15.03 M   Akt 372.00
16.03 M   Akt 374.00
17.03 M   Akt 378.00
18.03 M   Akt 382.82
19.03 M   Akt 378.41

Schon ein Anstieg aber nicht so plötzlch bis zum bitteren Ende 

Wenn du auf 5.20 willst, ist nicht trivial, hier eine Anleitung: https://forum.fhem.de/index.php/topic,84372.msg861586.html#msg861586
Das siwtchen zw. der aktuellen (vom OS) und perlbrew ist dann nur ein Eintrag im /etc/init.d/fhem services

pOpY

[Homalix99]

Hi,
Ich weiß ja wie ich das Verhalten reproduzieren kann und es auch vermeiden.
Ziel ist die Umstellung auf ububtu 64 Bit in Docker Container.

Gruß
Alex

[Wernieman]

Imer Docker-Container hast Du den Vorteil  einfacher die perl-Version tauschen zu können ...

[popy]

Das ist ja interessant, macht docker auf einem RPI4b mit 4GB Ram Sinn?

[Homalix99]

Habe ich so am Laufen, allerdings noch nicht mein Produktivsystem.
Für Fhem habe ich 3 Container, neben dem eigentlichen fhem noch Mariadb und MQTT. Aber noch nicht alles getestet.

Gruß

Alex

[Wernieman]

Also DB und Pi .. würde ich nicht so machen ...

Docker hat den Vorteil, die Software zu kapseln. Damit kannst Du im Docker andere Versionen als Außen fahren. Nachteil ist die erhöhte Komplexität und das verschieden Versionen von libarys parallel im Speicher gehalten werden müssen ...

Persönlich habe ich mich gegen den Pi entschieden, aber mein Hauptserver macht auch mehr als "nur" FHEM. Dort läuft aber (fast) alles in Docker. Habe nur beruflich auch viel mit Docker zu tuen.

Btw: Wenn Dir der Offizielle Container für FHEM in Docker nicht gefällt, da Du nur etwas "leichtes" brauchst, kann ich Dir gerne mein Docker-File geben ...

[Homalix99]

Hallo,

bisher läuft fhem mit dem offiziellen image, kann aber theoretisch sein, dass es letztendlich vielleicht doch nicht so passt. Von da her wäre Dein Dockerfile evtl. eine Option.
Kannst mir ja per PM senden, wenn ok.

VG

Alex

[Tungsten]

Stand: RPi 3 , Deb. stretch, perl (v5.24.1).
Perl VM Logsize chart nachgesehen.

Habe das gleiche Setup und Problem.
Wie hast du nur den Perl Speicherverbrauch geloggt? Hast du mal ein define dafür?
Im Sysmon ist nur der Perl Speicher ja nicht enthalten.

Bringt ein Update von Stretch auf Buster etwas?


Danke Dir

[MadMax-FHEM]

Bringt ein Update von Stretch auf Buster etwas?

Bei mir: ja!

ABER: wie du diesem (und weiteren) Thread(s) entnehmen kannst gibt es (wohl) nicht DIE Ursache für den Speicherzuwachs...
...daher auch (wohl) nicht DIE Lösung.

Gruß, Joachim

[Homalix99]

@Tungsten:

Wie hast du nur den Perl Speicherverbrauch geloggt? Hast du mal ein define dafür?

Mein Def. Erzeugt eine Logdatei, welche über svg-Grafik visualisiert werden kann.

Code Auswählen Erweitern


defmod a_pSize at +*00:05 {`echo \`date +"%Y-%m-%d_%H:%M:%S"\` size \`awk '/VmSize/{print \$2}' /proc/$$/status\` >> /opt/fhem/log/perlsize.log`}
attr a_pSize DbLogExclude .*
attr a_pSize comment Dient zum Loggen der Speichergröße vom perl Prozess (fhem)\
Logfile unter /opt/fhem/log/perlsize.log
attr a_pSize group Steuerung
attr a_pSize icon clock
attr a_pSize room System


Grafik:

Code Auswählen Erweitern


defmod SVG_Fhem_VM SVG log_fhem_VM_size:SVG_log_fhem_VM_size_1:CURRENT
attr SVG_Fhem_VM DbLogExclude .*
attr SVG_Fhem_VM plotWeekStartDay 0
attr SVG_Fhem_VM room SVG
attr SVG_Fhem_VM sortby 08


chart im Anhang

Gruß

Alex