Programm wird mit Laufzeit immer langsamer

[norwegen60]

Hallo zusammen,

ich weiß, dass ich hier eine ziemlich offen Frage stelle, aber ich weiß im Moment nicht so recht wo ich ansetzen soll.

Ich habe eine Anwednung die während der Laufzeit per RS232 Daten von einem Gerät abfragt, in die Datenbank schreibt, laufende Messergebnisse in zwei Charts darstellt und ein Teil der Daten in einem VirtualStringTree darstellt.
Nun besteht das Problem, dass die Anwendung nach 2 Tagen Laufzeit 2..3 s benötigt um z.B. nach Klick auf einen Button Daten per RS232 abzufragen. Nach dem Click erscheint die Windows-Sanduhr und 2..3 sec später sieht man die Daten am Splitterkabel, das ich zu Überwachungszwecken an die RS232 gehängt habe. Die Antwortzeit des Geräts selber liegt im ms-Bereich. Nach 4 Tagen Laufzeit sind es schon 5..6 s. Das Öffnen des Explorers geschieht normal. Es ist nur mein Programm, das langsamer wird

• Alle 5s werden Temperatur, Drehzahl und Status abgefragt.
• Alle 2 Minuten werden diese in einem Chart dargestellt und in DB geschrieben.
• Alle 60 Minuten werden 8 Messwerte erfasst. d.h. nach 2 Tagen hat man 48 solcher Messpunkte. Es sind also keine großen Datenmengen, die da anfallen.

• Zu Testzwecken habe ich den 60 Min-Intervall auf 4Min verringert. D.h. jetzt sind die Messungen nach 4h abgearbeitet => Kein Problem mit der Laufzeit => Es liegt wohl nicht daran, dass die Messpunkte ein Datenloch erzeugen
• Ich habe die 2 Minuten logs abgeschalten => Nach 2 Tagen ist Anwendung wieder langsam => Es liegt wohl auch nicht am Log der 2-Minuten Daten
• Ich habe die Darstellung in den Charts deaktiviert => Keine Verbesserung
• Ich habe den Speicherverlauf geloggt. GetMemSpace erhöht sich nach 2.5 Tagen von 26'100 auf 26'327 kByte und M.dwAvailVirtual verringert sich von 1'582'312 auf 1'576'936 kByte => Erscheint mir auch nicht auffällig

Delphi-Quellcode:

function GetMemSpace: Integer;
// *****************************************************************************************************************************************
// Emittelt den Speicherbedarf der aktuellen Anwendung
var
  State: TMemoryManagerState;
  i: Integer;
begin
  GetMemoryManagerState(State);
  Result := 0;
  for i := 0 to high(State.SmallBlockTypeStates) do
    Inc(Result, State.SmallBlockTypeStates[i].AllocatedBlockCount * State.SmallBlockTypeStates[i].UseableBlockSize);
  Inc(Result, State.TotalAllocatedMediumBlockSize + State.TotalAllocatedLargeBlockSize);
end;
   
    // Alle 10 Minuten loggen (60 x 5s)
    if (Tag = (Tag div 12) * 12) then
    begin
      M.dwLength := SizeOf(M);
      GlobalMemoryStatus(M);
      GetLogger.Debug('MemLog', format('Used Memory = %11.0n / %14.0n kB', [GetMemSpace / 1024, M.dwAvailVirtual / 1024]));
    end;

Jetzt fehlt mir eine Idee was ich noch machen kann, um herauszufinden, warum die Anwendung im Verlauf von Tagen langsamer wird.

Programm ist mit Delphi XE erstellt

Danke für jede Hilfe
Gerd

[Der schöne Günther]

Zitat:

Zitat von norwegen60 (Beitrag 1485146)

Jetzt fehlt mir eine Idee was ich noch machen kann, um herauszufinden, warum die Anwendung im Verlauf von Tagen langsamer wird.

Einen "Profiler" verwenden, denn genau dafür wurden die erfunden. Gib einfach mal "Delphi Profiler" in die Suchmaschine deines Vertrauens ein, es gibt auch mehrere kostenlose Lösungen.

[hoika]

Hallo,

Zitat:

laufende Messergebnisse in zwei Charts darstellt und ein Teil der Daten in einem VirtualStringTree darstellt.

Dann nimm mal genau diesen Code testweise raus.
Oder stell nur die letzten 100 Mess-Ergebnisse dar.

Zweiter Ansatzpunkt ist die Datenbank.
Wohin speicherst Du die Mess-Ergebnisse?
Erfolgt die GUI-Darstellung nach:
1. neue Daten hintendran
oder
2. GUI verwerfen, alle Daten neu laden und anzeigen

[norwegen60]

Zitat:

Zitat von Der schöne Günther (Beitrag 1485149)

Einen "Profiler" verwenden, denn genau dafür wurden die erfunden. Gib einfach mal "Delphi Profiler" in die Suchmaschine deines Vertrauens ein, es gibt auch mehrere kostenlose Lösungen.

:oops: Ich benutze hin und wieder den MsSQL-Profiler. Habe aber nicht realisiert, dass es sowas "natürlich" auch für die Delphi-Seite gibt.

Danke

[norwegen60]

Zitat:

Zitat von hoika (Beitrag 1485152)

Dann nimm mal genau diesen Code testweise raus.
Oder stell nur die letzten 100 Mess-Ergebnisse dar.

Ich hatte ja geschrieben, dass ich genau das schon gemacht habe. Temperatur und Drehzahl, wo überhaupt mehr als 100 Messpunkte anfallen, habe ich ganz abgeschalten. Bei den Intervall-Messungen nur die Chartdarstellung. Beides ohne Erfolg.

Ich probiere den Compiler

[WiPhi]

Wenn du via TCP/IP direkt oder via VPN zugriff auf das System hast, wäre ggf. auch noch Remote-Debugging via PA-Server eine Möglichkeit, die Stelle zu finden, welche den Performance-Einbruch verursacht.

[himitsu]

Von AQTime ist beim Delphi eine kostenlose Edition dabei (GetIt), aber nur die etwas kränkliche IDE-Integration.

Die wichtigsten Funktionen loggen/messen kannst auch selber.
GetTickCount, TStopwatch oder Dergleichen.

Beim Befüllen von Komponenten sind so Dinge wie BeginUpdate bzw. DisableControls beachtet?

[norwegen60]

Zitat:

Zitat von himitsu (Beitrag 1485167)

Von AQTime ist beim Delphi eine kostenlose Edition dabei (GetIt), aber nur die etwas kränkliche IDE-Integration.

Die wichtigsten Funktionen loggen/nessen kannst auch selber.
GetTickCount, TStopwatch oder Dergleichen.

Beim Befüllen von Komponenten sind so Dinge wie BeginUpdate bzw. DisableControls beachtet?

Wie gesagt ist es Delphi XE. Da gabs noch kein GetIt. Ich schau mir gerade AsmProfiler und SamplingProfiler an.

BeginUpdate und DisableControls sind beachtet, sollten hier aber kaum eine Rolle spielen, da kaum Daten gemessen werden. Da gibt es andere Methoden wo alle 3 Minuten gemessen wird und das über 1.5 Tagen. Da merkt man kaum was.

[himitsu]

Damals gab es noch das "manuelle" GetIt und die Additional-DVDs :stupid:

https://edn.embarcadero.com/article/41296

[TomyN]

Ich würde auf den TVirtualStringList tippen.

'Primitives' Profiling geht auch mit TimeGetTime...

[norwegen60]

Zitat:

Zitat von TomyN (Beitrag 1485196)

'Primitives' Profiling geht auch mit TimeGetTime...

Dazu müsste ich aber wissen wo/was ich loggen will. Das Problem ist aber, dass die Anwendung nach zwei Tagen immer langsam ist. Zwischen zwei 30 Minuten-Intervallen läuft im Programm eigentlich nichts. Ein 1000ms Timer sorgt dafür, dass alle 5s Temp, Rpm, Status ebgefragt werden. Ich habe den Log dieser Daten deaktiviert, so dass keine Daten in DB, VST, Log oder Chart geschrieben werden. Und dann fragt der Timer noch ab, ob der nächste Messintervall erreicht ist (GetTickCount > NextIntervallCount)

Ich habe einen zusätzlichen Button auf die Oberffläche gesetzt, der einfach SendCommand('TPR') ausführt. Nach dem Klick geht die Sanduhr an und 2..5sec später sieht man am RS232-Sniffer, dass der Befehl raus geht. Die Antwort vom Gerät erfolgt unverzüglich.

[Delphi.Narium]

Bezüglich Timer:

Statt alle 1000ms zu fragen, ob ein Zeitpunkt erreicht ist, berechne vor dem Einschalten des Timers die Millisekunden, die noch bis zum nächsten "Ausführungszeitpunkt" zu vergehen haben, setze das Timerinterval auf diesen Wert und dann den Timer auf enabled.

Hab' ich mal in 'nem Dienst gemacht, der diverse Aufgaben zu unterschiedlichsten Zeitpunkten zu erledigen hatte. Je Aufgabe ein Timer, dessen Interval berechnet wurde und dann den Timer eingeschaltet. In der Timerroutine wird dann die entsprechende Aufgabe gestartet und anschließend die Millisekunden bis zum nächsten Zeitpunkt berechnet und als Wert für das Interval gesetzt und dann der Timer eingeschaltet. Die "Auflösungsgenauigkeit" hat bei diesem Vorgehen in einem Bereich von +/- maximal 1ms. Trifft letztlich genauer, als alle 1000ms zu schauen, ob ein Zeitpunkt erreicht ist und ist dadurch letztlich auch weniger aufwendig.

Zitat:

Nach dem Klick geht die Sanduhr an und 2..5sec später sieht man am RS232-Sniffer, dass der Befehl raus geht.

Was genau passiert denn letztlich hier. Meine erste Vermutung wäre, dass hier irgendwas genutzt wird, dass sich auf das Laufzeitverhalten auswirken kann. Aber was?

Hatte mal ein ähnliches Problem mit 'nem ollen Rechner, 'nem ollen Delphi und 'nem ollen Windows.
Damals war die Ursache, dass mit steigender Laufzeit immer mehr in der Auslagerungsdatei landete und Windows dauernd von dort die Daten wieder in den Speicher holte (auch wenn das in Taskmanager, ... und den dort sichtbaren Werten für Speicherverbrauch und Nutzung der Auslagerungsdatei nicht unbedingt sichtbar war). Keine Ahnung, ob es derartige Probleme heute auch noch gibt und Du eventuell mit einem Problem in dieser Richtung zu kämpfen hast. In der Wartezeit bitte mal schauen, ob sich im Taskmanager die Werte für "Seitenfehler" bzw. "Änderung der Seitenfehler" stark bewegen. Dann könnte es sich um ein Problem in dieser Richtung handeln. Wie sehen die Werte für E/A-Bytes lesen bzw. schreiben aus? In einem für die Anwendung angemessenen Rahmen?

[TomyN]

Oder einen Thread mit einem WaitableTimer, den könnte man sogar mit 'absoluten' Uhrzeiten füttern.
Kann es evtl. sein, dass Du jedesmal einen neuen Timer erstellst?
Ansonsten könnte ich mir noch vorstellen, dass z.B. das USB Interface in den Energiesparmodus geht, das würde aber den Zuwachs nicht erklären.

Ach ja, nicht vergessen, dass GetTickcount nach 42,3(?) Tagen einen 'wrap around' macht und dann GetTickCount > NextIntervallCount erstmal sehr lange false ergibt ..

[Sinspin]

Zitat:

Zitat von norwegen60 (Beitrag 1485201)

Ich habe einen zusätzlichen Button auf die Oberffläche gesetzt, der einfach SendCommand('TPR') ausführt. Nach dem Klick geht die Sanduhr an und 2..5sec später sieht man am RS232-Sniffer, dass der Befehl raus geht. Die Antwort vom Gerät erfolgt unverzüglich.

Und was findet da dann genau statt wenn der Button gedrückt wurde? Wie funktioniert das Senden des Befehls? Wie wird dann die Verbindung zum COM aufgemacht?
Wird die COM Verbindung offen gelassen (wiederverwendet) oder neu erstellt?
Ich hatte vor langer Zeit mal einen Fehler mit einem ESC POS interface. Freigeben und neu erstellen war da die Lösung.

Jeden kleinen Aufruf mit Zeitmessung zu verwanzen klingt zwar erstmal nach arbeit. Aber der Aufwand lohnt sich. Bei mir sind diese Tests dann permanent im Quelltext. Halt deaktiviert via Compilerschalter wenn ich es nicht brauche.
Durch die Zeitmessung sollte es dann auch keinen Tag dauern bis auffält wo es herkommt. An irgend einer Stelle werden die Abstände kontinuierlich zunehmen.

[himitsu]

Delphi-Quellcode:

+/- maximal 1ms

± 8

Sleep und Timer haben standardmäßig eine Auflösung von 15-16ms.
Aber egal ... das merkt eh niemand.

Zitat:

Jeden kleinen Aufruf mit Zeitmessung zu verwanzen klingt zwar erstmal nach arbeit.

Noch ein $IFDEF drumrum, dann kann man es deaktivieren/entfernen, wenn fertig, und hat es für später immernoch da.

[Delphi.Narium]

Zitat:

Zitat von himitsu (Beitrag 1485215)

Delphi-Quellcode:

+/- maximal 1ms

± 8

Sleep und Timer haben standardmäßig eine Auflösung von 15-16ms.
Aber egal ... das merkt eh niemand.

Zitat:

Jeden kleinen Aufruf mit Zeitmessung zu verwanzen klingt zwar erstmal nach arbeit.

Noch ein $IFDEF drumrum, dann kann man es deaktivieren/entfernen, wenn fertig, und hat es für später immernoch da.

Hab' ich mit meinem ollen Delphi 7 über Jahre mitprotokolliert, um zu erfahren, wie groß die Abweichung bei meiner Berechnung ist. War immer im Bereich von +/- 1ms. Daher meine Aussage.

Und ja: Bei hoher Auslastung eines Rechners, passt das nicht mehr so genau. Da bekommt ein Programm halt nicht unbedingt genug Zeit, um pünktlich zu arbeiten ;-)

Und selbst wenn die Abweichung bei 15 - 16 ms liegt, ist das immernoch genauer, als alle 1000ms zu gucken, wie spät es ist und dann ggfls. zu reagieren ;-)

[TomyN]

Ich hatte schon gröbere Abweichung. Aber mit TimerBeginPeriod kann man da schon optimieren.
Aber im Prinzip ist es schon richtig, dass es sich hier nicht um einen Präzisionstimer handelt.

[norwegen60]

Da kommen mehr Anregungen rein als ich auf die Schnelle umsetzen kann. Ein paar Anmerkungen

Das Programm ist recht umfangreich und ich habe es übergeben bekommen. Bin dabei Dinge zu optimieren aber das ist recht mühsam da Funktionen viel zu tief verschachtelt sind.

• Ein Teil der Funktionen die in dem SekundenTimer überwacht und angestoßen werden, ist schon umgestellt auf fixe Timer
• Statt GetTickCount wird PerformQueryCounter verwendet, was aber für diesen Teil keine Rolle spielt da auch 15ms vollkommen ausreichend sind. Auch das 49 Tage Problem ist in dem eigene GetTick abgefangen.
• Der USB-Sleep ist ausgeschlossen. Zum einen müsste dann ein zweiter Aufruf schneller gehen. Zum anderen tritt das Problem auch im Demo-Mode auf. Da wird gar nicht kommuniziert. Haben wir gerade erst festgestellt.
• Habe jetzt auch ein Button implementiert der einfach ein Label beschreibt. Um sicherzugehen, dass es nicht eine Funktion ist. Befehl geht zuerst in DLL und von dort per AsyncPro zuer seriellen.
• Problem wurde mittlerweile mit verschiedenen (1x Win7, 2x Win10) Rechnern nachvollzogen

[himitsu]

Erstmal fummelt die Delphi-IDE "heimlich" an den Systemtimings rum, so lange sie läuft. Da muß man manchmal bissl aufpassen.

Die Auflösung ist 15-16, Langzeit (für eine Messung/Intervall) ist sie recht stabil/zuverlässig.
Je mehr Intervalle ausgelöst wurden, summiert sich die Abweichung.



Aber um Millisekunden streitet man eh nicht, vorallem da Windows kein Echtzeitsystem ist, das Multithreading da auch noch mitspielt und es eh keine Präzisionstimer sind.

[Uwe Raabe]

Die Messdaten werden zwar in die Datenbank geschrieben, aber kann es sein, dass da noch irgendwo ein file-basiertes Logging mitläuft, bei dem die Logdatei immer erst gelesen, ergänzt und dann wieder geschrieben wird?

[norwegen60]

Zitat:

Zitat von Uwe Raabe (Beitrag 1485229)

Die Messdaten werden zwar in die Datenbank geschrieben, aber kann es sein, dass da noch irgendwo ein file-basiertes Logging mitläuft, bei dem die Logdatei immer erst gelesen, ergänzt und dann wieder geschrieben wird?

Ja, es werden über nlog Logs geschrieben. Das sind immer 24h Logs. Ich habe mal die Logs löschen lassen. Die beginnen dann wieder bei 0 Datensätzen. Das ändert aber nichts an dem Delay.

[Jasocul]

Das letzte mal, dass ich mit RS232 zu tun hatte, war zu Turbo-Pascal-Zeiten. Mal sehen, ob meine Erinnerungen dazu noch ausreichen, dein Problem einzugrenzen.

Du schreibst, dass alle 5 Sekunden Temperatur, Drehzahl und Status abgefragt werden. Ich nehme an, dass du dafür auch einen Timer verwendest. Wird dort die Verbindung jedesmal neu initialisiert oder greifst du auf eine bestehende Verbindung zu? Im zweiten Fall kann sich der günstige Abfragezeitpunkt ständig verschieben. Wenn ich mich richtig erinnere, kommt von der seriellen Schnittstelle ein Startbit und dann erst die Daten. Wird das Startbit verpasst, musst du warten, bis das nächste Startbit übertragen wird. Im Laufe der Zeit, kann es dann zu Verschiebungen kommen, die zu Wartezeiten führen. Wenn das die Ursache für dein Problem sein sollte, kann eine regelmäßige Initialisierung der Verbindung eine Verbesserung bringen.

Stoppst du den Timer, wenn die Daten abgefragt werden? Das wäre ziemlich wichtig, da der sonst vielleicht mehrfach während einer Abfrage ausgelöst würde. In dem Fall misst du vielleicht gar nicht die richtige Zeit bei der Auslösung des Timers oder es kommt zu anderen Problemen und die Verzögerung ist eine sekundäre Auswirkung.

Laufen auf dem Rechner noch andere Programme oder werden gelegentlich andere Programme dort gestartet? Ich halte es zwar für unwahrscheinlich, aber wenn du Charts und VirtualStringTree verwendest, benötigst du Hauptspeicher. Je nach Umfang, Laufzeit und Nutzung anderer Programme, kann der Hauptspeicher fragmentiert sein. Auch das kann dann zu Verzögerungen führen. Aber ich vermute den Fehler eher an einer anderen Stelle.

[TigerLilly]

Ich würde bei den Methoden auf oberster Ebene, die wiederkehjredn aufgerufen werden, beginnen und deren Laufzeit (Eintritt - Austritt) loggen. Dann hast du einen ersten Anhaltspunkt, wo die Zeit liegen bleibt, ohne allzuviel am Code ändern zu müssen und ohne viel mit Profilern etc herumtun zu müssen. Leg die Info so ab, dass du sie leicht visualisieren kannst. Hantle dich dann weiter in die Tiefe. Versuche, nach dem Ausschlußprinzip vorzugehen - je mehr Methoden du ausschließen kannst, desto besser. Aber: immer messen, nicht vermuten.

HTH

[Blup]

Stichwort Datenbankverbindung
Werden die DB-Transaktionen nach jedem Messvorgang tatsächlich alle geschlossen?
Wenn eine Transaktion über die gesamte Laufzeit des Programms offen bleibt und in der Zwischenzeit tausende von Datensätzen eingefügt werden, bekommt der Datenbankserver ein Problem. Die Beschreibung würde dazu passen.

[Jumpy]

Entsteht die Verzögerung vllt. in der DLL? In einem der Threads wurde eine dazwischen geschaltete DLL erwähnt, deswegen frag ich da nochmal nach?