90_at.pm Speicherverschwendung/-leck

Begonnen von noansi, 22 Juli 2026, 12:29:14

Vorheriges Thema - Nächstes Thema

noansi

Hallo Rudolf,

in at_SecondsTillTomorrow($) ist mir aufgefallen, dass die caching Variable %at_stt mit der Zeit anwächst, da

  my $dayHour = int($t/3600);mit jeder Stunde größer wird und mit
$at_stt{$dayHour} = 86400+($l1[8]-$l2[8])*3600;bei Nutzung (z.B. periodisches at mit gleichem Tageszeitstart) mindestens ein neuer Eintrag pro Tag bis maximal ein neuer Eintrag pro Stunde hinzu kommt.

Es sind aber mit Sommerzeitumstellung maximal die letzten 25 Einträge (bzw. Stunden) für die Funktion interessant, so weit ich es verstehe. Damit wächst der Speicherverbrauch langsam aber stetig mit unnötigen Daten.
Und mit größer werdendem Hash wird sicherlich auch der Lookup aufwändiger und der Cashing Vorteil nimmt ab.

Daher folgender Vorschlag zum Aufräumen von %at_stt:
sub
at_SecondsTillTomorrow($)  # 86400, if tomorrow is no DST change
{
  my $t = shift;
  my $dayHour = int($t/3600);

  if(!$at_stt{$dayHour}) {
    my @l1 = localtime($t);
    my @l2 = localtime($t+86400);
    $at_stt{$dayHour} = 86400+($l1[8]-$l2[8])*3600;

    my $lim = $dayHour - 25;
    for (keys %at_stt) {
      delete($at_stt{$_}) if ($_ < $lim); #noansi: cleanup memory
    }
  }

  return $at_stt{$dayHour};
}

Oder übersehe ich etwas?

Gruß, Ansgar.

rudolfkoenig

Vielen Dank, habs leicht modifiziert eingecheckt.

Modifiziert, weil ich einigermassen ueberzeugt bin, dass "<$dayHour-23" reicht.

noansi

#2
Hallo Rudolf,

danke für's übernehmen.

ZitatModifiziert, weil ich einigermassen ueberzeugt bin, dass "<$dayHour-23" reicht.

Hmm, noch nicht ganz, ohne es jetzt praktisch mit Zeitumstellerei an der Systemuhr im Kampf gegen NTP ausprobieren zu wollen. In diesem Kontext wird es aufgerufen:
  my $ot = $data{AT_TRIGGERTIME} ? $data{AT_TRIGGERTIME} : gettimeofday();
  $ot = int($ot) if(!$rel);     # No way to specify subseconds
...
    $nt += at_SecondsTillTomorrow($nt) if($ot >= $nt);  # Do it tomorrow...und die kreierte $nt kann mal eine Stunde früher oder eine Stunde später sein, je nach Richtung der Zeitumstellung. Kann also bei Wiederholung eines entsprechenden at bezogen auf einen Tag Stunde 0 bis 22 oder Stunde 0 bis 24 umfassen. Daher hatte ich mich für die 25 entschieden, damit das beabsichtigte Caching sicher klappt. Zumal das gettimeofday() nach der Berechnung der Schaltzeit ausgeführt wird, was ungünstig an einer Stundengrenze auch nochmal ein Zusatzstündchen für den Vergleich vor dem Aufruf erzeugen kann. FHEM+perl+system schaffen auf jedenfall immer mal wieder Verzögerungen > 1s.

Gruß, Ansgar.

rudolfkoenig

Meine Ueberlegung:
<$dayHour-23 bedeutet schonmal 24 Stundenwerte, wir haben ja auf Stunde gerundet.
Selbst an einem Tag mit der Zeitumstellung kann man nicht mehr als 24 unterschiedliche Stunden referenzieren.
Erzeugen kann man zwar einmal im Jahr 25, aber es geht um das referenzieren, um den Cache zu nutzen.