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.
@Dr.Niels Ich wollte mal nachfragen, ob du mit dem Auszug aus dem Log was anfangen konntest, um das Problem einzugrenzen.
Glücklicherweise gab es die letzten Tage keine Abstürze/Neustarts mehr (warum auch immer), sodass das Thema gerade nicht mehr ganz so akut ist.
Falls da aber ein systematisches Problem besteht, würde ich es gerne lösen, bevor es wieder losgeht.
Beim Neustart füllt das Archiv die Aggregationen bis zu drei Tagen auf. Sollte mehr fehlen oder die Datei beschädigt sein, dann wird die Aggregation als fehlerhaft markiert, da eine Wiederherstellung potentiell länger dauern könnte. Wird ein Symcon korrekt heruntergefahren und neu gestartet, läuft das also alles super. Wenn jetzt aber mitten im Schreiben der Datei der Absturz kommt, dann ist diese natürlich beschädigt und führt zu den beschriebenen Problemen.
Wenn das bei dir häufiger vorkommt und du die eigentlichen Abstürze deines Systems nicht beheben kannst (was natürlich die optimale Lösung wäre), dann kannst du alternativ ein Start-Skript im Event Control anlegen, welches die Archivvariablen durchcheckt und ungültige reaggregiert.
Dass die Aggregation länger dauert, wenn viele Daten fehlen oder das Archiv korrupt ist, ist nachvollziehbar. Aber das Archiv ist doch eine zentrale Komponente des Systems. Wenn das fehlerhaft ist, muss doch davon ausgegangen werden, dass es zu diversen Problemen kommt. Ist es da wirklich sinnvoll, das quasi stillschweigend (mit einem Eintrag im Log) zu ignorieren und so zu tun als ob alles in Ordnung sei?
Natürlich macht das Archiv selten Probleme. Ich hatte bisher ja auch nie welche, selbst wenn der Dienst hart abgeschmiert ist. Warum das bei den letzten Abstürzen anders war, weiß ich nicht. Aber wenn es doch zu Problemen kommt, kriegt man es erst durch Zufall raus, wenn wie bei mir plötzlich ein merkwürdiges Verhalten an der ein oder anderen Stelle auftritt und man sich dann auf Fehlersuche begibt.
Wäre das nicht ein Fall für einen Spezialschalter, dass man auf Wunsch sicherstellen kann, dass IPS das Archiv von alleine repariert, wenn es kaputt ist?
Klar will ich die Ursache für die Abstürze finden und beheben. Seit zwei Wochen ist komischerweise auch wieder Ruhe. Da habe ich glaube ich auf die neuste Stable aktualisiert.
Das mit dem Überprüfen des Archivs per Skript ist eine gute Idee. Ich frage mich nur, wie ich das mache. Gibt es irgendeine Funktion, mit der ich überprüfen kann, ob die Aggregation fehlerhaft ist? Es gibt ja AC_GetLoggingStatus() und AC_GetAggregationVariables(), aber ich weiß nicht, ob die eine fehlerhafte Aggregation erkennen können.
Einfach stumpf bei jedem Start sämtliche Variablen neu zu aggregieren ist ja nicht wirklich zielführend. Dann dauert ja jeder Start 10 Minuten.
Aber wenn IPS beim Start offensichtlich feststellen kann, dass die Aggregation einzelner Variablen kaputt ist, dann gibt es doch sicher eine Funktion dafür, die ich nutzen kann, oder?
AC_GetAggregationVariables ist dein Freund. Da wird die Info zu allen geloggten Variablen ausgegeben. Und eines der Felder sollte „Valid“ (oder „Invalid“) sein, das möchtest du dann prüfen.