Ursache für dauerhafte CPU-Auslastung finden

[jfheins]

Zitat:

Zitat von Monday (Beitrag 1482722)

Könnte ein Profiler hier weiterhelfen?!

Ja, klar. AQTime wurde ja bereits genannt ;-)

Zitat:

Zitat von CodeX (Beitrag 1482725)

die neu hinzugefügte Debug-Zeile haut quasi ununterbrochen "0/0" Meldungen raus und tatsächlich gehen da offenbar ununterbrochen "leere" Messages durch (also in Msg ist alles 0).

Auch die msg ID? Also "Msg.Msg" ? Die ist das eigentlich Interessante. Ich würde jetzt tippen, ein Dutzend Messages pro Sekunde ist noch normal, hast du vll. genauere Zahlen wie viele da pro Sekunde laufen?
Evtl. einfach mal mit Zeitstempel und Msg ID loggen.

[CodeX]

Zitat:

Zitat von jfheins (Beitrag 1482726)

Auch die msg ID? Also "Msg.Msg" ?

Sorry, ja, auch Msg.Msg.

So sieht der Log von

Delphi-Quellcode:

OutputDebugString(PChar('### MSG App ' + GetTickCount.ToString + ' ' + Msg.Msg.ToString));

aus:

Code:

Debug Output: ### MSG App 1484513750 0 Process App.exe (16484)
Debug Output: ### MSG App 1484513781 0 Process App.exe (16484)
Debug Output: ### MSG App 1484513812 0 Process App.exe (16484)
Debug Output: ### MSG App 1484513843 0 Process App.exe (16484)
Debug Output: ### MSG App 1484513875 0 Process App.exe (16484)
Debug Output: ### MSG App 1484513906 0 Process App.exe (16484)
Debug Output: ### MSG App 1484513937 0 Process App.exe (16484)
Debug Output: ### MSG App 1484513968 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514015 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514046 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514078 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514109 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514140 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514171 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514218 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514250 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514281 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514312 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514343 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514375 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514406 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514437 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514468 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514515 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514531 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514562 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514593 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514609 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514640 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514671 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514718 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514750 0 Process App.exe (16484)
Debug Output: ### MSG App 1484514781 0 Process App.exe (16484)

Ist das normal?

[himitsu]

Findest irgendwo im Programmcode und Fremdkomponenten ein WM_NULL?


FMX/VCL (TPlatformWin/TApplication.WakeMainThread), Indy, OleControl's und paar Andere lösen ein WM_NULL aus, damit der Hauptthread z.B. die TThread.Synchronize verarbeitet.

[jfheins]

Normal ist relativ :stupid:

WM_Null Messages kommen wohl normalerweise nicht so oft vor. Aber es gibt bestimmte Software, die das verschickt bspw. um zu prüfen ob die Vordergrundfenster noch reagieren. Guck mal hier: https://devblogs.microsoft.com/oldne...02-00/?p=96266

Liegt dann vll. doch gar nicht an deinem Programm.

[CodeX]

Zitat:

Zitat von himitsu (Beitrag 1482728)

Findest irgendwo im Programmcode und Fremdkomponenten ein WM_NULL?
FMX/VCL (TPlatformWin/TApplication.WakeMainThread), Indy, OleControl's und paar Andere lösen ein WM_NULL aus, damit der Hauptthread z.B. die TThread.Synchronize verarbeitet.

In meinem Projekt habe ich das nicht gefunden. Bei den Komponenten habe ich WM_NULL bei Indy nur in Kommentaren gefunden (wird ohnehin nicht automatisch nach dem Programmstart verwendet). Aber theoretisch könnte es ja auch als "0" und nicht als "WM_NULL" im Quelltext irgendwo enthalten sein.

Zitat:

Zitat von jfheins (Beitrag 1482729)

Normal ist relativ :stupid:
WM_Null Messages kommen wohl normalerweise nicht so oft vor.[/url]

Dann anders formuliert: Können 33 Null-Messages pro Sekunde Grund für eine Auslastung von 2-3% auf einem logischen Prozessorkern sein?
Wenn ja, müsste das dann nicht jede Anwendung gleichermaßen betreffen? Messages werden nach meinem Verständnis normalerweise ja in jeder Anwendung empfangen und verarbeitet - selbst wenn nicht vom Entwickler explizit, dann dennoch vom Programmgrundgerüst für ganz normale Aktionen wie minimieren, etc.
Oder kann die Verwendung von HookMainWindow dazu führen?

Zitat:

Zitat von jfheins (Beitrag 1482729)

Liegt dann vll. doch gar nicht an deinem Programm.

Ehrlich gesagt, finde ich das gar nicht so wichtig. Wenn die Ursache in meinem Programm liegt, würde ich natürlich gerne die Ursache beheben. Wenn die Ursache aber extern liegt, dann würde ich zumindest gerne die Auswirkungen beheben. Sollte es an den Messages liegen: Wenn jetzt plötzlich 330 statt 33 davon pro Sekunde eingehen, dann führt das zu einer Auslastung von 20-30%? Und bei 1000 Messages dann zum kompletten Lockup? Das kann es ja nicht sein.

Und wie gesagt: Ich sehe im Process Explorer ja, dass keine andere Anwendung dieses Verhalten zeigt. Die anderen Prozesse sind entweder konstant 0, ab und an kurz "< 0.01" oder es handelt sich tatsächlich um Prozesse, die etwas tun (Browser, AntiVirus, etc.).

Ich werde mich jetzt ein bisschen in AQTime einarbeiten und es morgen damit versuchen. Dennoch finde ich diese Analyse vorab sehr sinnvoll, um zu verstehen, was als Ursache überhaupt in Frage kommt. Hätte ja sein können, dass sich das auch so herausfinden und beheben lässt.

[himitsu]

Zitat:

Aber theoretisch könnte es ja auch als "0" ...

Neeee neee neeee, alle Programmierer sind ja intelligent und verwenden vorhandene Konstanten, anstatt irgendwelcher wilder Magicvalues. :roll:

[Sinspin]

Dein Programm ist in SysTray minimiert wenn das Auftritt. Nur dann hast du CPU load? Oder auch wenn das Programm sichtbar ist?
...Ich kann mich erinnern das ich früher mal eine SysTray Komponente in Verwendung hatte die CPU verbraten hat wenn man die Animationsfunktion für das angezeigt Icon aktiviert hat.
Irgendwann bin ich dann auf eine andere umgestiegen oder das Verhalten war nach einer Aktualisierung weg. Ich kann mich aber nicht mehr erinnern.

[TiGü]

Wie ist das denn ausgegangen?

[CodeX]

Zitat:

Zitat von TiGü (Beitrag 1483551)

Wie ist das denn ausgegangen?

Tut mir leid für die sehr späte Rückmeldung...
AQTime hatte mich nur bedingt weitergebracht. Da es leider nur Laufzeiten und nicht irgendeine Form von Auslastung misst (zumindest habe ich nichts dergleichen gefunden), hatte ich darin nur als Bestätigung erkennen können, welche Threads dauerhaft laufen. Das hatte ich im Grunde auch vorher schon eingrenzen können, aber nun hatte ich zumindest eine Art Bestätigung. Die dauerhaften Threads gehören zu Dritt-Komponenten und sind fast alle auch harmlos gewesen. Bspw. hat VirtualTreeView einen dauerhaften WorkerThread, der aber wirklich nur etwas tut, wenn es was zu tun gibt. Die Ursache lag nach einigem Hin und Her in einer Komponente, die im Thread einen Timer startet und dieser zeichnet die Komponente neu, um diverse Animationen darin abbilden zu können. Testweises Deaktivieren des darin enthaltenen Timers entfernte auch die beobachtete CPU-Auslastung vollständig. Da die Ursache nicht im Hauptprogramm liegt, brauche ich da aber erstmal nichts dran weiterzumachen, sondern habe das entsprechend weitergereicht.
Ich bin hauptsächlich froh darüber, dass es nicht an den Messages o.ä. liegt.
Vielen Dank an alle für die Unterstützung!

[TiGü]

Danke für die Rückmeldung.

Zitat:

Zitat von CodeX

Die Ursache lag nach einigem Hin und Her in einer Komponente, die im Thread einen Timer startet und dieser zeichnet die Komponente neu, um diverse Animationen darin abbilden zu können.

Man beachte, wie zutreffend im Nachhinein das Glaskugel-Raten aus Beitrag #10 und #11 waren. :lol:

Um welche Dritt-Komponente handelt es sich denn?
Könnte hilfreich sein für spätere Generationen, die hier per Google drüber stolpern.