Cannot fork: Cannot allocate memory | BlockingInformParent

[Wernieman]

Naja ... da er ein System hat, wo auch mysql und apache läuft sollten die Anzahl der presents-Prozesse auf jedem Falle begrenzt werden.

Irgendwann hatten wir mal jemanden, wo die Begrenzung geholfen hat. Wie man aber presents bändigt, ist mir nicht bekannt ....

[Wzut]

Ich kenne z.Zt. nur zwei Methoden, um die Ursache zu identifizieren

vllt, könnte hier im Thread von DS_Starter vorgeschlagene sub eine Methode 3 bringen ( Antwort #634 am: 14 September 2019, 21:39:25 )
Ich hatte die Tage mir einen Fehler in eines meiner Module gebaut der den hash dieses Device hat zyklisch kräftig wachsen lassen.
U.a. habe ich zum Thema Speicherplatz von Perl Variablen dies gefunden :

Perl vergrößert einen Hash schrittweise auf 8, 16, 32, 64, ... Elemente. D.h. wird das 8. Element zugewiesen, vergößert Perl intern auf 16 Elemente usw. Für jeden Key alloziert Perl vorab einen Pointer (4 Bytes). Zusätzlich kommt mit zunehmender Anzahl Buckets ein wachsender Overhead von 9, 10, 11, ... Bytes je Key hinzu. Die Größe des Key geht auch mit ein.

[Christoph Morrison]

vllt, könnte hier im Thread von DS_Starter vorgeschlagene sub eine Methode 3 bringen ( Antwort #634 am: 14 September 2019, 21:39:25 )

(Einfach auf den Titel eines Postings klicken, dann springt man direkt zu ihm und kann es auch direkt verlinken: Posting #634)

[en-trust]

So, das presence.sh hab ich erstmal rausgeschmissen und mir analyzeObject eingerichtet. Nach etwas Recherche hier im Forum bin ich noch auf eine Option innodb_buffer_pool_size=128M in der (/etc/mysql/mariadb.conf.d/50-server.cnf) gestoßen. Läuft seit heute morgen...

Code Auswählen Erweitern

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  812 fhem      20   0  220864 175256  12556 S   3,6  18,8   8:31.17 perl
1372 fhem      20   0  167592 113284   3800 S   0,0  12,1   0:04.90 perl
  605 mysql     20   0  731600  94536  15760 S   0,0  10,1   0:21.38 mysqld
1173 pi        20   0  307844  58132  44872 S   0,0   6,2   0:02.49 zenity


mysql steht stabil bei 10%. Aber der erste Prozess von fhem steigt stetig, zwar nicht mehr so schnell, wie vorher, aber dennoch.

Hier mal die derzeit größten averages die apptime anzeigt

Code Auswählen Erweitern

name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
HA.Sven.Off                              notify_Exec                          20124        3   20124.50  6708.17     0.00     0.00 20.11. 14:06:26 HASH(HA.Sven.Off); HASH(Smartphone_Sven)
HA.Sven                                  dummy_Set                            20118        2   40199.01 20099.51     0.00     0.00 20.11. 14:06:26 HASH(HA.Sven); HA.Sven; off
HA.Sven.Off.PushNotify                   notify_Exec                          20088        2   20088.83 10044.41     0.00     0.00 20.11. 14:06:26 HASH(HA.Sven.Off.PushNotify); HASH(HA.Sven)
PushMessenger                            Pushover_Set                         20084        2   40144.47 20072.24     0.00     0.00 20.11. 14:06:26 HASH(PushMessenger); PushMessenger; msg; 'Anwesenheit'; 'Sven/Handy; hat; das; Haus; verlassen.'; ''; 0; ''
HA.Sven.On                               notify_Exec                          20082        3   20082.79  6694.26     0.00     0.00 20.11. 14:09:15 HASH(HA.Sven.On); HASH(Smartphone_Sven)
tmr-GetUpdate                            update                               20064      176  224591.89  1276.09 106302.70  3580.65 20.11. 13:58:41 update:TV_Programme
HA.Sven.On.PushNotify                    notify_Exec                          20061        2   20062.13 10031.06     0.00     0.00 20.11. 14:09:15 HASH(HA.Sven.On.PushNotify); HASH(HA.Sven)

Code Auswählen Erweitern

analyzeObject - check object $defs{HA.Sven} type: HASH
analyzeObject - Data::Peek deep: 0 -> analyzed $defs{HA.Sven} (type: HASH):
SV = IV(0x28a0448) at 0x28a0448
  REFCNT = 1
  FLAGS = (ROK)
  RV = 0x690de60

analyzeObject - Devel::Size -> total size object $defs{HA.Sven} (type: HASH): 2971 Bytes
analyzeObject - checked .attraggr (type: ARRAY): 44 Bytes
analyzeObject - checked .eventMapCmd (type: PV): 42 Bytes
analyzeObject - checked NAME (type: PV): 42 Bytes
analyzeObject - checked NR (type: PV): 50 Bytes
analyzeObject - checked helper (type: HASH): 1231 Bytes
analyzeObject - checked TYPE (type: PV): 42 Bytes
analyzeObject - checked .attreocr (type: ARRAY): 102 Bytes
analyzeObject - checked .attrminint (type: ARRAY): 44 Bytes
analyzeObject - checked FUUID (type: PV): 74 Bytes
analyzeObject - checked READINGS (type: HASH): 461 Bytes
analyzeObject - checked STATE (type: PV): 66 Bytes

Code Auswählen Erweitern

analyzeObject - check object $defs{PushMessenger} type: HASH
analyzeObject - Data::Peek deep: 0 -> analyzed $defs{PushMessenger} (type: HASH):
SV = IV(0x28a0448) at 0x28a0448
  REFCNT = 1
  FLAGS = (ROK)
  RV = 0x25d3d68

analyzeObject - Devel::Size -> total size object $defs{PushMessenger} (type: HASH): 9239 Bytes
analyzeObject - checked TYPE (type: PV): 42 Bytes
analyzeObject - checked FVERSION (type: PV): 80 Bytes
analyzeObject - checked .FhemMetaInternals (type: PV): 24 Bytes
analyzeObject - checked .attrminint (type: ARRAY): 44 Bytes
analyzeObject - checked .attraggr (type: ARRAY): 44 Bytes
analyzeObject - checked NAME (type: PV): 47 Bytes
analyzeObject - checked NR (type: PV): 50 Bytes
analyzeObject - checked USER_KEY (type: PV): 64 Bytes
analyzeObject - checked helper (type: HASH): 1794 Bytes
analyzeObject - checked APP_TOKEN (type: PV): 64 Bytes
analyzeObject - checked FUUID (type: PV): 74 Bytes
analyzeObject - checked READINGS (type: HASH): 5617 Bytes
analyzeObject - checked STATE (type: PV): 70 Bytes
analyzeObject - checked VALIDATION_TIMER (type: PV): 76 Bytes
analyzeObject - checked DEF (type: PV): 95 Bytes

[DS_Starter]

Würde mal sagen da ist noch nichts aufregendes zu sehen.
Am Besten gehst du ein Device nach dem anderen durch (nicht jedes notify oder at).

Z.B. (in Klammern steht der Devicename):

{ analyzeObject("CamHE1") }

Willst du tiefer rein gehen, setzt du ein oder mehrere Unterobjekte mit Leerzeichen dahinter:
{ analyzeObject("CamHE1 HELPER .SNAPHASH") }

Du kannst es dir auch vereinfachen, indem du einen Modultyp angibst, z.B.:
{ analyzeObject("TYPE=SSCam") }

Manche Typen kann man nicht untersuchen (siehe den angegebenen Post).

Wenn du auf verdächtig große Datenmangen stößt, beobachte ob sie permanent wachsen. Das wäre dann ein Ansatz.
Vielleicht hilft das Vorgehen, auch wenn es zeitraubend ist.

Grüße,
Heiko

[en-trust]

Würde mal sagen da ist noch nichts aufregendes zu sehen.

Ich habe mal hier irgendwo gelesen, wenn bei apptime der average größer 1000 ist, sollte man der Sache nachgehen.

[DS_Starter]

Mit apptime misst man im Prinzip das Antwortzeitverhalten des Systems bzw. mögliche Blockierungen.
Du brauchst aber Hinweise für ein Speicherwachstum bei dir. Da hilft dir apptime wenig ... andere Baustelle für einen anderen Zweck Sachverhalt.

[mumpitzstuff]

Ich würde mit den Dingen beginnen, die relativ häufig aufgerufen werden. Es ist relativ unwahrscheinlich das etwas die Ursache ist, das nur 2-3 Mal ausgeführt wurde. Wenn das der Fall ist, müsste dein Speicheranstieg relativ starke Stufen aufweisen, die man sehen würde, wenn man relativ häufig den Speicher Wert erfasst.

[en-trust]

Hab jetzt seit heute Morgen konstante 385Mb Speicherverbrauch.
Gelöscht habe ich das TVProgramm Device. Darüber hinaus habe ich den Kernel von 7 auf 8 aktualisiert. Ob das aber einen positiven Einfluss hat...
Ich beobachte mal weiter.

[W_Esch]

Hallo zusammen,
Hatte auch seit zwei Monaten das Problem mit Memorywachstum. Habe das Modul frezemon, welches inaktiv war, heute aus der config gelöscht. Nach dem Neustart ist der Speicherverbrauch konstant. 
Das war die Lösung. Da mein System 8GB Memory hat ist mir erst gestern das System stehen geblieben. Ein durchforsten der Logs hat gezeigt, dass das Problem seit ca. 4 Wochen existierte.

[vknie]

Hallo zusammen,

ich hatte bis eben auch das Problem mit dem Memory-Schwund und den halben Thread bis zum Ende durchgelesen.
Ausgerechnet im derzeit letzten Beitrag von W_Esch steht auch für mich die Lösung und auch der Verlauf war in etwa identisch.
Auch bei mir war das Modul inaktiv, aber eben doch sehr zerstörerisch. Damit rechnet man ja eigentlich nicht.
Hätte ich von einem "inaktiven" Modul nicht erwartet. Muss man mit sowas auch bei "disabled" rechnen.
Danke W_Esch für den Hinweis. 

[scooty]

Und noch eine Kombination, die zu Speicherwachstum führt (zumindest auf meinem System):

   
• Tablet(s) mit FULLY-Browser
• Auf Tablet(s) im FULLY-Browser die "MQTT Integration" aktiviert, als  "MQTT Broker URL" den MQTT2_Server von FHEM eingetragen
• Tablet(s) werden in FHEM (automatisch) als MQTT2_DEVICE(s) angelegt

Dann kommt so etwas dabei raus:
s. Bild

Rasantes Wachstum der Speicherbelegung, unterbrochen durch Restarts von FHEM im Rahmen meiner Fehlersuche.

Viele Grüße,
Andreas

[rudolfkoenig]

Kannst Du bitte im Problemfall die Ausgabe von "list -r TYPE=MQTT2_SERVER" und "list TYPE=MQTT2_DEVIECE" hier anhaengen?

[CQuadrat]

Ich hatte das Problem mit wachsendem Speicherverbrauch seit dem Frühjahr auch. Jetzt habe ich das hie gelesen und vorhin (ca 18:00) mein (deaktiviertes) freezmon gelöscht. Hier das Resultat:

[CQuadrat]

So sah es vorher aus. Mit regelmäßigen fhem-Restarts bei den Maxima.