Archivumbau zur 5.5

Moin,

ich habe dir bereits etwas gebastelt und an eure Mailadresse gesendet :wink:

Gruß
Hans

Moin Dr.Niels,

das Problem mit dem Löschen der Daten aus den db-Unterverzeichnissen ist bei mir jetzt mit IP-Symcon 5.5, Windows x64, 06.10.2020, 6729d5c28e87 ok :wink:

Dieses Problem

tritt noch immer auf. Teste doch mal mit der Datei Training_wiederholen_sort.txt. Mit der Datei habe ich noch eine Fehlermeldung bekommen.

Nachtrag: Kann es sein, dass das Archiv in der Konsole geschlossen sein muss?

Gruß
Hans

Das Archiv blockt jetzt eigentlich sauber parallele Zugriffe auf die Dateien. Ich konnte das bei mir leider nicht nachstellen, daher musste ich „blind“ fixen, aber da dürfte nichts mehr durchkommen. Hast du die Datei vielleicht sonst irgendwie geöffnet oder schreibgeschützt oder dergleichen?

Moin Dr.Niels,

es gibt keine Probleme mit den Dateien und es ist auch wiederum so, dass der Fehler nicht immer auftritt. Die zeitlichen Rahmenbedingungen der Abläufe scheinen dabei relevant zu sein. Es sind auch immer andere Variable betroffen.

Muss das Archiv in der Console geschlossen sein oder spielt das keine Rolle?

Gruß
Hans

Hallo,

ich wollte auch mal einen Bug melden, vielleicht wurde dieser schon gemeldet.
Bei mir ist so das ich mehrere Variablen archiviere als Zähler. Wird IPS neu gestartet werden die Graphen damit falsch dargestellt.
Quasi als ob die Variablen nicht als Zähle archiviert würden.

Gehe ich manuell ins Archiv dann auf alle reaggregieren, dann werden die Graphen richtig angezeigt.
Startet man IPS neu muss man wieder manuell reaggregieren.

Edit: gerade ausprobiert, IPS an aus und es war doch alles ok.
Hab auch den Server neu gestartet. Konnte es nicht nach stellen.

Eigentlich sollte an allen Stellen (kontinuierliche Aggregation, aufholen nach Neustart und Reaggregation) der Aggregationstyp beachtet werden. Ich würde dem jetzt erst einmal nicht nachgehen. Wenn das bei dir nochmal auftaucht oder (noch besser) du das nachstellen kannst, dann melde dich gerne!

@PC Oldie: Ich habe mal eine Version mit erweitertem Debug gebaut. Diese schreibt ins Log, wenn relevante Funktionen gestartet, in kritische Sektionen gehen und abschließen. Du kannst die ja mal installieren und bei einem Fehler mal ins Log schauen bzw. es mir schicken. Die Version findest du hier: https://apt.symcon.de/pool/symcon/win/symcon_5.5-90-feature-archive-debug_amd64.exe

Du verwendest Windows, oder? Ansonsten kann ich das natürlich auch für andere Plattformen bauen.

Moin,

nachstellen konnte ich jetzt ober genanntes verhalten nicht. Aber beim Wasserverbrauch war es wieder so.

Zeigte auf einmal am Mittwoch 80m verbrauch an. Wenn man aber auf eine Stunde anzeigen gegangen ist, zeigt die Grafik normales Verbrauch an. Nach reag wird gezeigt wie es sollte.

Vor reagg:

Und nach reagg:

Hatte so etwas bei anderen Graphen auch, vielleicht war das Problem bei letzteren Versionen und nach einem Update wurde es behoben und habe nur die Nachläufer.

Hallo,

ich habe heute über Portainer ein Update des Symcon gemacht.
Das Problem ist wieder da, Wasser in dem Fall ist geblieben.

So sieht es aus:

Gehe ich bei den Graphen auf Tag anzeigen kommt folgende Meldung:

Neu Reagg habe ich noch nicht gemacht

Hi zusammen,

hoffe meine Beobachtung/Problem passt hier her.

Seit dem Umbau habe ich auch Veränderungen bei den Graphen festgestellt. Es tauchen jetzt vermehrt „Null“-Werte (0) in der Darstellung der Graphen auf. Wenn man dann eine Reaggregation der Variable macht sind die graphen wieder korrekt.

Ich habe mal von meinem Füllstand Heizöl vorher und hinterher eine Screenshot gemacht!

Vorher

Nachher

Gruß Heiko

Könnt ihr das irgendwie nachstellen? Ich würde vermuten, das passiert irgendwie bei einem Neustart, typischerweise also bei einem Update. Ich konnte das allerdings noch nicht selbst nachstellen…

Kommen da eigentlich die Extremwerte hinzu und ist das Drumherum korrekt oder ist da mehr kaputt? Falls ihr das Nachstellen könnt bzw. mal wieder habt, könnt ihr mir mal eure Dateien mit den Rohwerten und den Aggregationsdaten der entsprechenden Variablen schicken? Bei den Rohwerten sollte sonst auch der aktuelle Monat ausreichen, falls das ein wenig länger in die Vergangenheit geht.

Und mal als Test: Wenn ihr das wieder habt, dann macht mal nach der Sicherung der entsprechenden Daten eine Reaggregation und startet IP-Symcon danach direkt neu. Es wäre interessant zu wissen, ob der Ausreißer dann wiederkommt

Moin Dr.Niels,

in der Pro Konsole wird im Tab Archiv jetzt nicht mehr die korrekte Größe neben der Anzahl der Datensätze angezeigt. Bei mir steht der Wert immer auf 44,95 MB. Auch eine Reaggregation und ein erneutes Aufrufen des Tabs bringen keine Änderung :wink:

Gruß
Hans

Wo steckt denn dort der Fehler? Sind einzelne Variablen falsch oder wird falsch aufsummiert? Du könntest die Gesamtgröße (laut Archivwerten) mit einem Miniskript berechnen:


$aggregationVariables = AC_GetAggregationVariables(46341, false);

$recordSize = 0;

foreach ($aggregationVariables as $aggregationVariable) {
    $recordSize += $aggregationVariable['RecordSize'];
}

var_dump($recordSize);

Entspricht die Ausgabe deiner Anzeige oder kommt dort etwas anderes hinaus?

Moin Dr.Niels,

der „Fehler“ ist nur das unterschiedliche Verhalten der Anzeige. Vor 5.5 war es so, dass, wenn nicht reaggregiert worden war, die Anzeige der Größe permanent stieg. Wenn da dann 700 MB oder mehr stand habe ich von Hand reaggregiert und die angezeigte Größe war wieder nur 45-50 MB, der Wert der auch korrekt ist.

Von daher war vermutlich die Anzeige vor 5.5 fehlerhaft. Dein Testskript deckt sich mit der Anzeige - von daher alles ok :loveips:

Gruß
Hans

Ja, vorher gab es einen Fehler, dass unter gewissen Umständen die Zahlen deutlich schneller stiegen als sie es sollten. Der ist mittlerweile behoben.

Moin Dr.Niels,

ja, das habe ich gemeint :slight_smile:

In IP-Symcon 5.5, Windows x64, 14.10.2020, c0da18ff7753 ist der Fehler mit dem Deadlock noch vorhanden. Paresy schreibt im Changelog, dass Symcon u. U. abgestürzt sei. Dies ist bei mir allerdings nicht passiert.

Gruß
Hans

@PC Oldie: Wie äußert sich bei dir der Fehler? Kannst du ihn provozieren?

paresy

Moin paresy,

ist umfänglich in den Posts beschrieben :wink:

Ausserdem hat Niels meine Daten zum Test erhalten. Das Problem ist, dass er das auf seinem Rechner nicht nachvollziehen kann :mad: Er hat auch Logs mit erweitertem Debug von mir bekommen.

Vorab: ich bin nur darauf gekommen, weil ich meine alten Sportdaten nochmals mit AC_AddLoggedValues komplett neu übernhemen wollte. In der Vergangenheit habe ich immer die csv-Dateien erzeugt. Leider tritt der Fehler stochastisch auf, mal betrifft es Variable xyz dann abc, dann jkl und abc und manchmal läuft es fehlerfrei durch :confused: Dies ist auch der Grund, warum ich die Daten nicht noch weiter untersucht habe, da die Testdatei ja immer identisch ist.

Gruß
Hans

Hallo, kann ich auch bestätigen, bei jedem Neustart von IPS ist mal die oder eine andere Zählervariable „falsch“ (zeigen dann immer einen sehr hohen Wert an). Nach dem reaggrgieren ist alles wieder OK bis zum nächsten Neustart. Aktuelle Testing Version.

Grüße Torsten

Kann ich ebenfalls bestätigen. Bereits seit Start des Archivumbaus.

Kann irgendjemand das halbwegs verlässlich nachstellen? Also passiert das bei nahezu jedem Neustart (auch wenn es verschiedene Variablen trifft)? Wenn ja, dann könnt ihr ja mal IP-Symcon beenden, eine Sicherung vom Archivordner machen und dann neu starten.

Dann wären die Daten der betroffenen Variable im Vorher/Nachher-Vergleich für mich sehr spannend, insbesondere die Aggregationsdateien. Zusätzlich noch die Rohdaten vom aktuellen Monat. Wenn mir das jemand schicken könnte, wäre das großartig und würde die Fehlersuche sicherlich gut voranbringen.

Ansonsten noch ein paar Fragen:

  • Betrifft der Fehler alle Aggregationsstufen oder nur manche?
  • Passiert das bei irgend jemanden, der nicht Windows benutzt?

@PC Oldie: Bei dem Deadlock-Fix ging es leider nicht um deinen Fehler, sondern um einen „echten“ Deadlock. Wurden Funktionen unglücklich gleichzeitig ausgeführt, konnte IP-Symcon abstürzen.