Cannot fork: Cannot allocate memory | BlockingInformParent

[Amenophis86]

Gibt es schon Erkenntnisse?

Ja, aber die sind geheim. SCNR

[SouzA]

Sehr hilfreich, danke.

[Amenophis86]

Sehr gerne

Aber mal im Ernst, meinst du nicht die Informationen würden hier stehen, wenn es bereits weitere gäbe? Es gibt sicher keinen Grund diese geheim zu halten.

[andies]

Manchmal werden Threads vergessen.

[Amenophis86]

Das stimmt, aber ob man bei 3 Tage nach dem letzten Post schon von vergessen reden kann mag ich bezweifeln. Aber wir weichen vom Thema ab

[enno]

Ich bin schon dabei. Ich lager ein Modul (MPD, SIP, AVM) nach dem anderen auf meinen zweiten Pi aus. Verbunden über FHEM2FHEM und Dummys funktioniert die Steuerung auf dem auffälligen System weiter.

Die Verlagerung von MPD hat den Speicherverbrauch deutlich reduziert, aber noch nicht beseitigt. Ich warte gerade ab, wann das System das nächste mal stehen bleibt. Dann werde ich die ganzen Wetterdienste umziehen...

Gruss
  Enno

Ich habe den PI jetzt abgeschaltet und bin mit FHEM auf einen NUC mit 4 GB RAM umgezogen. Ich habe FHEM dazu neu installiert und dann die "fhem.cfg" einfach rüberkopiert. Läuft alles, auch der Speicherverbrauch steigt hier an. Da der Rechner aber deutlich mehr Speicher hat und nur FHEM läuft, kommt die Fehlermeldung nicht mehr. Ich habe es bisher noch nicht geschafft (> 2 Wochen) so lange laufenzulassen bis auch dieses System in die Knie geht.

Gruss
  Enno

[nils_]

Ich habe den PI jetzt abgeschaltet und bin mit FHEM auf einen NUC mit 4 GB RAM umgezogen. Ich habe FHEM dazu neu installiert und dann die "fhem.cfg" einfach rüberkopiert. Läuft alles, auch der Speicherverbrauch steigt hier an. Da der Rechner aber deutlich mehr Speicher hat und nur FHEM läuft, kommt die Fehlermeldung nicht mehr. Ich habe es bisher noch nicht geschafft (> 2 Wochen) so lange laufenzulassen bis auch dieses System in die Knie geht.

Gruss
  Enno

da langweilt sich der NUC aber 

aber wenn der speicher auch steigt, ist die wahrscheinlichkeit groß, das der Fehler _demnächst_ (t.b.d ) auch dort auftritt

[rico5588]

Versuch doch mal, was bei mir geholfen hat, freezmon und apptime zu löschen/umbennen im fhem ordner. Danach weißt du dann ob es besser wird. Ich konnte so nach 1 Stunde sagen das es daran liegt...Deaktivierung hat bei mir kwine n Erfolg gezeigt.

[frank]

freezemon ansich macht bei mir keine probleme. erst die aktivierung von apptime über das attribut fm_forceApptime=1 hat bei mir einen permanenten speicherzuwachs von ca 50MB pro tag produziert (sysmon => used ram). nach ca 7 tagen waren fast keine forks mehr möglich.

mit attr fm_forceApptime=0 plus fhem restart konnte ich diesen anstieg abschalten.

es muss allerdings mindestens noch ein problem geben, da ich jetzt auch gesehen habe, dass es bei mir im märz und anfang april bereits auch schon speicherprobleme gab, obwohl damals weder freezemon noch apptime existierten.

dieses "alte" problem kann ich aber zur zeit nicht mehr erkennen. eventuell wurde es mit einem fhem update am 9.4. behoben.

[enno]

freezemon und apptime kann es bei mir nicht sein, habe ich beide nicht aktiviert und zur Sicherheit auch aus /opt/fhem/FHEM/.. gelöscht und beim update exclude.

Gruss
  Enno

[Brice]

Mein Produktivsystem läuft seit dem 20.03.2018 auch ohne erzwungenem shutdown/restart fehlerfei und FHEM hat auch zwischenzeitlich ein update bekommen. Warum das so ist: keine Ahnung. Das es an freezemon liegt, halte ich immer noch für unwahrscheinlich.

Nur an der Androhung, das System zwangsweise bei Überschreitung eines Schwellwertes neu zu starten, kann es nicht liegen . Ich bin ratlos, aber wenn es läuft, dann ist es für mich ok.

Leider habe ich keinen weiteren Tipp für alle Betroffenen.

[DS_Starter]

Hallo zusammen,

möglicherweise gibt es einen Ansatz...

Vor einigen Tagen habe ich mir einen Sonos Play 1 zugelegt und demzufolge das Sonosmodul aktiviert.

Das Modul braucht ohnehin recht viel Speicher, aber die RAM-Ausnutzung stieg permanent von ca. 370MB auf ca.450MB und ebenfalls die  CPU-Last (Minimum) von ca. 0.50% auf über 3% innerhalb von 2 Tagen an. Einen Plot habe ich angehängt.

Zur Fehleriengrenzung habe ich nicht das Modul wieder deaktiviert, sondern habe einem Bauchgefühl folgend die fhem.pl-Version 16211 vom 18.02.2018 (https://svn.fhem.de/trac/browser/trunk/fhem/fhem.pl?rev=16211)  wieder implementiert. Diese Version war die letzte Version bevor die Umstellung der InternalTimer-Verwaltung von Hash nach Array vorgenommen wurde.

Seitdem bleibt die RAM-Nutzung stabil bei ca. 380 MB (geht natürlich mal kräftig hoch, aber wieder runter) und die CPU-Last schwankt zwischen 0,3 und 1,0%. (zweiter Plot)
Um auszuschließen, dass dieser positive Effekt nur bei mir in dieser Konstellation zutrifft, wäre natürlich hilfreich wenn die betroffenen Nutzer diese fhem.pl-Version ebenfalls zum Vergleich einsetzen würden (wer es sich zutraut !)

ACHTUNG: Wer DOIF benutzt wird wahrscheinlich Fehler bekommen und das DOIF-Modul nicht laden können weil in späteren fhem.pl-Versionen eine Funktion eingebaut wurde die DOIF benutzt. Vielleicht kann ja Rudi auch eine fhem.pl zur Verfügung stellen, die die Änderungen von Version 16211 zu Version 16214 nicht enthält (alle anderne aber noch drin sind).

In diesem Sinn Allen einen sonnigen Feiertag und hoffentlich Testerfolge.

LG,
Heiko

[rudolfkoenig]

Da du die InternalTimer Aenderung im Verdacht hast: was liefert

Code Auswählen Erweitern


fhem> { join("\n", map { "$_->{TRIGGERTIME}, $_->{FN}" } @intAtA) }
fhem> { int(keys %intAt) }

im Problemfall zurueck?

Ich habe ein fhem.pl mit

Code Auswählen Erweitern

% svn diff -r16211:16214 fhem.pl > fhem.diff
% patch -R fhem.pl < fhem.diff
erstellt, kurz getestet, und hier angehaengt.

Btw. bei mir lief fhem.pl r16453 34 Tage lang, zuletzt mit 118MB Speicherbelegung.
Nach dem Neustart benoetigt r16675 110MB. Ich verwende nur die von mir betreuten Module.

[DS_Starter]

Hallo Rudi,

danke für die fhem.pl. Habe ich gerade eingespielt und beobachte ...

Da du die InternalTimer Aenderung im Verdacht hast: was liefert
Code: [Auswählen]

fhem> { join("\n", map { "$_->{TRIGGERTIME}, $_->{FN}" } @intAtA) }
fhem> { int(keys %intAt) }

im Problemfall zurueck?

Ich hatte während des Ansteigens des RAM / CPU die diversen Testscripte aus dem Thread ausgeführt, aber keine Auffälligkeiten gesehen.
Vor dem Einsatz von Sonos hatte ich ebenfalls kein solches Verhalten von FHEM festgestellt (zumindest keine die ins Gewicht fielen).
Nun ist es aber so, dass Sonos mit einem Subprozess arbeitet. Liefert dieser Test in diesem Fall brauchbare Hinweise ?

Momentan bin ich mir auch noch nicht ganz so sicher, deswegen wünsche ich mir von anderen Nutzern auch noch Testergebnisse.
Bisher waren die verwendeten Module im Fehlerfall nicht sehr homogen, aber in häufigen Fällen half auf apptime/freezemon zu verzichten.
Das deutet für mich in diese Richtung....

Bis jetzt ist es wie beschrieben ein mit Indizien belegtes Bauchgefühl.
Ich werde die neue fhem.pl jetzt mindestens bis morgen Abend auf meinem Prod laufen lassen und dann nochmal einen Test mit der bisherigen "alten" Version machen. Dann kann ich auch das Statement von oben ausführen.

LG,
Heiko

[enno]

Moin Rudi,

danke für die fhem.pl. Habe ich gerade auch eingespielt und beobachte ...

Gruss
  Enno