Cannot fork: Cannot allocate memory | BlockingInformParent

[Tungsten]

Hallo Zusammen,

ich habe jetzt auch mal angefangen den Speicherverbrauch mit zu loggen.

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


Ist ja wirklich erschreckend wenn man das beobachtet...
Es hilft ein FHEM shutdown+restart.

Ich hätte folgende Fragen/Ideen.

Wäre es möglich im Sysmon den Perl Speicherverbrauch als Reading zu integrieren?
Dann hätte man ein Reading auf das man automatisch reagieren kann.

Wie kann man beitragen das Problem grundsätzlich einzugrenzen?
Es scheinen ja viele betroffen zu sein.

Perl Version ist auch bei mir v5.24.1 auf Pi3 mit Stretch.

Die RAM Speicherauslastung scheint konstant zu sein im gleichen Zeitraum.

Danke Euch!

[Wernieman]

Die Frage ist, ob Du den Speicherverbrauch von FHEM oder vom System loggst.

Es gibt einen gravierenden Unterschied von linux zu Windows: bei Windows wird nur der Speicherverbrauch der Programme angezeigt. bei Linux (und anderen "echten" Unixen) aber den incl. der Cache. Da der Cache aber dynamisch verwaltet wird, wenn mehr Speicher frei wird mehr geached, geht damit bei Unix-Systemen der Speicherverbrauch immer hoch. Auch wenn wenig Speicher gebraucht wird.

Wenn Du dagegen den Speicherverbrauch von FHEM (also des FHEM-Prozess) loggst, ist es dagegen aussagekräftig ....

[Tungsten]

Ich habe meinen Beitrag ergänzt, dass ich wie von Homalix99 vorgeschlagen logge.

Sollte dies ungeeignet sein, dann wäre ich für einen Hinweis und ein define zum richtigen Loggen ins DBlog dankbar.

Evtl hilft es ja das Problem einzugrenzen wenn möglichst viele vergleichbare Daten liefern.

[rudolfkoenig]

Wäre es möglich im Sysmon den Perl Speicherverbrauch als Reading zu integrieren?

Das bitte dem Sysmon Maintainer vortragen, am besten als Patch
Haette den Vorteil, dass frueher oder spaeter der richtige Verbrauch angezeigt wird.
Viele Anfaenger verwenden sowas wie free/used, was irrefuehrend ist.

Wie kann man beitragen das Problem grundsätzlich einzugrenzen?

Alle verwendeten Module einzeln deaktivieren, und schauen, wann es aufhoert. Dann fuer das zuletzt deaktivierten Modul ein Thema im passenden Forumsbereich oeffnen. Wiederholen, bis alle Module wieder integriert sind, und kein Speicherzuwachs zu beobachten ist.

Perl Version ist auch bei mir v5.24.1 auf Pi3 mit Stretch.

5.24 ist bekannt fuer ein Speicherloch in der Regexp-Bibliothek.
Bevor ich mit der Prozedur im vorherigen Absatz anfangen wuerde, wuerde ich eine andere Perl-Version installieren, entweder durch OS-Upgrade oder durch perlbrew.

[Tungsten]

Danke dir, somit überlasst ihr es dem Zufall und einzelnen Usern dem scheinbar generellen Problem individuell nachzugehen.

Kein Wunder dass der Beitrag letzte Woche 3. Geburtstag hatte und 60 Seiten lang ist, ohne eine Lösung zu haben.

[Frank_Huber]

Danke dir, somit überlasst ihr es dem Zufall und einzelnen Usern dem scheinbar generellen Problem individuell nachzugehen.

Kein Wunder dass der Beitrag letzte Woche 3. Geburtstag hatte und 60 Seiten lang ist, ohne eine Lösung zu haben.

Nein, es überlässt hier niemanden etwas dem Zufall.
Es gibt hier aber nicht DAS EINE Problem, es ist bei jedem Betroffenen individuell.
Denke Rudi hätte das längst gefixt wenn es so einfach wäre...
Aber jedes Problem ist anderst, so muss jeder für sich seine Ursache finden und beheben.

[rudolfkoenig]

Danke dir, somit überlasst ihr es dem Zufall und einzelnen Usern dem scheinbar generellen Problem individuell nachzugehen.

Das Problem ist nicht generell, die meisten (mich inklusive) haben kein Problem mit Speicherzuwachs. Ich habe in dieses Problem schon viele Stunden investiert, und waere sehr froh, wenn es nicht mehr auftaucht. Wenn Du uns zeigen kannst, wie man das Problem loest: ich lerne gerne was dazu.

[JoWiemann]

Danke dir, somit überlasst ihr es dem Zufall und einzelnen Usern dem scheinbar generellen Problem individuell nachzugehen.

Es gibt leider keine wirkliche "Regel". Ich habe zwie Fhem Instanzen laufen. Eine auf einem RPi 3b und eine auf einem Cubie. Beide haben die selben Devices und sind per Fhem2Fhem verbunden. Der RPi ist für die Steuerung zuständig. Der Cubie für Visualisierung und Logging. Auf dem RPi war Sysmon der Verursacher für Speicherverbrauch. Nach dem deaktivieren läuft er nun stabil. Auf dem Cubie war es die Perl Version. Nach dem letzen upgrade auf buster läuft er auch mit SysMon stabil.

Mein Test RPi, identisch zum RPi 3b allerdings ein RPi 2, läuft ohne jedwedes Problem.

Grüße Jörg

[Wernieman]

Btw: Was ich jetzt gar nicht gefunden habe (oder überlesen)(und sorry fürs Kapern):
Mit welchen Perl Versionen ist eigentlich FHEM getestet?

Da hier fhem im Docker läuft, wäre ein testen in Verschiedenen Versionen ziemlich einfach möglich ..... (Eventuell sogar automatisch)

[frank]

ich kann im plot von @Tungsten gar kein speicherleck erkennen.
wenn bei unter 120MB bereits "cannot fork" erscheint, hat die hardware nicht genügend freien speicher.
eventuell zu viel andere sw am laufen?

[Tungsten]

ich kann im plot von @Tungsten gar kein speicherleck erkennen.
wenn bei unter 120MB bereits "cannot fork" erscheint, hat die hardware nicht genügend freien speicher.
eventuell zu viel andere sw am laufen?

RAM Auslastung ist einigermaßen stabil bei 65-70%

Total: 926.08 MB, Used: 649.87 MB, 70.17 %, Free: 121.87 MB

Wie deaktiviert man einzelne Module zum Testen? Meint ihr damit über 'attr disable = 1'?

[rudolfkoenig]

Wie deaktiviert man einzelne Module zum Testen? Meint ihr damit über 'attr disable = 1'?

disable=1 ist nicht zuverlaessig, je nach Modul ist es nicht implementiert, oder unterbindet nur bestimmte Funktionen.
Ich meine eine Kopie der Konfiguration ohne irgendeine Definition eines Modul-Typs, und FHEM damit starten.

[Homalix99]

ich kann im plot von @Tungsten gar kein speicherleck erkennen.
wenn bei unter 120MB bereits "cannot fork" erscheint, hat die hardware nicht genügend freien speicher.
eventuell zu viel andere sw am laufen?

Bei mir ging es bei 540 MB für den perl prozess los mit den Meldungen, bei RPi 3 und 1 GB RAM.

Auf die Frage von Tungsten, ob man das als Reading (z. B. in SYSMON integriert) zur weiteren Auswertung und Möglichkeit darauf zu reagieren, machen kann:
Meine Lösung:
1. in 99_myUtil:

Code Auswählen Erweitern


sub psize($) {
    my ($name) = @_;
    my $ret;
    my $v   = `awk '/VmSize/{print \$2}' /proc/$$/status`;
    $ret = sprintf("%.2f",(rtrim($v)/1024));
    fhem ("setreading $name state $ret");
   return;
}


2. Dummy:

Code Auswählen Erweitern


defmod Speicherauslastung dummy
attr Speicherauslastung DbLogExclude .*
attr Speicherauslastung comment Wert gibt die perl-Speicherbelegung durch fhem  an
attr Speicherauslastung event-on-change-reading state
attr Speicherauslastung group Info
attr Speicherauslastung readingList Alarm_PerlsizeLimit Alarm_MEM_Avail
attr Speicherauslastung room System
attr Speicherauslastung setList Alarm_MEM_Avail:slider,100,10,900\
Alarm_PerlsizeLimit:slider,120,10,800
attr Speicherauslastung stateFormat { sprintf("%.2f MB",,(ReadingsVal($name,"state",0)))}


3. AT:

Code Auswählen Erweitern


psize("Speicherauslastung");;\
my $ram_avail = ReadingsVal("RPI_Stat","ram_avail",0);;\
fhem("setreading Speicherauslastung ram_avail $ram_avail");;\
}
attr a_pSize DbLogExclude .*
attr a_pSize group Steuerung
attr a_pSize room System

Ruft alle 5 Min. die Sub auf, welche den Speicherverbrauch des Perl-Prozess direkt in den Dummy schreibt, sowie aus Sysmon (wenn gewünscht, Ram Available abfrägt und als Reading ram_avail in den Dummy kopiert.
Im Dummy kann man dann Grenzwerte setzen und mit weiterer Routine darauf reagieren (z. B. sich eine mail senden lassen, etc.
oder den state des Dummy in DBLog laufen lassen.


Gruß

Alex

[Tungsten]

Kurzes Update von mir. Nach Update von Stretch auf Buster und somit auch Perl v5.28.1 ist das Problem bei mir nicht mehr aufgetreten.

Es hat auch den positiven Nebeneffekt, dass Radiostreams, die ich über FTUI auf einem BT Lautsprecher ausgebe, keine Aussetzer mehr haben.
Den Grund dafür habe ich immer an anderer Stelle gesucht, aber nicht wirklich fixen können.

[cortmen]

Ich bekomme diese Meldung öfters, wenn ich über "hm" meine Temperaturlisten ab und zu neu verteile.
Immer dann wenn 3-4 Devices betroffen sind.
Und es läuft ein:

Code Auswählen Erweitern

HMinfo hm get:configCheck :-f

Am RAM Speicher liegt es nicht:

Code Auswählen Erweitern

KiB Spch :  1768824 gesamt,   904336 frei,   715436 belegt,   149052 Puff/Cache
KiB Swap:        0 gesamt,        0 frei,        0 belegt.  1027560 verfü Spch

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     ZEIT+ BEFEHL
23526 root      20   0    7844   3580   2908 R  10,0  0,2   0:00.63 top
  739 fhem      20   0  371448 313584   8532 S   5,0 17,7 441:06.17 perl