Cannot fork: Cannot allocate memory | BlockingInformParent

Begonnen von Burny4600, 14 Februar 2018, 10:33:06

Vorheriges Thema - Nächstes Thema

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 ....
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Wzut

Zitat von: rudolfkoenig am 19 November 2020, 13:49:20
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 :
ZitatPerl 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.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Christoph Morrison

Zitat von: Wzut am 19 November 2020, 20:07:06
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...

  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
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)


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


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
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

en-trust

ZitatWü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.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

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.
FHEM, Viessmann 300, SMA inverter, Zaehler über OBIS, DeltaSol über VBUS, Bayrol SaltRelax über httpmod, MQTT, Firmata, Homematic, MAX, FS20, Gardena smart Bewässerung, OneWire, SONOS, InfluxDB, GRAFANA, alles integriert und alles auf Docker

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

#851
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
Fhem auf Gigabyte Brix
CUL V3 HM / CUL V3 MAX / MaxCube aFW Homematic&MAX / ZWave.me ZME_UZB1 / SDuino 433 / Velux KLF200
Homematic / MAX / Logitech Hub / ZWave / Wifi LED / div. 433 Temperatursensoren / pywws WH10880 / IO Homecontrol

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:
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), KM271 (per ser2net), SONOS (div. Gimmicks), OneWire, Hue

CQuadrat

So sah es vorher aus. Mit regelmäßigen fhem-Restarts bei den Maxima.
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), KM271 (per ser2net), SONOS (div. Gimmicks), OneWire, Hue