Autor Thema: Kontinuierliches Speicherwachstum von FHEM  (Gelesen 727 mal)

Offline pte

  • Jr. Member
  • **
  • Beiträge: 55
Kontinuierliches Speicherwachstum von FHEM
« am: 27 Juli 2017, 16:56:42 »
Ich stelle fest, dass meine FHEM Installation täglich mehr Speicher in Anspruch nimmt (täglich so um die 2...3%).
Über
{ use Data::Serializer }
{ my $ds = Data::Serializer->new();; join("\n", map { "$_:".length($ds->serialize($defs{$_})) } sort keys %defs) }
habe ich festgestellt, das z.B. meine HM-CC-RT-DN im Weather-Channel ständig mehr Speicher beanspruchen.
Per {Dumper($defs{VentilEGKueche_Weather})} stelle ich weiterhin fest, dass dieser Channel im hash ein array namens "CHANGED" enthält, welches eine große Anzahl von Einträgen enthält =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2017.07.27 16:40:07 =~=~=~=~=~=~=~=~=~=~=~=
{Dumper($defs{VentilEGKueche_Weather})}
{
  'READINGS' => {
                  'measured-temp' => {
                                       'TIME' => '2017-07-27 16:39:11',
                                       'VAL' => '20.7'
                                     },
                  'R-sign' => {
                                'TIME' => '2014-11-04 20:13:54',
                                'VAL' => 'off'
                              },
                  '.RegL_01.' => {
                                   'TIME' => '2016-03-19 11:37:39',
                                   'VAL' => '08:00 00:00'
                                 },
                  '.peerListRDate' => {
                                        'TIME' => '2016-03-19 11:37:38',
                                        'VAL' => '2016-03-19 11:37:38'
                                      },
                  'state' => {
                               'TIME' => '2017-07-27 16:39:11',
                               'VAL' => '20.7'
                             }
                },
  'DEF' => '28B89701',
  'NOTIFYDEV' => 'global',
  'helper' => {
                'tmpl' => {},
                'expert' => {
                              'tpl' => 0,
                              'def' => 1,
                              'raw' => 0,
                              'det' => 1
                            },
                'role' => {
                            'chn' => 1
                          }
              },
  'NR' => 1318,
  'CHANGEDWITHSTATE' => [],
  'NAME' => 'VentilEGKueche_Weather',
  'CFGFN' => 'EG.KU.cfg',
  'TYPE' => 'CUL_HM',
  'chanNo' => '01',
  'CHANGED' => [
                 'measured-temp: 22.6',
                 '22.6',
                 'measured-temp: 22.6',
                 '22.6',
                 'measured-temp: 22.6',
                 '22.6',
                 'measured-temp: 22.6',
                 '22.6',
                 'measured-temp: 22.6',
                 '22.6',
                 'measured-temp: 22.6',
                 '22.6',
                 'measured-temp: 22.6',
                 '22.6',
                 'measured-temp: 22.6',
                 '22.6',
                 'measured-temp: 22.6',
                 '22.6',

und so weiter. in wenigen Tagen an die 10.000 Stück.

Hat jemand eine Idee, woher diese entstehen?
Lichtenstein/Sa. grüßt den Rest der Welt

Offline pte

  • Jr. Member
  • **
  • Beiträge: 55
Antw:Kontinuierliches Speicherwachstum von FHEM
« Antwort #1 am: 28 Juli 2017, 08:49:51 »
scheine der Ursache näher zu kommen.
Die betroffenen Geräte (channel) haben bei mir ein "do_not_notify".
Meine Vermutung: Events werden in der Geräteinstanz in "CHANGED" zwischengespeichert und eigentlich durch den Ereignismanager von dort verarbeitet. Letzteres erfolgt bei "do_not_notify" nicht und damit füllt sich das Array.
Ob dies jetzt nur bei Homatic Geräten der Fall ist, oder auch andere Gerätetypen betrifft, habe ich noch nicht geprüft.

Kann Martin sich der Sache einmal annehmen?
Lichtenstein/Sa. grüßt den Rest der Welt

Offline martinp876

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9875
Antw:Kontinuierliches Speicherwachstum von FHEM
« Antwort #2 am: 30 Juli 2017, 18:14:32 »
ich kann erst einmal nicht erkennen, das CUL_HM hier etwas anderes macht.
Es muss Aufgabe des kernal sein die events zu löschen.
Rudi muss sich
DoTrigger($$@)
in fhem.p ansehen.

  my $max = int(@{$hash->{CHANGED}});
  return "" if(defined($attr{$dev}) && defined($attr{$dev}{do_not_notify}));
  my $now = TimeNow();
ist m.E.  falsch.

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 13591
  • Das "S" in "IoT" steht für "Security"
Antw:Kontinuierliches Speicherwachstum von FHEM
« Antwort #3 am: 30 Juli 2017, 18:37:41 »
  return "" if(defined($attr{$dev}) && defined($attr{$dev}{do_not_notify}));
Ein solches Konstrukt ist mir schon mehrfach in FHEM negativ aufgefallen.

Es ist völlig egal, welchen Wert das Attribut "do_not_notify" hat, es reicht schon seine bloße Existenz, um ggf. ein falsches Verhalten auszulösen.

Wenn ich "do_not_notify" auf 0 setze, erwarte ich, dass es abgeschaltet ist. Das sollte eigentlich für alle Attribute gelten, die als "Schalter" gedacht sind. Nur weil ein Schalter existiert, heißt das noch lange nicht, dass er immer angeschaltet ist.

-----------------------
Nächster Hamburg-Stammtisch: 15.12.2017

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 17262
Antw:Kontinuierliches Speicherwachstum von FHEM
« Antwort #4 am: 02 August 2017, 09:21:48 »
Habs gefixt, kurz getestet und eingecheckt, bitte um Feedback.
Und betateilchen hat auch Recht :)