Cannot fork: Cannot allocate memory | BlockingInformParent

[enno]

Ich hatte auf meinem NUC lange Ruhe. Im Urlaub hatte ich meine drei Yamaha Musiccast Geräte abgeschaltet. FHEM versuchte sie weiter regelmässig zu finden und der Speicher lief in zwei Tagen voll. Nachdem ich die Module gelöscht hatte war das Problem wieder verschwunden. Jetzt nach dem Urlaub sind die Geräte wieder normal auf Standby und die Module wieder eingespielt. Funktioniert ohne Speicherzuwachs. Kann ich aber schnell wieder provozieren, in dem ich am Gerät den "Stecker ziehe"...

Das Problem ist bei dem von mir genutzten Modul bekannt, nur leider noch nicht offiziell gefixt.
https://forum.fhem.de/index.php/topic,98383.msg955311.html#msg955311

Gruss
  Enno

[CoolTux]

Nun hat es auch mich extremst erwischt. Seit einigen Wochen läuft mir Tag täglich der Speicher voll. Am Ende beantsprucht FHEM 45% Speicher. Sobald er dann 2mal forkt ist Ende im Gelände.
Ich untersuche aktuell das HUE Bridge Modul nach dem ich fhem-connect ausgeschlossen habe. Es frisst zwar auch einiges aber nicht so extrem.
Das einzige was bei mir nachweislich an steigt wenn ich fhemdebug memusage mache ist defs

Code Auswählen Erweitern

defs                            5228452
Das ist kurz nach einen FHEM neustart. Im Moment rette ich mich in dem ich den Speicherpuffer immer leer Räume.

Code Auswählen Erweitern

sync && echo 3 > /proc/sys/vm/drop_caches

Senkt aber natürlich nicht den FHEM Verbrauch sondern gibt nur gepufferten Speicher frei.

[rudolfkoenig]

Nun hat es auch mich extremst erwischt.

Finde ich gut, damit gibt es Hoffnung auf Besserung

Apropos "fhemdebug memusage": sie misst nur (mehr oder weniger richtig) die im Perl sichtbaren Daten, z.Bsp. wenn jemand immer mehr Daten in einem Hash packt, ohne je aufzuraeumen.
Es zeigt bestimmte Probleme aber nicht an:
- Speicherloch im C-Bibliothek
- Vergessene Aufrufe, um Daten im C-Bibliothek freizugeben. Z.Bsp. muessen die Ergebnisse von XML::DOM::Parser->parsefile explizit mit dispose entfernt werden, deswegen ist fuer mich alles, was XML::DOM verwendet, verdaechtig.

Um zu zeigen, dass das Problem nicht alle betrifft, im Anhang die Messungen meines Speicherverbrauchs.
Der leichte Zuwachs kann ich auch ohne Speicherloch erklaeren, da ich immer wieder Kleinigkeiten (z.Bsp. durch Modul-reload) ohne Neustart teste.

[CoolTux]

Finde ich gut, damit gibt es Hoffnung auf Besserung

Apropos "fhemdebug memusage": sie misst nur (mehr oder weniger richtig) die im Perl sichtbaren Daten, z.Bsp. wenn jemand immer mehr Daten in einem Hash packt, ohne je aufzuraeumen.
Es zeigt bestimmte Probleme aber nicht an:
- Speicherloch im C-Bibliothek
- Vergessene Aufrufe, um Daten im C-Bibliothek freizugeben. Z.Bsp. muessen die Ergebnisse von XML::DOM::Parser->parsefile explizit mit dispose entfernt werden, deswegen ist fuer mich alles, was XML::DOM verwendet, verdaechtig.

Um zu zeigen, dass das Problem nicht alle betrifft, im Anhang die Messungen meines Speicherverbrauchs.
Der leichte Zuwachs kann ich auch ohne Speicherloch erklaeren, da ich immer wieder Kleinigkeiten (z.Bsp. durch Modul-reload) ohne Neustart teste.

Leider scheint die Hoffnung verschwindend klein zu sein. Es ist ein mühseliger Akt. Aber schauen wir mal.
Ich habe auf dem FHEM Host im übrigen Debian buster mit perl 5.28.1. Nur zur Info da ja mal der Verdacht auf die Perl Version lag.

[MadMax-FHEM]

Da nun ein agiler Entwickler betroffen ist werfe ich noch mal das echodevice-Modul ins Rennen...

Evtl. gibt es "Parallelen"...

Ich habe eine kleine Testinstallation und wenn ich da dann meine echodevices anlege kann ich zusehen, wie der Speicher wächst...

Nehme ich es wieder raus ist Ruhe...

Mittlerweile teste ich jedes neue Modul auf diesem System für ein paar Tage/Wochen (auch/hauptsächlich wegen Speicher) bevor ich es auf meinem Hauptsystem aktiviere (oder auch nicht)...

Mein Hauptsystem schafft es auf einem PI locker einen Monat und mehr...
...und das soll auch so bleiben...

Gruß, Joachim

[CoolTux]

Da nun ein agiler Entwickler betroffen ist werfe ich noch mal das echodevice-Modul ins Rennen...

Evtl. gibt es "Parallelen"...

Ich habe eine kleine Testinstallation und wenn ich da dann meine echodevices anlege kann ich zusehen, wie der Speicher wächst...

Nehme ich es wieder raus ist Ruhe...

Mittlerweile teste ich jedes neue Modul auf diesem System für ein paar Tage/Wochen (auch/hauptsächlich wegen Speicher) bevor ich es auf meinem Hauptsystem aktiviere (oder auch nicht)...

Mein Hauptsystem schafft es auf einem PI locker einen Monat und mehr...
...und das soll auch so bleiben...

Gruß, Joachim

Ich habe kein Echo Device. Bei mi sind 2 Produktive Systeme betroffen. Ich habe auf meinem Entwicklersystem die Demo Konfig geladen und einige meiner Module. Dort verzeichne ich keinen Anstieg trotz mehrerer Tage Laufzeit. Auf meinem 1. Produktivsystem geht mittlerweile selbst nach einem kompletten reboot der Speicher innerhalb von 24 Stunden durch die Decke.

[MadMax-FHEM]

Einen Echo Dot hätte ich noch über...

Parallelen im Code könnte man auch ohne einen Echo zu haben finden...

Evtl. mit dem Hinweis von Rudi...

Allerdings würde ich es vermutlich nicht "sehen"...
...bzw. "verstehen"...

Gruß, Joachim

[CoolTux]

Einen Echo Dot hätte ich noch über...

Parallelen im Code könnte man auch ohne einen Echo zu haben finden...

Evtl. mit dem Hinweis von Rudi...

Allerdings würde ich es vermutlich nicht "sehen"...
...bzw. "verstehen"...

Gruß, Joachim

Den Tipp von Rudi habe ich mir schon angeschaut. Gefunden habe ich in meiner Umgebung aber kein Modul welches XML::DOM verwendet.
Ich schaue mir gerne das Modul echo Dot an.

[CoolTux]

Ich finde im SVN kein 37_echodevice.

[CoolTux]

Ist nicht offiziell. Ich habe es mir angeschaut. Sieht soweit ok aus.
Der Micha arbeitet mit einer Queue, eventuell wird diese nicht korrekt abgebaut und daher kommt "DEIN" Speicheranstieg. Ist aber mehr so eine Vermutung. Allerdings sollte man das ja auch an Hand der Arbeitsweise des Modules erkennen. Kommen Befehle drüben an oder nicht, Werden Readings aktualisiert oder nicht.
Ich denke mal Du siehst es auch bei einem list am @{$hash->{helper}{CMD_QUEUE}}

[MadMax-FHEM]

Hallo Leon,

danke für's Nachschauen...
Ja ist (noch) nicht offiziell...

Was kann ich an der cmd_queue sehen?

Bei keinem der Echo-Devices steht dort was...

Ich dachte nur ich meld mich noch mal, weil ja nach Modulen "gesucht" wird, die einen Speicheranstieg hervorrufen.
Einige machen das mit "deaktivieren" und schauen wann der Speicheranstieg weg ist...
...ich hab halt (einfach) ein Testsystem aufgesetzt wo ich halt ein Modul nach dem anderen "mal aktiviere" und "teste" bevor es "scharf geht"

Und bei dem Modul ist es einfach und deutlich zu sehen...

Damian hatte auch mal ein spezielles DOIF-Konstrukt gepostet mit dem ebenfalls ein Anstieg "generiert" werden konnte...

Hmmm, dass du es (auch) mit Buster hast, hmmm...

Werde aber trotzdem mal ein System mit Buster aufsetzen...
...mal sehen.

Gruß, Joachim

[CoolTux]

Ich habe nun einige ausschließen können.
Proplanta
UWZ
und diverse eigene Sachen.

Aktuell teste ich ob eventuell meine Umstellung für das HM-MOD-RPI-PCB Schuld sein kann
Habe die Definition geändert von

Code Auswählen Erweitern

/dev/ttyAMA0
nach

Code Auswählen Erweitern

uart://192.168.42.23:12345
Schema

[CoolTux]

Er wächst und gedeiht

Code Auswählen Erweitern


        USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
      1 fhem     22145 11.5 10.5 115056 99696 ?        S    14:36   2:11 /usr/bin/perl fhem.pl configDB
      2 fhem     22145 10.4 10.6 116316 100956 ?       S    14:36   2:25 /usr/bin/perl fhem.pl configDB
      3 fhem     22145  9.1 11.0 120300 105060 ?       S    14:36   3:03 /usr/bin/perl fhem.pl configDB
      4 fhem     22145  8.4 11.4 124268 108900 ?       S    14:36   3:40 /usr/bin/perl fhem.pl configDB
      5 fhem     22145  7.8 11.7 126724 111232 ?       S    14:36   4:09 /usr/bin/perl fhem.pl configDB
      6 fhem     22145  7.4 12.1 130244 114876 ?       S    14:36   4:42 /usr/bin/perl fhem.pl configDB
      7 fhem     22145  7.0 12.4 133392 118024 ?       S    14:36   5:11 /usr/bin/perl fhem.pl configDB
      8 fhem     22145  6.8 12.7 136536 121168 ?       S    14:36   5:43 /usr/bin/perl fhem.pl configDB
      9 fhem     22145  6.7 13.1 139684 124316 ?       S    14:36   6:15 /usr/bin/perl fhem.pl configDB
     10 fhem     22145  6.5 13.4 142836 127468 ?       R    14:36   6:44 /usr/bin/perl fhem.pl configDB
     11 fhem     22145  6.4 13.7 146024 130664 ?       S    14:36   7:20 /usr/bin/perl fhem.pl configDB
     12 fhem     30880  0.0 13.1 146024 124712 ?       S    16:30   0:00 /usr/bin/perl fhem.pl configDB
     13 fhem     22145  6.5 14.1 149228 133992 ?       S    14:36   8:03 /usr/bin/perl fhem.pl configDB
     14 fhem     22145  6.4 14.4 152476 137240 ?       S    14:36   8:35 /usr/bin/perl fhem.pl configDB
     15 fhem     22145  6.3 14.8 156384 141020 ?       S    14:36   9:08 /usr/bin/perl fhem.pl configDB
     16 fhem     22145  6.3 15.1 158996 143760 ?       S    14:36   9:44 /usr/bin/perl fhem.pl configDB
     17 fhem     22145  6.4 15.5 162260 147024 ?       S    14:36  10:27 /usr/bin/perl fhem.pl configDB
     18 fhem     22145  6.6 16.1 169028 153248 ?       S    14:36  11:26 /usr/bin/perl fhem.pl configDB
     19 fhem     22145  6.5 16.5 172948 157040 ?       S    14:36  12:03 /usr/bin/perl fhem.pl configDB
     21 fhem     22145  6.5 16.9 176212 160304 ?       S    14:36  12:37 /usr/bin/perl fhem.pl configDB
     22 fhem     22145  6.4 17.2 179480 163572 ?       S    14:36  13:11 /usr/bin/perl fhem.pl configDB
     23 fhem     22145  6.4 17.5 182744 166836 ?       S    14:36  13:48 /usr/bin/perl fhem.pl configDB
     24 fhem     22145  6.4 17.9 185684 169904 ?       S    14:36  14:27 /usr/bin/perl fhem.pl configDB
     25 fhem     22145  6.4 18.2 189276 173368 ?       S    14:36  15:03 /usr/bin/perl fhem.pl configDB
     27 fhem     22145  6.4 18.6 192544 176636 ?       R    14:36  15:40 /usr/bin/perl fhem.pl configDB
     28 fhem     22145  6.4 18.9 195808 179900 ?       S    14:36  16:15 /usr/bin/perl fhem.pl configDB
     29 fhem     22145  6.3 19.3 199076 183168 ?       S    14:36  16:50 /usr/bin/perl fhem.pl configDB
     30 fhem     22145  6.4 19.6 201688 185908 ?       S    14:36  17:29 /usr/bin/perl fhem.pl configDB
     31 fhem     22145  6.4 19.9 204956 189176 ?       S    14:36  18:10 /usr/bin/perl fhem.pl configDB
     33 fhem     22145  6.4 20.2 208236 192456 ?       S    14:36  18:57 /usr/bin/perl fhem.pl configDB
     34 fhem     22145  6.4 20.6 211508 195728 ?       S    14:36  19:32 /usr/bin/perl fhem.pl configDB
     35 fhem     22145  6.4 20.9 214784 199004 ?       S    14:36  20:10 /usr/bin/perl fhem.pl configDB
     36 fhem     22145  6.3 21.3 218064 202072 ?       S    14:36  20:41 /usr/bin/perl fhem.pl configDB
     37 fhem     22145  6.4 21.6 221340 205136 ?       S    14:36  21:24 /usr/bin/perl fhem.pl configDB
     39 fhem     22145  6.4 21.9 224592 208472 ?       S    14:36  21:59 /usr/bin/perl fhem.pl configDB
     40 fhem     22145  6.3 22.3 227840 211720 ?       S    14:36  22:30 /usr/bin/perl fhem.pl configDB
     41 fhem     22145  6.4 22.7 231412 215320 ?       S    14:36  23:15 /usr/bin/perl fhem.pl configDB
     42 fhem     22145  6.3 22.7 234656 215984 ?       S    14:36  23:49 /usr/bin/perl fhem.pl configDB
     43 fhem     22145  6.3 23.2 238940 220192 ?       S    14:36  24:21 /usr/bin/perl fhem.pl configDB
     44 fhem     22145  6.3 23.5 241536 222940 ?       S    14:36  24:56 /usr/bin/perl fhem.pl configDB
     46 fhem     22145  6.3 23.8 244460 225872 ?       S    14:36  25:27 /usr/bin/perl fhem.pl configDB
     47 fhem     22145  6.2 24.1 247708 229156 ?       S    14:36  25:57 /usr/bin/perl fhem.pl configDB
     48 fhem     22145  6.2 24.5 250960 232424 ?       S    14:36  26:29 /usr/bin/perl fhem.pl configDB
     49 fhem     22145  6.2 24.8 254220 235708 ?       S    14:36  27:14 /usr/bin/perl fhem.pl configDB
     50 fhem     22145  6.2 25.1 256812 238324 ?       S    14:36  27:52 /usr/bin/perl fhem.pl configDB
     51 fhem     22145  6.2 25.4 260056 241604 ?       S    14:36  28:33 /usr/bin/perl fhem.pl configDB
     52 fhem     22145  6.3 25.8 263312 244888 ?       S    14:36  29:13 /usr/bin/perl fhem.pl configDB
     53 fhem     22145  6.3 26.1 266572 248168 ?       S    14:36  29:56 /usr/bin/perl fhem.pl configDB
     54 fhem     22145  6.3 26.5 269896 251496 ?       S    14:36  30:37 /usr/bin/perl fhem.pl configDB


[DS_Starter]

Hallo Marc,

ich hatte mit Buster ebenfalls negative Erfahrungen gemacht.
Nachdem ich Stretch zu Buster upgegradet hatte, war sofort ohne irgendwelche Änderungen an der FHEM-Konfiguration ein erhöhter Speicherverbrauch und ein stetig ansteigender Speicher zu verzeichen.
Schau hier: https://forum.fhem.de/index.php/topic,84372.msg952143.html#msg952143

Mittlerweile habe ich alle Systeme neu mit Buster aufgesetzt (nicht upgegradet). Es hat sich am Bild im Prinzip nicht viel geändert. Ingesamt würde ich behaupten ist der Anstieg nicht mehr so steil. Die Systeme halten 8-9 Tage bevor ein Neustart wegen cannot fork nötig wird. Insgesamt wird bei mir grundsätzlich mehr Speicher gegenüber Stretch verbraucht.

Das hatte ich mit Stretch nicht. Wie gesagt, das alles ohne Änderungen an dem Umfang der eingesetzten Module etc.
Andere User hatten gerade mit Stretch das Problem. Irgendwie gibt sich mir kein Bild.

[CoolTux]

Guten Morgen,

Ich bin gerade wegen dem auf einmal auftretenden Speicherverbrauch zu Buster gewechselt  .
Auch mir ergibt sich noch kein Bild.


Grüße