RAM-Speicherüberlauf mit HMCCU und RaspberryMatic

[ToM_ToM]

Hallo Zusammen,

ich bin vor rund 5 Monaten von der CCU2 auf einen Pi3 mit RaspberryMatic (3.45.5.20190330) umgestiegen. Zeitgleich hatte ich meinen BananaPi auf dem FHEM läuft, von Bananian auf Armbian umgeswitcht und ein paar andere Änderungen vorgenommen.
Daraufhin lief immer Arbeitsspeicher voll und war nach ca. 5 Tagen aufgebraucht (bei Start von FHEM ca. 400 MB, nach 5 Tagen 980 MB). Nun habe ich die letzten Monate Fehlersuche betrieben indem ich einzelne Module abgeschaltet (disabled) oder gelöscht habe.
Ergebnis: Nachdem ich das Device HMCCU aus FHEM gelöscht habe, läuft der Speicher nicht mehr voll. Vor dem Umstieg auf RaspberryMatic hatte ich diese Probleme auch nicht. Kann jemand die Erfahrung bestätigen?

Anbei ein List von der HMCCU (ohne die einzelnen Devices)

Code Auswählen Erweitern


Internals:
   CCUNum     1
   Clients    :HMCCUDEV:HMCCUCHN:HMCCURPC:HMCCURPCPROC:
   DEF        192.168.178.42
   FUUID      5c445dea-f33f-4bf2-9289-e18e67cc0003b511
   FVERSION   88_HMCCU.pm:v4.3.15-s19373/2019-05-11
   NAME       CCU2
   NOTIFYDEV  global,TYPE=(HMCCU|HMCCUDEV|HMCCUCHN)
   NR         161
   NTFY_ORDER 50-CCU2
   RPCState   running
   STATE      OK,running
   TYPE       HMCCU
   ccuaddr    BidCoS-RF
   ccuchannels 495
   ccudevices 45
   ccuif      BidCos-RF
   ccuinterfaces BidCos-RF,VirtualDevices,HmIP-RF,BidCos-Wired
   ccuip      192.168.178.42
   ccuname    Zentrale ccu2
   ccustate   active
   ccutype    CCU2/3
   host       192.168.178.42
   prot       http
   version    4.3.015
   READINGS:
     2019-05-17 15:34:31   count_channels  495
     2019-05-17 15:34:31   count_devices   45
     2019-05-17 15:34:31   count_groups    0
     2019-05-17 15:34:31   count_interfaces 4
     2019-05-17 15:34:31   count_programs  81
     2019-05-17 15:37:03   rpcstate        running
     2019-05-17 15:37:12   state           OK
   hmccu:
     defInterface BidCos-RF
     defPort    2001
     evtime     0
     evtimeout  0
     rpccount   0
     rpcports   2001,2000
     updatetime 0
     adr:

     HIER WÜRDEN DIE EINZELNEN DEVICES STEHEN

     rpc:
Attributes:
   ccudef-readingfilter .*
   ccudef-readingformat datapoint
   ccuflags   procrpc,nonBlocking
   devStateIcon (OK|Initialized):10px-kreis-gruen Error:10px-kreis-rot
   event-on-change-reading .*
   icon       rc_HOME
   room       System->Fhem
   rpcinterfaces BidCos-RF,BidCos-Wired
   rpcport    2001,2000
   rpcserver  on
   stateFormat state,rpcstate
   stripchar  :
   stripnumber 1
   verbose    2


VG, Thomas

[amenomade]

Dein Thread lieber ins Homematic Subforum verschieben. Dort sind die Spezialisten

[MadMax-FHEM]

Oder in einem der "Speicher läuft voll" Threads "anhängen"...

Bei mir habe ich ähnliches mit dem Modul 37_echodevice...

Gruß, Joachim

[zap]

Es liegt sehr wahrscheinlich nicht an HMCCU sondern an einem Memoryleak im Perl Interpreter. Siehe dazu auch die entsprechenden Threads. Jeder meint, ein anderes Modul als Ursache identifiziert zu haben. Letztlich ist es aber die Perl Version.

Zb https://forum.fhem.de/index.php/topic,84372.0.html

[ToM_ToM]

Hi zap,

die Beiträge mit den Modulen und Perl-Version hatte ich auch gelesen. Allerdings habe ich die exakt gleiche Perl-Version auf 5 Systemen laufen. Bei 3 davon läuft es über Monate hinweg ohne Probleme. Bei den Zweien wo ich mit der RaspberryMatic arbeite, läuft der Speicher voll. Das ist das was ich merkwürdig finde. Hatte vor dem Umstie auf RaspberryMatic auch HMCCU mit der selben Perl-Version über Monate stabil laufen (da allerdings via Bananian statt Armbian).
Habe jetzt auf dem System wo der Fehler auftritt die fhem.cfg komplett bereinigt und keine Devices mehr drin und lasse es mal so ein paar Tage laufen um zu schauen ob sich dann trotzdem der Speicher erhöht.