Moin,
das parallele Ausführen hat wirklich was gebracht - von 1 Min 30 auf 50 Sek 
Wenn man den Befehl aus der Konsole direkt per Skript ausführen könnte, dann wäre mein hier Warning: Another aggregation is already running - Seite 2 beschriebenes Anliegen perfekt gelöst 
Den Befehl bräuchte ich nur beim Start von IPS 
Gruß
Hans
Hallo
Die parallele Ausfuehrung hat sich bei mir auf unter 5 Minuten ausgewirkt . Respekt.
Jetzt kommt der Haken:
Im Log kommen so viele Meldungen gleichzeitig, dass sich zB ein Modul nicht gerade darueber freut.(permanent)
Das Syslog-Modul im Store von Demel42.
Error in Script C:\ProgramData\Symcon\modules.store\demel42.syslog\Syslog\module.php on Line 326
24.09.2020 17:52:03 | 41354 | MESSAGE | Server Socket | Schließe Verbindung…
24.09.2020 17:52:04 | 00000 | CUSTOM | PHP | Error: Error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 90262088 bytes)
Muessen die ganzen Meldungen wirklich sein?
Du kannst den Spezialschalter für den LogfileFilter verwenden, falls es dir zu viel ist
paresy
Hallo
Ja MessageQueueWatch hat die Meldungen reduziert.
Die Meldung vom Modul ist geblieben.
Schau ich mir mir morgen noch mal genauer an.
Der Fehler „Another aggregation is running“ sollte mittlerweile auch nur noch kommen, wenn du die gleiche Variable mehrfach aggregieren möchtest. Warum möchtest du den eigentlich bei jedem Start nutzen? Hast du noch ein Szenario in der die kontinuierliche Aggregation Fehler macht? Wenn ja, dann würde ich diesen gerne beheben Und dann musst du gar nicht mehr reaggregieren
Moin Dr.Niels,
falls deine Rückfrage an mich gerichtet war hier nochmals die Begründung
Wenn ich keine Reaggregation machen würde beim Neustart nach der Übertragung wären die Graphen fehlerhaft.
Da ich die Reaggregation per Skript ausführe musste ich bislang eine Pause von 5 s zwischen den Reaggregationen der Variablen machen. Nun geht das auch ohne Meldung mit einer Sekunde
Gruß
Hans
So lange du genügend RAM hast, kannst du quasi auch alle Aggregationen parallel starten. Ist zwar bei tausenden von Variablen nicht optimal, sollte aber trotzdem gehen
paresy
Moin,
das werde ich noch testen, danke für den Hinweis
Es gibt aber möglicherweise noch einen Fehler nach dem Umbau. Wenn man im Archiv mittels AC_DeleteVariableData / IPS_ApplyChanges Daten löscht und diese dann mit AC_SetLoggingStatus / SetAggregationType / IPS_ApplyChanges dem Archiv wieder zufügt wird die Anzahl der Datensätze nicht gelöscht. Auch ein erneutes Reaggregieren bringt keine Besserung, Klickt man auf die Anzeige sind aber korrekterweise keine Daten vorhanden, obwohl die csv-Daten noch vorhanden sind Fügt man später echte Daten wieder zu, dann ist die Anzahl doppelt so hoch wie sie eigentlich sein sollte.
Meine Vermutung ist, dass AC_DeleteVariableData die csv-Daten nicht löscht.
Gruß
Hans
Moin,
ich habe jetzt mal genauer geschaut und festgestellt, dass
$Anzahl = AC_DeleteVariableData(KID_ARCHIV, 40924, 0, 0);
echo "Es wurden $Anzahl Datensätze gelöscht
";
die Anzahl der angeblich gelöschten Datensätze korrekt ausgibt, aber in Wirklichkeit die csv-Dateien der Variablen 40924 in den unterhalb von db liegenden Ordnern mit den Jahren/Monaten erhalten bleiben. Das erklärt auch das beschriebene Verhalten, dass nach
AC_SetLoggingStatus(KID_ARCHIV, 40924, true);
AC_SetAggregationType(KID_ARCHIV, 40924, 1);
IPS_ApplyChanges(KID_ARCHIV);
die Datensätze alle wieder vorhanden sind 
Den Vorgang kann ich problemlos reproduzieren.
Ergänzung: Dies passiert auch, wenn ich die Daten im Archiv in der Pro Konsole lösche.
Es gibt die neue Funktion „Ignoriere geloggte Nullen und negative Werte“. Mit welchem Befehl wird dieser Schalter gesetzt?
Zu diesem Thema der Hinweis, dass dieser mit dem Logging erzeugte Wert in den seltenen Fällen stört, wenn man danach alte externe Daten zufügen will, da dann u. U. nicht die aufsteigende Reihenfolge eingehalten wird. Dies ist sicherlich nicht der Normalfall sollte aber vielleicht in der Dokumentation erwähnt werden. Ich bin darauf gekommen als ich alte Sportdaten neu übernommen habe.
Dieser 1. automatisch erzeugte Wert wird übrigens in der Pro Konsole nach einer Reaggregation erst dann angezeigt, wenn man das Archiv geschlossen und wieder neu geöffnet hat. Normalerweise wird nach einer Reaggregation aber die Anzahl der Datensätze sofort korrekt dargestellt.
Ansonsten ist die Reaggregation nun wirklich blitzschnell
Gruß
Hans
Moin,
da niemand das Problem bestätigt hat und beim manuellen Löschen des kompletten db-Ordners bei den Unterordnern seitens Windows beim Löschen nach Administrator Berechtigungen nachgefragt wird (UAC ist aus), obwohl ich als Administrator aktiv bin, frage ich mich, ob hier ein Berechtigungsproblem die Ursache sein könnte, dass die Daten in den Unterordnern nicht gelöscht werden. Die Ordner werden aber durch IPS automatisch angelegt und im Log ist kein Fehlerhinweis zu finden 
Solche Berechtigungsprobleme treten ja auch bei der Verwendung von IPS_Execute auf, Stichwort IPS läuft als lokales Systemkonto. Hat jemand eine Idee?
Gruß
Hans
Moin,
neben der Löschproblematik tritt beim Zufügen von Daten mit AC_AddLoggedValues dieser Fehler stochastisch auf.
Warning: boost::filesystem::remove: Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird: "C:\ProgramData\Symcon\db/2015/08/10064.csv" in C:\ProgramData\Symcon\scripts\39562.ips.php on line 1190
Warning: boost::filesystem::remove: Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird: "C:\ProgramData\Symcon\db/2015/08/27299.csv" in C:\ProgramData\Symcon\scripts\39562.ips.php on line 1190
Dieses Problem gab es hier IP-Symcon Community Forum schon einmal. In meinem Fall handelt es sich allerdings nur um 2532 Sätze die aufgeteilt zu 31 Variablen zugefügt werden sollen, wobei die 31 Variablen vorher nur einen Nullsatz erhalten, die den Start markieren.
Der Fehler mit dem Deadlock tritt nicht immer auf und betrifft - wenn er auftritt - dann immer andere Variablen
Gruß
Hans
Ich kann mir vorstellen, dass der Fehler kommt, wenn du gleichzeitig Daten liest und löschen möchtest. Ich vermute der wahrscheinliche Fall hier wird sein, dass du während des Archiv-Commits (jede Minute) die Dateien löschen möchtest, obwohl die gerade noch im Zugriff sind.
Hier müsste ich verhindern, dass das beides gleichzeitig passiert, dann sollte das fehlerfrei klappen. Besten Dank für den Fund!
Moin Dr.Niels,
nein, ich lösche keine Daten während des Zufügens Es handelt sich um historische Daten die ich neu aufbauen möchte. Das Problem tritt auch nur dann auf, wenn man viele Daten übernimmt und der Fehler ist stochastisch. Ich vermute, dass dieser Fehler stärker auftritt, wenn ich dies auf dem deutlich schwächeren Produktivsystem laufen lassen würde, was ich bislang aufgrund der Probleme nicht gemacht habe.
Wie sieht es denn mit dem Problem des Nichtlöschens von Daten in den Unterordnern aus - Post #47? Kannst du das mal bei euch testen? An der Stelle komme ich nicht weiter :eek:
Gruß
Hans
Passiert das jedes mal? Ich hatte das so verstanden, dass beide Fehler gelegentlich auftauchen. Dann würde halt bei beiden die gleiche Erklärung passen, dass du halt während das Archiv die neuen Daten schreibt halt diese nicht gleichzeitig modifizieren kannst und es zu Fehlern kommt. Wenn allerdings das Löschen nie funktioniert, dann ist das etwas anderes.
Moin,
nein, es sind 2 völlig getrennte Probleme.
Zum einen bitte mal testen, ob bei euch alle Daten einer Variablen auch komplett in allen Unterverzeichnissen auf einem Win System gelöscht werden. Dies funktioniert bei mir weder aus der Pro Konsole noch via AC_DeleteVariableData. Lediglich die Daten direkt unter db werden gelöscht. In den Jahren und Monaten bleiben die Daten erhalten. Dieser Fehler tritt immer auf und kann von mir leicht reproduziert werden.
Das 2. Problem ist das Hinzufügen von Datensätzen mittels AC_AddLoggedValues. Dieser Fehler tritt in stochastischer Weise auf und es scheint einen Zusammenhang mit der Anzahl der Datensätze zu geben. Eine Löschung findet zu diesem Zeitpunkt nicht statt.
Gruß
Hans
Moin Dr.Niels,
um auszuschließen, dass dieses Problem
nur auf dem Entwicklungssystem auftritt, habe ich es jetzt zusätzlich auf dem Produktivsystem getestet und musste feststellen, dass dort ebenfalls die Daten nicht vollständig gelöscht werden :eek:
Gruß
Hans
Auf welcher Version läuft denn dein Produktivsystem? Das sollte eigentlich ein 5.5-spezifischer Fehler sein. Den habe ich aber mittlerweile geortet und gefixt. Am Hinzufügen von Werten bin ich noch dran. Das versuche ich noch bei mir nachzustellen. Habe jetzt einige Variablen, die sekündlich einen neuen Wert hinzugefügt bekommen.
Moin,
das läuft ebenfalls auf V 5.5 IP-Symcon 5.5, Windows x64, 23.09.2020, 0f21cdf0d4c0. Gut zu lesen, dass das Problem erkannt worden ist da ich schon Zweifel hatte, ob es an meinen Systemen liegt
Gruß
Hans
Moin Dr.Niels,
hier noch ein Hinweis.
Ich vermute mal, dass du die Variablen normal loggst. Bei mir tritt das Problem dann auf, wenn ich eine Textdatei mit 2032 Datensätzen und 31 verschiedenen Variablen per Skript mittels AC_AddLoggedValues hinzufüge. Das db Verzeichnis samt Unterverzeichnissen lösche ich komplett, dann wird via Pro Konsole reaggregiert und danach erfolgt die Datenübernahme per Skript. Die Werte in der Datei sind dabei immer aufsteigend im zeitlichen Sinne.
Gruß
Hans
Kannst du mir so eine Textdatei vielleicht einfach mal per Mail schicken? Dann probiere ich es einfach mal damit