nach einigen Test habe ich bei mir den Übeltäter dafür gefunden.
Das ganze lief unter V1 fast 2 Jahre ohne Probleme.
Die Daten kommen von einem Mega8 und werden im Sekundentakt über die Comschnittstelle eingelesen laufen über Cutter und Registervariable und werden Script ausgewertet. Wenn ich die Comschnittstelle deaktiviere bleibt der Speicherverbrauch konstant bei ca. 59MB. Sobald aktiv steigt der Verbrauch in einem Tag auf ca. 124 MB an. Nach 3 Tagen sind es so um die 360 MB.
Hallo RWN,
Hallo Parsey,
ich erlaube mir, mich hier auch gleich wieder anzuhängen
… ich sende alle 2 Sekunden den Anforderungsrequest (5Byte) und erwarte dann den Response von 71Byte, diese Daten werden dann eben über das Script der RegisterVariable den Buffer hinzugefügt, normalerweise wird das Script für das empfangen der Daten (71byte) ==> 19mal aufgerufen = 18x4ms + 1x14ms (letzter Empfang dann wird auch gleich die Auswertung der Daten durchgeführt)
… in dieser Konstellation steigt eben bei einer 2 Sekundentaktung der Speicher um 10MB je Stunde
Als zweites Problem habe ich noch, wenn der RegVarBuffer über das Anforderungsscript zurückgesetzt (gelöscht) wird, dann kommt der Inhalt des Empfangsbuffers durcheinander nach ca. 2 Stunden durcheinander ==> es kommen im Buffer nicht mehr die Daten an, welche über das COM-Port gesendet wurden (Problem kann durch schliessen und wieder öffen des COM-Ports gelöst werden)
Ich vermute ein Speicherleck im RegisterVariable Modul gefunden zu haben. Gebt mir noch ein wenig Zeit, um es zu verifizieren. Dann wird es den Fix geben.
Hallo Parsey,
kann leider auch keine positive Rückmeldung geben
… habe jetzt seit 18:30 den Test laufen und der Speicher sieht gut aus steht nach 3 Stunden auf jedenfall noch unter 40MB, jedoch kommt es immer wieder zu Fehlermeldungen bzw. fehlerhalten Pufferinhalten (siehe Anhang - Meldungen der COM1)
… ich kann die neue DLL auch nur an der internen Schnittstelle des Rechners COM1 laufen lassen, den an der COM1 verhälten sich die Scriptaufrufe etwas anders als an der COM3 !!! ==> an der COM1 werden für die 71Byte normalerweise die RegVar-Scripts ca. 6 mal getriggert !! (siehe Anhang) an der COM3 (USB-COM-Adpater von C* mit Handshakeleitungen) werden die Scripts 19x getriggert (siehe Anhang vorheriges Posting) und es kommt nach ca. 30 Sekunden der Bufferinhalt durcheinander (Bufferinhalt entspricht nicht den Daten welche über das COM-Port geschickt wurden)
… verwende ich wieder die alte DLL für die COM3, ist wieder alles in Ordnung und es läuft sicher wieder 2-3 Stunden
Ok. Neuer Versuch. Habe noch ein paar Änderungen vorgenommen und ein wenig mehr „Stress-Getestet“, um zu sehen, ob Pakete verdreht/verschluckt werden. Bis jetzt funktioniert es bei mir aber gut.
… irgendwie bewirkt die ECHO - Ausgabe vor dem „neuen Request“ aber in Verbindung mit dem USB-COM-Port wunder, es kommt auf einmal zuviel weniger Pufferfehlern ==> daher meine Frage, löst das ECHO eine Verzögerung aus, welche irgendwie das Puffer schreiben (der beiden Scripte ==> 1. will löschen / 2. will Daten im Puffer hinzufügen) positv beeinflusst ==> Habe mir auch schon überlegt nach den Löschen eine WHILE-Schleife einzubauen, welche prüft ob der Puffer wirklich leer ist bevor der neue Request abgesetzt wird ?? (Glaube zwar das es keinen positven Erfolg bringt wird) ==> gibts dafür eine andere Möglichkeit eine Art SEMAPHORE zwischen die beiden Scripts zu bekommen ??
Was mir auch mit den beiden neuen DLLs aufgefallen ist (verstärkt mit der heutigen), das man beim Arbeiten in der Konsole vorhältnissmässig oft, das POPUP „Socket-Fehler #10048 Die Adresse ist bereits in Gebrauch“ bekommt, wenn man ein Objekt öffnen will (z.B. IO-Instanz des COM-Ports / Script der RegVariable)
zuerst dachte ich, sieht gut aus. Der Speicher stand heute Morgen bei 54MB.
Leider ist das System heute Nacht um 3:24 Uhr ohne ersichtlichen Grund stehen geblieben. Dienst beenden ging nicht nur über Taskmanager killen.
Neu gestartet, 10min später ging wieder nichts. Das war das erste mal in fast 2,5 Jahren das bei mir das System ohne ersichtlichen Grund stehen blieb.
Ich hab ja auch das „Speicherproblem“ und muss sagen seit ich gestern die dll von paresy installiert habe hab ich fast keinen Anstieg mehr. Seit 18 Stunden ca. 67mb Speicher bzw 58mb virtuellem Speicher. Sonst ist der Speicherbedarf in der Zeit immer um 300mb und mehr gestiegen.
Bin bis jetzt also zufrieden, habe auch keine Fehler im Log gefunden, geschweige denn einen absturz wie von RWN berichtet.
Hallo,
habe vorhin einen Sempahore über eine IPS-Variable eingebaut, damit die Scripts sich auf keinen Fall mehr in die Wege kommen können !!!
… seit dem habe ich auch keine „korrupten Daten“ mehr von USB_COM-Port , mir fällt auf das seit den „neuen DLLs“ sich eben das Auslesen des Buffers komisch verhält !!
Wenn man sich das Debugfenster ansieht, werden die Daten „Receive“ in Millisekundentakt empfangen (so wie Sie eben über das COM-Port gesendet werden), jedoch dann das Buffer auslesen „Buffer“ dauert oft „ewig“ bis dann die Daten verarbeitet werden ==> Im meinen konkreten Fall liegen zwischen Datenempfang und das alle Daten im RegVarBuffer sind bis zu 11 Sekunden (Sriptlaufzeit 1-2ms)
… daher auch kein Wunder das sich die Scripts in die Wege gekommen sind !! ==> eigentlich müsste die Verarbeitung leicht innerhalb einer Sekunde fertig sein
@Horst:
mir waren die Befehle „IPS_SemaphoreEnter“ und „IPS_SemaphoreLeave“ bekannt, aber was bringen die mir wenn ich über Scriptgrenzenhinweg eine Verriegelung brauche (RegVar - Script wird meist >5 mal aufgerufen) und die Befehle aber innerhalb des Scriptes wieder aufgehoben werden müssen, ansonsten „Warning: Semaphore ‚LOGO_SEMAPHORE‘ was not released!“ und der Script wird fehlerhaft makiert
Hallo PARESY,
habe jetzt zwar keine Pufferprobleme mehr seit 17:30, jedoch ist IPS wie schon RWN beobachtet hat seit dem zweimal eingeschlafen !!!
… es wird nichteinmal mehr das Timerevent gestartet
Habe auch seit 19:00 das Anforderunginterval auf 10 Sekunden gestellt und einen Zähler eingerichtet welcher mir die Aufrufe zählt, wo es zu einer Kollision der Scripte gekommen währe ==> Habe so 4x das Ereigniss gehabt das der Bufferinhalt über 10 Sekunden zum auslesen benötigt hat (Zähle einfach die TimerEvents wenn der Semaphore noch sitzt)
Semaphore ist im Moment so programmiert ==> Es wird das Anforderungsscript abgebrochen wenn der Semaphore noch beim neuen Timerevent sitzt bzw. das Timerevent mehr als 10x durchlaufen wurde und der Semaphore immer noch sitzt wird eine Zwangslöschen des Semaphore durchgeführt (nächstes Timerevent setzt dann den Request ab)
Es muss sich irgendwo noch ein Deadlock Problem eingeschlichen haben. Meine Test-Cases scheinen noch nicht genügend komplex zu sein. Muss mir da noch etwas ausdenken, wie ich das gut simulieren kann. Das Geschwindigkeitsproblem werde ich mir ansehen.
Ist zwar schon ein bischen angestaubt der Thread, aber ich geb noch mal Feedback.
Bei mir läuft es jetzt. Speicher pendelt je nach Auslastung zwischen 45 und 55 MB. Alles im grünen Bereich.