Archiv wächst bei jedem Neustart rasant

Hallo,
seit der 5.5 wächst mein Archiv bei jedem restart vom Symcondienst auf einem Raspberry Pi

ich überwache die Archivgröße mit folgendem Script (Event alle 15 min):


<?
set_time_limit(180);
function DirectorySize($directory)
{
    $size = 0;
    $files= glob($directory.'/*');
    foreach($files as $path)
    {
        is_file($path) && $size += filesize($path);
        is_dir($path) && $size += DirectorySize($path);
    }
    return floatval($size);
} 
function DirectorySizeMB($directory)
{
    $rc = floatval (DirectorySize($directory) / floatval(1024.0 * 1024.0));
    return $rc;
}

$value = DirectorySizeMB('/var/lib/symcon/db/');
SetValueFloat(36190, $value);

die Größe war bei mir immer relativ gleich mit ca. 20-30 MB, da ich fast alle alten Daten nach 3-12 Monaten wieder lösche (abhängig vom Variablenprofil).

Seit dem Update auf 5.5 habe ich mit jedem Neustart vom Symcon einen großen Sprung beim belegten Speicher.
(1x um ca. 6 Uhr wird gesichert. cron-job: Symcon wird beendet, die Daten wegkopiert und dann wieder gestartet). Da tritt der Sprung auf. Der letzte große Sprung im Chart ist von 3x testweise restart des Symcon-Dienstes.

hier die Verzeichnisinfo:
vor Neustart
nach Restart.png

nach Neustart:
bevor Restart.png

es schaut so aus, als ob die berechneten Daten der Datenpunkte in die Day/Month/Year Dateien immer angehängt werden und nicht die Datei überschreiben/ersetzen.

liebe Grüße
Wolfgang

Hallo,
was mir noch aufgefallen ist:
wenn man das ganze Archiv komplett neu reaggregiert, dann werden die Dateien korrekt neu geschrieben und die Filegröße passt auch wieder.
lg
Wolfgang

Ich habe gerade nochmal geschaut. Ich konnte Probleme nachstellen, wenn in der Aggregation fehlerhafte Zeilen waren. Das sollte bei dir allerdings nicht möglich sein, da du ja bereits reaggregiert hast. Kannst du mir ein vollständiges Backup per Mail an office@symcon.de schicken? Denn schaue ich mir einmal an, was bei dir schiefgeht.

Hallo Dr. Niels,

ich habe 2 Scripte, welche an den Archivdaten Änderungen vornehmen (neu eintragen oder löschen).

ich lösche ältere Daten immer mit folgendem Script (nur kurzer ausschnitt), sollte aber alles erklären.


    $result =  AC_DeleteVariableData (32753, $varID, $item["FirstTime"], $checkDate);
    if ($result > 0)
    {
        IPSLogger_Dbg($LoggerCategory, $dpInfo . "   Anzahl gelöschte Datensätze: " . $result);

        if (!AC_ReAggregateVariable(32753, $varID))
        {
            IPSLogger_Err($LoggerCategory, "Reaggregation FAILED for " . $dpInfo );
        }
    }

neue Daten kriege ich nur über die Anbindung an die Homematic und
einen Datenpunkt setzte ich so: (stündliche Langzeitdaten (Temperatur) von Wetterstation).


<?php

$id = 48029;
$ziel = 25695;

$startzeit = time() - 2*60*60;  // 2 Stunden zurück
$endzeit = $startzeit + 60*60;

$werte = AC_GetAggregatedValues(32753,$id,0 /* stündliche Werte */, $startzeit,$endzeit,1);  // nur 1 Wert

$wert = round($werte[0]['Avg'],1);
$timeStamp = $werte[0]['TimeStamp'] + 30*60;

// nicht verwenden, sonst hat der Datenpunkt einen falschen Zeitstempel
//SetValueFloat($ziel,$wert);

// direkt ins Archiv eintragen
AC_AddLoggedValues(32753, $ziel, [
  [
    'TimeStamp' => $timeStamp,
    'Value' => $wert
  ]
]);

AC_ReAggregateVariable (32753, $ziel);

die Backups habe ich geschickt.

lg
Wolfgang

Ich habe das Backup gerade mal bei mir eingespielt. Ich glaube du hast keine vollständige Reaggregation durchgeführt. Ist da vielleicht etwas schiefgegangen? Nachdem ich das gemacht habe, funktioniert der Neustart wunderbar. Du hattest in deinen Daten übrigens auch das gleiche Verhalten, was ich schon bei meinen existierenden Daten beobachtet habe.

Hallo Dr. Niels,

ich kann das jetzt bei mir auch nicht mehr nachstellen.

ich habe aber immer bei einer kompletten Reaggregation das Archiv geöffnet und dann „alle Reaggregieren“ rechts oben ausgewählt.

Der Effekt sollte mit der Datensicherung von gestern (2020_11_08__06_16_12) reproduzierbar sein. Hier hatte ich einige Tage die Reaggregation nicht gemacht.

Ich habe heute auch mal mein Datenlösch-Programm über alle Archiv-Variablen drüberlaufen lassen.
(Script ID: 38873 im Backup, 1 Aufruf behandelt einen Datenpunkt)

Wenn ich danach ins Archiv einsteige, kommt die Meldung:
2020-11-09 14_33_49-PS-Symcon — IP-Symcon Verwaltungskonsole.png

Obwohl ich im Script immer ein AC_ReAggregateVariable mache, sobald Daten gelöscht wurden.

das ist mir bei der Version 5.4 so auch nie aufgefallen. Dieses Cleanup-Script habe ich seit ca. 5 Monaten im Einsatz. Bis zur 5.4 ohne Probleme.

liebe Grüße
Wolfgang

Hat sich vielleicht bei deinen Daten etwas geändert? Daten löschen setzt die Aggregation immer auf ungültig, unabhängig von der Anzahl der gelöschten Datensätze. Sprich, bei 0 Datensätzen wird es ungültig, du reaggregierst aber nicht.

Hallo,
OK. d.h. wenn keine Daten im Datenpunkt gelöscht wurden, ist dann das Archiv ungültig?

ich werde den Code mal testweise wie folgt ändern.


    $result =  AC_DeleteVariableData (32753, $varID, $item["FirstTime"], $checkDate);
    //  if ($result > 0)
    //{
        IPSLogger_Dbg($LoggerCategory, $dpInfo . "   Anzahl gelöschte Datensätze: " . $result);

        if (!AC_ReAggregateVariable(32753, $varID))
        {
            IPSLogger_Err($LoggerCategory, "Reaggregation FAILED for " . $dpInfo );
        }
    //} 

vielleicht ist dann das Problem weg.
ich werde das heute Abend testen. wenn das Problem morgen bei der Datensicherung wieder auftritt, melde ich mich.

PS: wenn AC_DeleteVariableData keine Daten löscht (rc = 0), dann ist ein invalides Archiv ein nicht erwarteter Zustand.

liebe Grüße
Wolfgang

Hallo Dr. Niels,
die Änderungen haben funktioniert. d.h. das AC_DeleteVariableData war das Problem, wenn man danach nicht sofort ein AC_ReAggregateVariable macht.

hier der Screenshot von heute. (Restart vom Symcon-Dienst um 6:15):


lg
Wolfgang

Super! Bei AC_DeleteVariableData hast du recht. Wir haben gar nicht dokumentiert, dass die Aggregation danach ungültig wird. Das bessern wir nach!