ich habe seit einigen Tagen das Problem, dass mein Server (Windows 11) scheinbar häufiger abstürzt bzw. neu startet.
Oftmals passiert das genau um Mitternacht, vereinzelt aber auch tagsüber.
Woran das liegt, konnte ich bisher noch nicht feststellen. Jedenfalls tritt das Phänomen erst seit kurzem auf.
Mich macht jedoch etwas stutzig, dass nach dem Neustart des IPS-Dienstes (nachdem der Server zuvor neu gestartet ist) jedes Mal sämtliche Variablen ihre Aggregation verlieren.
Mir fällt das immer erst auf, wenn ich zahlreiche Fehlermeldungen in IPS bekomme, weil irgendwelche Operationen auf dem Archiv nicht mehr funktionieren.
Gehe ich dann ins Archive Control, müssen sämtliche Variablen neu aggregiert werden. Vereinzelt sind es eine Handvoll, die noch ok sind. Merkwürdig finde ich das vor allem deswegen, weil ja nicht sämtliche Variablen permanent aktualisiert werden.
Hat jemand eine Idee, warum das so ist? Dieses Verhalten habe ich früher so nie festgetsellt, selbst wenn der IPS-Dienst mal nicht sauber beendet wurde. Die Variablen waren danach trotzdem noch in Ordnung. Von daher beschleicht mich der leise Verdacht, dass IPS vielleicht selbst für die Abstürze verantwortlich ist, auch wenn sich aus dem Event-Log leider nichts brauchbares an Infos ergibt.
IP-Symcon 8.0, Windows (amd64), 27.02.2025, 1564acf8dddb
Nee, da ist massig Platz. Daran kann es nicht liegen.
Ich verstehe halt nicht, wieso es immer fast alle Variablen betrifft. Wenn eine Variable nicht angefasst wird, dann dürfte sich an der Aggregation doch eigentlich nichts ändern. Wieso ist IPS dann nach dem Absturz plötzlich der Meinung, dass die alle neu aggregiert werden müssen? Scheint ja zu stimmen, denn die ganzen Funktionen, die auf aggregierte Daten zugreifen, laufen dann ja auch nicht mehr richtig.
Früher hätte ich ohne Probleme im laufenden Betrieb den Stecker vom Server ziehen können und IPS wäre nach dem Start ganz normal gelaufen, ohne dass irgendeine Variable Probleme gemacht hätte.
Die Daten werden nach dem Neustart auch alle brav weiter geloggt. Rohdaten sind also kein Problem. Nur die Aggregation ist dann plötzlich im Eimer.
Kannst du sonst mal die Logs nach so einem Neustart hier posten oder mir per PM schicken?
Prinzipiell ist für die Aggregation die Aktualisierungsrate der Variablen egal. Es wird für jede Stunde/Tag/… der aggregierte Wert gespeichert, auch wenn der potentiell über längere Zeit gleich bleibt. Wenn Symcon aus ist, dann werden die Stundenwerte natürlich nicht weitergeschrieben. Daher wird bei einem Start auch erst einmal „aufgeholt“, damit die aggregierten Werte für die Zeit in der Symcon aus war zur Verfügung stehen. Dabei werden eigentlich bis zu drei Tage aufgeholt. Sollte Symcon länger inaktiv sein, müssen alle Variablen reaggregiert werden. Aber das klingt bei dir ja nicht so, als wenn da drei Tage zwischen wären, daher wundert mich das Verhalten schon sehr…
OK, so war auch mein Verständnis, was die Funktionsweise des Archivs angeht.
Zwischen Absturz und Neustart liegen nur wenige Minuten. Daher ist das ja so seltsam.
Ich gucke mal, ob ich in den Logs was finde. Dauert aber ein wenig. Ich bin aktuell geschäftlich unterwegs und die Logs sind auch einige GB groß, weil ich die Variablenwerte alle logge. Da muss ich erst mal das passende mit einem Texteditor extrahieren, der mit so großen Dateien umgehen kann.
@Dr.Niels So, ich habe die Log-Files mal analysiert. Das Ganze verhält sich wie folgt:
Der Server stürzt irgendwann ab. In der Log-Datei sieht man dies daran, dass diese plötzlich mitten in einer Zeile abrupt endet. Also die letzte Zeile in der Log-Datei wird angefangen, aber nicht mehr vollendet.
Nichtmal eine Minute später startet der Dienst wieder und es wird eine neue Log-Datei erzeugt.
Das geht erst mal alles seinen gewohnten Gang. Er erkennt die Zeitzone, lädt sämtliche Komponenten etc.
Irgendwann kommt dann der interessante Teil. Das Archive Control generiert den Zeitstempel für Zeitversatzänderungen. Dann beginnt er die Variablen zu reaggregieren.
Es kommen einige wenige Meldungen Aktualisiere Aggregationsdaten für Variable… #12345.
Das meiste ist jedoch Invalid line in file 12345.hour.csv:
Es sieht also so aus, als wäre bei fast allen Variablen nach dem Absturz die Stunden-Aggregation kaputt. Aber scheinbar kriegt er sie ja nicht von alleine repariert. Erst wenn ich die Aggregation im Archive Control selbst starte, sind die Aggregationsdaten wieder valide.
Ich kann jetzt leider nicht nachvollziehen, wie so eine hour.csv im Fehlerfall aussieht. Da müsste ich ggf. beim nächsten Absturz mal einen Blick rein werfen, aber merkwürdig ist das schon. Wieso stellt er beim Start fest, dass die Daten kaputt sind, repariert sie aber durch die Aggregation nicht?
Sonst ist im Log eigentlich nichts auffälliges zu sehen. Danach läuft alles normal weiter bis auf die ganzen Skript-Fehler, die entstehen, weil das Archiv kaputt ist.