Ursache für dauerhafte CPU-Auslastung finden

[Uwe Raabe]

Das WaitMessage wird am Ende von Idle aufgerufen. Es ist also durchaus normal wenn ein Programm dort steht.

Ich würde mal das Idle selbst analysieren. Dort können z.B. im FOnIdle oder DoActionIdle ein paar CPU-lastige Arbeiten stattfinden.

Übrigens ist die Angabe 0,1% - 0,2% CPU-Auslastung in Relation zu der Anzahl der verfügbaren logischen Prozessoren zu sehen. Bei einem Zweikern-System ist 1% wenig, bei einem 64-Kern System ist damit quasi ein Kern ausgelastet.

[TiGü]

Naja, gesamt gesehen hast du ja eine Auslastung von 2-3 Prozent auf einen Kern, du hattest es vorne irgendwo erwähnt.
Du müsstest also bei 100 zufälligen Pausieren in zwei bis drei Fällen zur betreffenden Codestelle kommen.
Wie ich oben sagte...ist halt ne sehr stumpfe Methode und mit AQTime wirste schneller zum Ziel kommen.

Deine Applikation sendet oder empfängt TCP oder UDP Kommunikation?

[himitsu]

Wenn dauern Messages reinkommen (z.B. weil irgendwer massiv mit Broadcasts um sich wirft), dann könnte man das mal mitzählen/loggen.
TApplicationEvents.OnMessage

* aber OnMessage bekommt nur PostMessage mit, exclusive WM_WIMER
* und wenn irgendwo Messages außerhalb der VCL verarbeitet werden, dann geht das auch unter (z.B. haben MessageBox und Open-/SaveDialoge innen eine eigene Message-Loop, so lange der Dialog angezeigt wird)
* und für SendMessage bräuchte man einen anderen Hook

[Monday]

Könnte ein Profiler hier weiterhelfen?!

[CodeX]

Ich habe jetzt mal analysiert, wo/wie die Messages in der Anwendung verarbeitet werden. Es existiert eine zentrale Prozedur, wo alle Messages erst durchgehen:

Delphi-Quellcode:

Application.HookMainWindow(HookAppProc);

[...]

function TKlasse.HookAppProc(var Msg: TMessage): Boolean;
begin
  OutputDebugString(PChar('### MSG App ' + Msg.WParam.ToString +'/'+ Msg.LParam.ToString)); //Das habe ich jetzt hinzugefügt
  Result := False; //Should always be False unless we don't want the default message handling
  case Msg.Msg of
    WM_SIZE: ...
    WM_CLOSE: ...
    WM_SYSCOMMAND: ...
    ...
  end;
end;

Ich glaube, das an sich sollte nicht das Problem sein, aber 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). In der genannten Funktion passiert damit nichts, da es nach der case Abfrage gleich wieder rausspringt, aber vielleicht liegt das Problem dennoch hier?
Ist es normal, dass ununterbrochen leere Messages reinkommen? Wenn nicht, habe ich eine Chance, die Quelle der Messages herauszufinden (oder zumindest ob von außerhalb oder von einer anderen Stelle im Projekt)? Vielleicht kommt ja dann genau hier AQTime ins Spiel?

[jfheins]

Zitat von Monday:

Könnte ein Profiler hier weiterhelfen?!

Ja, klar. AQTime wurde ja bereits genannt

Zitat von CodeX:

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 von jfheins:

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

Sorry, ja, auch Msg.Msg.

So sieht der Log von 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?