Quelle hoher Prozessorauslastung ermitteln

[Sven M.]

Moin zusammen,
folgende Situation:
Ich entwickle derzeit eine Software, die bestimmte Messwerte erfasst und daraufhin bestimmte Parameter regelt. Diese Software soll bis zu 2 Monate am Stück laufen. Nun habe ich allerdings das Problem, dass anfangs alles einwandfrei funktioniert, mit steigender Laufzeit jedoch immer längere Perioden auftreten, die den Prozessor zu 100% auslasten. Das geht soweit, dass das Programm irgendwann einfach nicht mehr reagiert. Ich tue mich nun leider momentan schwer, die Ursache dafür herauszufinden.

Gibt es irgendeine Art Tool, Klasse oder sonst was für 'nen kleinen Helfer, der mir sagt, in welcher Klasse und Funktion die große Auslastung begründet liegt? Oder bin ich auf mich allein gestellt?


Beste Grüße
Sven

[Bernhard Geyer]

Siehts du im Taskmanager welches Programm die 100% CPU verursacht?
Oder bist du dir sicher das es dein Programm ist?

[jaenicke]

Du kannst einerseits den Process Explorer verwenden, insbesondere in den Prozessdetails im Reiter Threads. Wenn du .dbg Debuginformationen bereitstellst, siehst du dort nicht nur in welchem Thread, sondern auch mit welchen Aufrufstacks im Moment Auslastung verursacht wird.

Andererseits kannst du, wenn du auf dem PC selbst debuggen kannst, Delphi dort starten und dich mit dem Prozess verbinden. Dann kannst du direkt dort debuggen.

Falls die Angabe deiner Delphiversion veraltet ist:
Mit aktuelleren Versionen kannst du auch per Remote Debugger aus der Ferne den Prozess debuggen. Zudem kannst du dort auch leicht die einzelnen Threads anschauen und kommst auch an die jeweilige Codestelle, an der der Thread gerade angehalten wurde.

[Bernhard Geyer]

Zitat von jaenicke:

Mit aktuelleren Versionen kannst du auch per Remote Debugger aus der Ferne den Prozess debuggen.

Ich denke bei D5 sollte das auch gehen (Jedenfalls habe ich das bei D6 schon öfters verwendet - auch wenn es nicht super-stabil und komfortabel ist)

[mjustin]

Enthält das Programm Schleifen, die regelmäßig ausgeführt werden? Als einfache Diagnosemöglichkeit würde sich eine Protokollierung von Ausführungszeiten relevanter Methoden anbieten. Dazu empfehle ich eine einfache Logging-Bibliothek wie log4d oder log4delphi (beide auf Sourceforge).

Auf diese Weise kann die Programmstelle, die im Laufe der Zeit immer längere CPU Auslastung erzeugt, schrittweise eingekreist werden. Bei einem Programm, das nacheinander immer drei Prozeduren A, B und C ausführt, kann man so anhand des Protokoll beobachten, welche der drei Prozeduren zunehmende Ausführungszeiten hat. Und diese dann näher betrachten.

Auch die Anzahl von Wiederholungen von Schleifen kann protokolliert werden. Programmierfehler können dazu führen, dass die Schleife öfter als notwendig ausgeführt wird und entsprechend längere Laufzeiten hat.

[OlafSt]

Ich denke mal, das hier große Mengen an Daten in irgendwelchen Listen gespeichert werden, ohne das diese sich leeren (oder geleert werden).

Bestes Beispiel ist das TMemo. Das einfügen neuer Strings geht anfangs ratzfatz. Mit 20k Zeilen spürt man schon deutliche Längen nach TMemo.Add, mit 30k Zeilen bewegen wir uns langsam im Sekundenbereich für das Add etcpp. Dieselben Probleme hat auch TList, TStringList, TObjectList, TGrid und und und. Dieses Phänomen habe ich schon mit Delphi 1 beobachtet und bis heute existiert dieses Problem.

Da man dieselben Laufzeiten beobachtet, wenn man eine Textdatei >5MB mit Notepad öffnet, tippe ich auf ein in der WinAPI vergrabenes Problem mit Listen aller Art.

Abhilfe: Verhindern, das diese Listen ein gewisses Maß an "Füllgrad" überschreiten oder passende Controls suchen, die nicht auf dem WinAPI-"TList" basieren.

[jaenicke]

Zitat von Bernhard Geyer:

Ich denke bei D5 sollte das auch gehen (Jedenfalls habe ich das bei D6 schon öfters verwendet - auch wenn es nicht super-stabil und komfortabel ist)

Theoretisch ja, aber gerade bei solchen Sachen dürfte der alte Remote Debugger an die Grenzen stoßen... probieren kann man es natürlich.

Ansonsten blieben noch Profiling Tools wie AQTime.

[p80286]

Zitat von OlafSt:

Ich denke mal, das hier große Mengen an Daten in irgendwelchen Listen gespeichert werden, ohne das diese sich leeren (oder geleert werden).

Bestes Beispiel ist das TMemo. Das einfügen neuer Strings geht anfangs ratzfatz. Mit 20k Zeilen spürt man schon deutliche Längen nach TMemo.Add, mit 30k Zeilen bewegen wir uns langsam im Sekundenbereich für das Add etcpp. Dieselben Probleme hat auch TList, TStringList, TObjectList, TGrid und und und. Dieses Phänomen habe ich schon mit Delphi 1 beobachtet und bis heute existiert dieses Problem.

Da man dieselben Laufzeiten beobachtet, wenn man eine Textdatei >5MB mit Notepad öffnet, tippe ich auf ein in der WinAPI vergrabenes Problem mit Listen aller Art.

Abhilfe: Verhindern, das diese Listen ein gewisses Maß an "Füllgrad" überschreiten oder passende Controls suchen, die nicht auf dem WinAPI-"TList" basieren.

Ich habe bisher noch kein Betriebssystem und keine Programmiersprache erlebt, bei denen der Zeitraum für die sequenzielle Verarbeitung von Daten, nicht proportional zur Datenmenge anwuchs. Aber vielleicht kennst Du ja Alternativen.

Gruß
K-H

[Meflin]

Zitat von p80286:

Ich habe bisher noch kein Betriebssystem und keine Programmiersprache erlebt, bei denen der Zeitraum für die sequenzielle Verarbeitung von Daten, nicht proportional zur Datenmenge anwuchs. Aber vielleicht kennst Du ja Alternativen.

Ein Add, was er beschrieben hat, ist nunmal aber nicht sequentiell, sondern zum Beispiel in einer Linked List eine Operation mit konstanter Zeitkomplexität. Da dauert auch das 3,265,349. add nicht länger als das 2.

Wenn ich allerdings schon höre, dass eine Anwedung "2 Monate am Stück" laufen soll, dann wird es aber genau solche Gründe haben. An der Stelle sei mal angemerkt: Wenn es um Hochverfügbarkeit geht, geht man eigentlich genau den gegenteiligen weg: man entwirft sein System so, dass es problemlos mit Neustarts umgehen kann, und führt diese unter Umständen sogar gewollt herbei. Es sollte natürlich nicht prinzipiell unmöglich sein, eine Anwendung so zu schreiben, dass sie unendlich lange laufen kann, aber ich könnte mir durchaus vorstellen, dass der Aufwand dafür deutlich höher ist, als sich gleich ein ordentliches (und fehlertolerantes) Design zu überlegen.

[BUG]

Die anderen Beiträge gehen ja in die Richtung, dass die Anwendung eine graphische Anwendung ist. Die Aufgabe wäre aber eigentlich eher etwas für einen Deamon/Service.
Dazu kannst du dann eine graphische Bedienoberfläche schreiben, auf der der Anwender herumklicken kann.

Zitat von Meflin:

Es sollte natürlich nicht prinzipiell unmöglich sein, eine Anwendung so zu schreiben, dass sie unendlich lange laufen kann, aber ich könnte mir durchaus vorstellen, dass der Aufwand dafür deutlich höher ist, als sich gleich ein ordentliches (und fehlertolerantes) Design zu überlegen.

Eine Anwendung, die lange laufen soll, muss ein ordentliches und fehlertolerantes Design haben

Graphische Oberflächen sind nicht ganz einfach und dank der verwendeten Bibliotheken ziemlich unübersichtlich/undurchschaubar und damit einfach ein Einfallstor für Fehler.
Also sollte man das Wichtige (Daten sammeln) von der Bedienoberfläche trennen und im Zweifelsfall einfache, stabile, gut erprobte Betriebssystemfunktionen nutzen (z.B. Dateisystem, Pipes).