Cannot fork: Cannot allocate memory | BlockingInformParent

[DS_Starter]

Hallo zusammen,

so, das wars erstmal mit buster.
Nachdem ich weiterhin einen stetigen RAM-Anstieg verzeichnete, habe ich heute 13:00 wieder auf stretch restored.
Wie man auf dem Plot deutlich sieht, ist RAM und SWAP wieder so wie es sein soll.

Vielleicht versuche ich es später noch einmal und auch mit einer Neuinstallation, vorerst aber nicht.

Grüße,
Heiko

[towag]

Ich hatte heute wieder einmal einen Totalausfall der Home-Automation ("zur Freude" der Family).
Inzwischen restarte ich die FHEM-Instanz 2x pro Tag. Aber in seltenen Fällen reicht nicht einmal das aus.

SystemInfo:
FHEM: Server started with 316 defined entities (fhem.pl:19719/2019-06-27 perl:5.024001 os:linux user:fhem pid:4854)
Raspberry mit Stretch und letztem Patch-Stand
Das System ist nicht wirklich unter Stress: top - 17:30:13 up  2:14,  1 user,  load average: 0.28, 0.26, 0.26
Die GUI (tabletUI) läuft auf einem anderen Device.


Im Logfile kommen immer wieder diese Meldungen von verschiedenen Modulen vor (hier nur ein Auszug)
Ich weiß nicht, ob das gehäufte Auftreten heute Morgen und der Memory-Verbrauch (siehe Grafik) in Zusammenhang stehen.

Vielleicht hat jemand einen Anhaltspunkt?


2019.07.01 06:47:40 1: PERL WARNING: Use of uninitialized value $hcitool in concatenation (.) or string at ./FHEM/73_PRESENCE.pm line 990.
2019.07.01 06:47:40 1: stacktrace:
2019.07.01 06:47:40 1:     main::__ANON__                      called by ./FHEM/73_PRESENCE.pm (990)
2019.07.01 06:47:40 1:     main::PRESENCE_DoLocalBluetoothScan called by FHEM/Blocking.pm (194)
2019.07.01 06:47:40 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2019.07.01 06:47:40 1:     main::BlockingCall                  called by ./FHEM/73_PRESENCE.pm (707)
2019.07.01 06:47:40 1:     main::PRESENCE_StartLocalScan       called by fhem.pl (3297)
2019.07.01 06:47:40 1:     main::HandleTimeout                 called by fhem.pl (671)
2019.07.01 06:47:40 1: PERL WARNING: Use of uninitialized value $hcitool in scalar chomp at ./FHEM/73_PRESENCE.pm line 991.
2019.07.01 06:47:40 1: stacktrace:
2019.07.01 06:47:40 1:     main::__ANON__                      called by ./FHEM/73_PRESENCE.pm (991)
2019.07.01 06:47:40 1:     main::PRESENCE_DoLocalBluetoothScan called by FHEM/Blocking.pm (194)
2019.07.01 06:47:40 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2019.07.01 06:47:40 1:     main::BlockingCall                  called by ./FHEM/73_PRESENCE.pm (707)
2019.07.01 06:47:40 1:     main::PRESENCE_StartLocalScan       called by fhem.pl (3297)
2019.07.01 06:47:40 1:     main::HandleTimeout                 called by fhem.pl (671)
2019.07.01 06:47:40 1: PERL WARNING: Use of uninitialized value $hcitool in -x at ./FHEM/73_PRESENCE.pm line 993.
2019.07.01 06:47:40 1: stacktrace:
2019.07.01 06:47:40 1:     main::__ANON__                      called by ./FHEM/73_PRESENCE.pm (993)
2019.07.01 06:47:40 1:     main::PRESENCE_DoLocalBluetoothScan called by FHEM/Blocking.pm (194)
2019.07.01 06:47:40 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2019.07.01 06:47:40 1:     main::BlockingCall                  called by ./FHEM/73_PRESENCE.pm (707)
2019.07.01 06:47:40 1:     main::PRESENCE_StartLocalScan       called by fhem.pl (3297)
2019.07.01 06:47:40 1:     main::HandleTimeout                 called by fhem.pl (671)
2019.07.01 06:47:40 2: PRESENCE (Handy_Thomas) - error while processing check: no hcitool binary found. Please check that the bluez-package is properly installed

Das Tool ist installiert und die die Handy-Überwachung funktioniert auch.
root@homecontrol:/opt/fhem/FHEM# which hcitool
/usr/bin/hcitool

2019.07.01 06:57:11 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4751.
2019.07.01 06:57:11 1: stacktrace:
2019.07.01 06:57:11 1:     main::__ANON__                      called by fhem.pl (4751)
2019.07.01 06:57:11 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/37_Spotify.pm (803)
2019.07.01 06:57:11 1:     main::Spotify_dispatch              called by FHEM/HttpUtils.pm (609)
2019.07.01 06:57:11 1:     main::__ANON__                      called by fhem.pl (745)
2019.07.01 06:57:11 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4751.
2019.07.01 06:57:11 1: stacktrace:
2019.07.01 06:57:11 1:     main::__ANON__                      called by fhem.pl (4751)
2019.07.01 06:57:11 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/37_Spotify.pm (805)
2019.07.01 06:57:11 1:     main::Spotify_dispatch              called by FHEM/HttpUtils.pm (609)
2019.07.01 06:57:11 1:     main::__ANON__                      called by fhem.pl (745)
2019.07.01 07:15:43 1: PERL WARNING: Use of uninitialized value in int at ./FHEM/42_SYSMON.pm line 3516.
2019.07.01 07:15:43 1: stacktrace:
2019.07.01 07:15:43 1:     main::__ANON__                      called by ./FHEM/42_SYSMON.pm (3515)
2019.07.01 07:15:43 1:     main::SYSMON_isCPUTempBBB           called by ./FHEM/42_SYSMON.pm (1209)
2019.07.01 07:15:43 1:     main::SYSMON_obtainParameters_intern called by ./FHEM/42_SYSMON.pm (1129)
2019.07.01 07:15:43 1:     main::SYSMON_obtainParameters       called by ./FHEM/42_SYSMON.pm (956)
2019.07.01 07:15:43 1:     main::SYSMON_blockingCall           called by FHEM/Blocking.pm (194)
2019.07.01 07:15:43 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2019.07.01 07:15:43 1:     main::BlockingCall                  called by ./FHEM/42_SYSMON.pm (905)
2019.07.01 07:15:43 1:     main::SYSMON_Update                 called by fhem.pl (3297)
2019.07.01 07:15:43 1:     main::HandleTimeout                 called by fhem.pl (671)
2019.07.01 07:15:43 1: PERL WARNING: Use of uninitialized value $entry in index at ./FHEM/42_SYSMON.pm line 2186.
2019.07.01 07:15:43 1: stacktrace:
2019.07.01 07:15:43 1:     main::__ANON__                      called by ./FHEM/42_SYSMON.pm (2186)
2019.07.01 07:15:43 1:     main::SYSMON_getCPUProcStat         called by ./FHEM/42_SYSMON.pm (1230)
2019.07.01 07:15:43 1:     main::SYSMON_obtainParameters_intern called by ./FHEM/42_SYSMON.pm (1129)
2019.07.01 07:15:43 1:     main::SYSMON_obtainParameters       called by ./FHEM/42_SYSMON.pm (956)
2019.07.01 07:15:43 1:     main::SYSMON_blockingCall           called by FHEM/Blocking.pm (194)
2019.07.01 07:15:43 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2019.07.01 07:15:43 1:     main::BlockingCall                  called by ./FHEM/42_SYSMON.pm (905)
2019.07.01 07:15:43 1:     main::SYSMON_Update                 called by fhem.pl (3297)
2019.07.01 07:15:43 1:     main::HandleTimeout                 called by fhem.pl (671)
2019.07.01 07:15:43 1: PERL WARNING: Use of uninitialized value $free_version in substitution (s///) at ./FHEM/42_SYSMON.pm line 2268.
2019.07.01 07:15:43 1: stacktrace:
2019.07.01 07:15:43 1:     main::__ANON__                      called by ./FHEM/42_SYSMON.pm (2268)
2019.07.01 07:15:43 1:     main::SYSMON_getRamAndSwap          called by ./FHEM/42_SYSMON.pm (1255)
2019.07.01 07:15:43 1:     main::SYSMON_obtainParameters_intern called by ./FHEM/42_SYSMON.pm (1129)
2019.07.01 07:15:43 1:     main::SYSMON_obtainParameters       called by ./FHEM/42_SYSMON.pm (956)
2019.07.01 07:15:43 1:     main::SYSMON_blockingCall           called by FHEM/Blocking.pm (194)
2019.07.01 07:15:43 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2019.07.01 07:15:43 1:     main::BlockingCall                  called by ./FHEM/42_SYSMON.pm (905)
2019.07.01 07:15:43 1:     main::SYSMON_Update                 called by fhem.pl (3297)
2019.07.01 07:15:43 1:     main::HandleTimeout                 called by fhem.pl (671)
2019.07.01 07:15:43 1: PERL WARNING: Use of uninitialized value $free_version in numeric gt (>) at ./FHEM/42_SYSMON.pm line 2269.
2019.07.01 07:15:43 1: stacktrace:
2019.07.01 07:15:43 1:     main::__ANON__                      called by ./FHEM/42_SYSMON.pm (2269)
2019.07.01 07:15:43 1:     main::SYSMON_getRamAndSwap          called by ./FHEM/42_SYSMON.pm (1255)
2019.07.01 07:15:43 1:     main::SYSMON_obtainParameters_intern called by ./FHEM/42_SYSMON.pm (1129)
2019.07.01 07:15:43 1:     main::SYSMON_obtainParameters       called by ./FHEM/42_SYSMON.pm (956)
2019.07.01 07:15:43 1:     main::SYSMON_blockingCall           called by FHEM/Blocking.pm (194)
2019.07.01 07:15:43 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2019.07.01 07:15:43 1:     main::BlockingCall                  called by ./FHEM/42_SYSMON.pm (905)
2019.07.01 07:15:43 1:     main::SYSMON_Update                 called by fhem.pl (3297)
2019.07.01 07:15:43 1:     main::HandleTimeout                 called by fhem.pl (671)

2019.07.01 07:17:28 1: Cannot fork: Cannot allocate memory
2019.07.01 07:17:28 1: stacktrace:
2019.07.01 07:17:28 1:     main::fhemFork                      called by FHEM/Blocking.pm (172)
2019.07.01 07:17:28 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2019.07.01 07:17:28 1:     main::BlockingCall                  called by ./FHEM/73_PRESENCE.pm (707)
2019.07.01 07:17:28 1:     main::PRESENCE_StartLocalScan       called by fhem.pl (3297)
2019.07.01 07:17:28 1:     main::HandleTimeout                 called by fhem.pl (671)
2019.07.01 07:17:28 1: Cannot fork:
2019.07.01 07:17:28 1: Cannot fork: Cannot allocate memory

2019.07.01 17:19:19 1: stacktrace:
2019.07.01 17:19:19 1:     main::__ANON__                      called by fhem.pl (4751)
2019.07.01 17:19:19 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/37_Spotify.pm (803)
2019.07.01 17:19:19 1:     main::Spotify_dispatch              called by FHEM/HttpUtils.pm (609)
2019.07.01 17:19:19 1:     main::__ANON__                      called by fhem.pl (745)
2019.07.01 17:19:19 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4751.

[CoolTux]

Setze mal im global Device das Attribut
blockingCallMax auf 6

[maci]

Seit ca einer Woche hatte ich schon 2 mal das Problem mit dem Cannot allocate memory.

Zuvor ist das bei diesem System noch nie aufgetreten.
Ich habe sogar das notify das, das System neu starten soll, wenn das auftreten soll eingebaut. Es läuft schon mehre Monate.
Doch bei mir ist es immer so, dass sich einfach Fhem beendet und alles andere bleibt.
Hier eine Log Auszug:

Code Auswählen Erweitern

2019.07.04 21:53:27 3: DbLog DBLogging: Reopen requested.
2019.07.04 21:53:27 3: DbLog DBLogging - Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user fhemuser
2019.07.04 21:53:27 3: DbLog DBLogging - Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2019.07.04 21:53:27 3: DBLogging_Reopen: Reopen executed.
2019.07.04 21:53:33 3: DbLog DBLogging -> addLog created - TS: 2019-07-04 21:53:33, Device: Raspberry_Ventilator, Type: RPI_GPIO, Event: addLog, Reading: state, Value: on, Unit:
2019.07.04 21:53:33 3: SolarEdge: set interval changed interval to 60 seconds
2019.07.04 21:53:34 3: DbLog DBLogging -> addLog created - TS: 2019-07-04 21:53:34, Device: Schalter_Poolpumpe_Sw, Type: CUL_HM, Event: addLog, Reading: state, Value: off, Unit:
2019.07.04 21:53:45 3: wforecast: poll (FORECAST)
2019.07.04 21:53:45 3: netatmo_R70_ee_50_0c_06_84: poll (RELAY)
2019.07.04 21:53:45 3: netatmo_R70_ee_50_0c_06_84: requestThermostatReadings (70:ee:50:0c:06:84)
2019.07.04 21:53:57 1: Cannot fork: Cannot allocate memory
2019.07.04 21:53:57 1: Cannot fork: Cannot allocate memory
2019.07.04 21:53:58 0: Server shutdown
2019.07.04 21:53:58 2: DbLog DBLogging - waiting for shutdown 3 seconds ...
2019.07.04 21:54:01 2: DbLog DBLogging - continuing shutdown sequence
2019.07.04 21:54:01 1: [Freezemon] myFreezemon: Long function call detected ShutdownFn:DBLogging - 3.014468 seconds
2019.07.04 21:54:01 1: Shutdown executed
2019.07.04 21:54:01 1: Shutdown executed
2019.07.04 23:44:42 3: [UtilsHourCounter] Init Done with Version 1.0.1.0 - 10.12.2014 (john)
2019.07.04 23:44:43 1: Including fhem.cfg
2019.07.04 23:44:43 3: WEB: port 8083 opened
2019.07.04 23:44:43 3: WEBtablet: port 8085 opened
um 23.44 habe ich meinen Raspberry neu gestartet.

Mein Raspberry läuft mit einer SSD und hat eingeschalteten Swap.

Wenn ich in Sysmon nach sehe, sehe ich dass der RAM Verbrauch stetig steigt.

Was mich etwas erstaunt, ist die Tatsache, dass dies erst jetzt auftritt und nicht schon früher.
Wobei ich am System nichts geändert habe. Weder ein Update noch sonst etwas.

Gruß Georg

[towag]

Wenn ich mich nicht täusche macht der Speicherverbrauch einen Sprung wenn im Logfile dieses Fehlermuster auftritt:

2019.07.05 06:47:37 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4751.
2019.07.05 06:47:37 1: stacktrace:
2019.07.05 06:47:37 1:     main::__ANON__                      called by fhem.pl (4751)
2019.07.05 06:47:37 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/37_Spotify.pm (803)
2019.07.05 06:47:37 1:     main::Spotify_dispatch              called by FHEM/HttpUtils.pm (609)
2019.07.05 06:47:37 1:     main::__ANON__                      called by fhem.pl (745)
2019.07.05 06:47:37 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4751.
2019.07.05 06:47:37 1: stacktrace:
2019.07.05 06:47:37 1:     main::__ANON__                      called by fhem.pl (4751)
2019.07.05 06:47:37 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/37_Spotify.pm (805)
2019.07.05 06:47:37 1:     main::Spotify_dispatch              called by FHEM/HttpUtils.pm (609)
2019.07.05 06:47:37 1:     main::__ANON__                      called by fhem.pl (745)

[rudolfkoenig]

@maci: _dass_ es ein Problem gibt, will hier keiner bestreiten, ich bin sogar der Meinung, dass mehrere Ursachen gibt. Ich habe das Problem aber nicht (wie die Mehrheit der FHEM-Benutzer auch nicht), kann es nicht nachstellen, und weiss auch nicht, woran das liegt. Bisher haben wir nur einen sinnvollen Vorschlag, das Problem einzugrenzen: alle Module einzeln nach und nach abzuschalten, bis ein Problem-Modul gefunden wird. Leider ist das bisher fuer alle Betroffenen unpraktikabel gewesen, deswegen haben wir auch kein Ergebnis.

@towag: die unmittelbare Ursache ist das Spotify Modul, das ein Reading auf undefined setzen will, weil es auf einem nicht existierenden Wert im JSON zugreift.

[der-Lolo]

könnte FHEM nicht z.b. einmal am Tag die Daten die im Arbeitsspeicher liegen ablöschen..?
Ich denke ja mittlerweile darüber nach täglich automatisch einen neustart zu machen...

Ich denke aber auch darüber nach FHEM auf eine Docker installation zu ändern, sodass nicht das ActivePerl der Synology NAS benutzt werden muss...

[MadMax-FHEM]

Bisher haben wir nur einen sinnvollen Vorschlag, das Problem einzugrenzen: alle Module einzeln nach und nach abzuschalten, bis ein Problem-Modul gefunden wird. Leider ist das bisher fuer alle Betroffenen unpraktikabel gewesen, deswegen haben wir auch kein Ergebnis.

Ich bin dabei es etwas andersrum zu machen

Auf meinem Hauptsystem habe ich (glücklicherweise) auch kein/kaum ein Problem.
Speicher steigt zwar dort auch aber sooo langsam, dass ich gut damit leben kann.
1 Monat plus ist kein Problem.
Und das Notify mit autom. Restart hat dort erst 1x "zugeschlagen", ansonsten habe ich meist davor (wegen "irgendwas") gebootet/neu gestartet...


Ich habe 2 Testsysteme. Also eins zum ausprobieren von allen möglichen Dingen, das System ist (zugegebenermassen) daher schon reichlich "tot-installiert"...
Wenn ich etwas für sinnvoll erachte kommt es erst mal auf mein 2tes Testsystem, das ist eigentlich sehr sauber installiert, da wird eben getestet, ob meine "Installations-Notizen" richtig sind/waren.
Dann läuft es dort eine Weile, um zu sehen, ob "Auffälligkeiten" zu beobachten sind...

Und erst dann geht es auf das Hauptsystem (also nat. nur, wenn nichts aufgefallen ist   )...

Hier habe ich bzgl. des echodevice-Moduls etwas geschrieben:
https://forum.fhem.de/index.php/topic,84372.msg928468.html#msg928468

Gruß, Joachim

[MadMax-FHEM]

könnte FHEM nicht z.b. einmal am Tag die Daten die im Arbeitsspeicher liegen ablöschen..?

Sollte ja passieren, aber der Fehler steckt wohl "in" Perl selbst (also einer oder mehrerer Libs) und daher wird das wohl nicht gehen...
Ansonsten wäre ja komplett ablöschen sowas wie ein "interner Neustart", da kann man auch gleich selbst neu starten...

Ich denke ja mittlerweile darüber nach täglich automatisch einen neustart zu machen...

Das macht das Notify doch im Bedarfsfall automatisch...

Ich denke aber auch darüber nach FHEM auf eine Docker installation zu ändern, sodass nicht das ActivePerl der Synology NAS benutzt werden muss...

Andere Perl-Version: neues Glück (oder auch nicht   )...

Gruß, Joachim

[maci]

Sollte ja passieren, aber der Fehler steckt wohl "in" Perl selbst (also einer oder mehrerer Libs) und daher wird das wohl nicht gehen...
Ansonsten wäre ja komplett ablöschen sowas wie ein "interner Neustart", da kann man auch gleich selbst neu starten...

Das macht das Notify doch im Bedarfsfall automatisch...

Andere Perl-Version: neues Glück (oder auch nicht   )...

Gruß, Joachim

Ich habe schon angefangen mich in Docker einzuarbeiten.
Mein Dell Wyse (AMD 4kern, 4GB, 32GB) ist schon in Betrieb mit Ubuntu Server 18.04
Braucht derzeit ca. 7,8 - 8,5 Watt an Strom. Siehe: https://forum.fhem.de/index.php/topic,99124.0.html

[der-Lolo]

Ich habe ein DOIF gebastelt - welches mir bei RAM Nutzung > 2GB eine Message via Telegram schicken soll.
Nun ist es aber leider so das der Trigger oft ausbleibt wenn FHEM nicht in einem Browser geöffnet ist...
Wenn ich dann größer 2GB habe und FHEMWEB in einem Browser öffne triggert auch das DOIF -
keine ahnung warum das nicht vernünftig funktioniert, das gehört hier aber auch nicht her.

Ich habe jedenfalls keinen Ram Auslastung zuhoch Trigger der zuverlässig unattended kommt...

ein list des DOIFs

Code Auswählen Erweitern

Internals:
   DEF        ([DS716:ram:"Used: (\d+)"] > 2000) (msg push @rr_Michael Ram Auslastung angestiegen Neustart von FHEM ausführen)
DOELSEIF ([$SELF:cmd] eq "1" and [Eichenheim_Bot:msgText] eq "restart") (shutdown restart)
DOELSE()

   FUUID      5d09cb44-f33f-68f5-c05b-95f6255d629b4e15
   MODEL      FHEM
   NAME       RAMmsgAdjust
   NR         202
   NTFY_ORDER 50-RAMmsgAdjust
   STATE      cmd_3
   TYPE       DOIF
   VERSION    19303 2019-05-01 08:47:16
   READINGS:
     2019-07-05 11:06:35   Device          DS716
     2019-06-29 12:16:26   cmd             3
     2019-06-29 12:16:26   cmd_event       DS716
     2019-06-29 12:16:26   cmd_nr          3
     2019-07-05 11:06:35   e_DS716_ram     Total: 7903.75 MB, Used: 909.80 MB, 11.51 %, Free: 1789.29 MB
     2019-06-20 17:19:26   e_Eichenheim_Bot_msgText zu
     2019-06-19 07:42:28   mode            enabled
     2019-06-29 12:16:26   state           cmd_3
   Regex:
     accu:
   attr:
     waitdel:
   condition:
     0          ::ReadingValDoIf($hash,'DS716','ram','','Used: (\d+)') > 2000
     1          ::ReadingValDoIf($hash,'RAMmsgAdjust','cmd') eq "1" and ::ReadingValDoIf($hash,'Eichenheim_Bot','msgText') eq "restart"
   devices:
     0           DS716
     1           RAMmsgAdjust Eichenheim_Bot
     all         DS716 RAMmsgAdjust Eichenheim_Bot
   do:
     0:
       0          msg push @rr_Michael Ram Auslastung angestiegen Neustart von FHEM ausführen
     1:
       0          shutdown restart
     2:
       0         
   helper:
     event      ram: Total: 7903.75 MB, Used: 909.80 MB, 11.51 %, Free: 1789.29 MB
     globalinit 1
     last_timer 0
     sleeptimer -1
     timerdev   DS716
     timerevent ram: Total: 7903.75 MB, Used: 909.80 MB, 11.51 %, Free: 1789.29 MB
     triggerDev DS716
     bm:
       DOIF_Get:
         cnt        1
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        05.07. 11:06:58
         max        2.21729278564453e-05
         tot        2.21729278564453e-05
         mAr:
           HASH(0x8fd25b0)
           RAMmsgAdjust
           ?
       DOIF_Notify:
         cnt        7381
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        05.07. 11:03:35
         max        0.00153589248657227
         tot        0.382654190063477
         mAr:
           HASH(0x8fd25b0)
           HASH(0x8faf768)
       DOIF_Set:
         cnt        3
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        05.07. 11:06:58
         max        5.69820404052734e-05
         tot        0.00013279914855957
         mAr:
           HASH(0x8fd25b0)
           RAMmsgAdjust
           ?
     timerevents:
       ram: Total: 7903.75 MB, Used: 909.80 MB, 11.51 %, Free: 1789.29 MB
     timereventsState:
       ram: Total: 7903.75 MB, Used: 909.80 MB, 11.51 %, Free: 1789.29 MB
     triggerEvents:
       ram: Total: 7903.75 MB, Used: 909.80 MB, 11.51 %, Free: 1789.29 MB
     triggerEventsState:
       ram: Total: 7903.75 MB, Used: 909.80 MB, 11.51 %, Free: 1789.29 MB
   internals:
   itimer:
   perlblock:
   readings:
     0           DS716:ram
     1           RAMmsgAdjust:cmd Eichenheim_Bot:msgText
     all         DS716:ram RAMmsgAdjust:cmd Eichenheim_Bot:msgText
   trigger:
   uiState:
   uiTable:
Attributes:
   group      msg-adjust
   room       97-Helper,99-Controller

[Frank_Huber]

Ich habe das Problem aber nicht (wie die Mehrheit der FHEM-Benutzer auch nicht)

Oder es ist bei den meisten Usern nicht in einem problematischen Level.
Ich sehe bei mir auch auf allen Instanzen einen permanenten Anstieg des Arbeitsspeichers.
Hatte aber noch nie den Fehler mit allocate memory.
Also wenn man nicht darauf schaut merkt man es nicht.

Ich hänge nachher mal noch nen Screen an.

EDIT: Screen angehängt.

[MadMax-FHEM]

Oder es ist bei den meisten Usern nicht in einem problematischen Level.
Ich sehe bei mir auch auf allen Instanzen einen permanenten Anstieg des Arbeitsspeichers.
Hatte aber noch nie den Fehler mit allocate memory.
Also wenn man nicht darauf schaut merkt man es nicht.

Ich hänge nachher mal noch nen Screen an.

Gesendet von meinem S60 mit Tapatalk

Also mein Testsystem2 (welches die Module bekommt bevor sie [evtl.] auf's Hauptsystem gehen) hatte einige Zeit (größer 3 Monate) nur alexa-fhem, Tradfri, Harmony und einige Notify, at, Dummy und zeigte KEINERLEI anstieg...

Aktuell teste ich das Unifi/UnifiClient-Modul und es steigt sehr, sehr, sehr, sehr leicht an...

Würde aber Unifi (und werde ich demnächst) ohne Bedenken auch auf das Hauptsystem nehmen...

Also es geht wohl auch (fast) komplett ohne Anstieg...

Daher ja die Idee mal zu untersuchen, was an den Modulen die definitiv Speicherlecks haben/verursachen, ob und wenn welche Gemeinsamkeiten diese Module aufweisen...
...ein Kandidat wäre das echodevice-Modul.

Ein anderer Kandidat war ja mal ein "spezielles DOIF" von Damian...

Gruß, Joachim

[Brice]

Hier läuft es nach Schwierigkeiten im März 2018 seither "einigermaßen", alle 3 bis 4 Wochen müsste ich FHEM neu starten, wenn in dieser Zeit nicht ein shutdown/restart aufgrund update gemacht wird. Betrifft nur mein Produktivsystem.

Ich schicke täglich über Telegram eine Nachricht über den aktuellen Zustand, um dann bei Bedarf ein shutdow/restart durchzuführen.

[maci]

Meine System läuft anscheinend wieder.
Ich habe nach der Logfileanalyse gesehen, dass vor und nach der Memorymeldung häufig viele Feezemon einträge waren.
Ich habe den Freezemon installiert, dann aber gesehen, dass haufenweise Meldungen kommen, die alle owserverabfragen betreffen.
Ich hatte ihn dann deaktiviert.

Ich habe Freezemon komplett deinstalliert, nun läuft mein System mit 272MB Speicherauslastung seit mehr als 24 Std. Kein langsamer Anstieg mehr, nur immer wieder ein paar Ausschläge auf etwas über 300MB. Aber dann gleich wieder normal.

Ich hatte das ganze jetzt 2 mal wo sich dann Fhem einfach beendet hat nach der Cannot allocate memory Meldung.
Erst ein kompletter Reboot half, da Fhem nicht gestartet ist, weil angeblich der Port 8083 belegt war.
Jedenfalls war Freezemon nach dem ersten Reboot aktiv. Dann wurde der Speicher immer voller, bis nach 26 Std wieder das Limit erreicht war.
Nach dem 2. Auftreten habe ich zuerst, weil fast Mitternacht, den Fhem-Server nur neugestartet.
Gestern mm Morgen war der Speicher mit fast 600MB schon wieder ziemlich ausgelastet.
Habe dann das Log durchgesehen und nach den vielen Meldungen von Freezemon, auch rund um die Abstürze, beschlossen, Feezemon zu entfernen. Dann das System nochmal neu gestartet, das war um ca. 9:30 Uhr. Seit dem ist Ruhe.