Ursache für dauerhafte CPU-Auslastung finden

[CodeX]

Oh, vielen Dank!

Das zweite Video hatte ich also im Prinzip zuvor richtig verstanden und auch geschaut, was danach passiert. (dazu gleich mehr)

Das erste Video hat mir aber schon mal ein bisschen weitergeholfen.
Der Haupt-Thread (TID auch mit Process Explorer abgeglichen), der die Auslastung verursacht landet beim Anhalten immer hier:

Code:

win32u.NtUserWaitMessage:
762E10C0 B80C100100       mov eax,$0001100c
762E10C5 BA10632E76       mov edx,$762e6310
762E10CA FFD2             call edx
762E10CC C3               ret               <------
762E10CD 8D4900           lea ecx,[ecx+$00]

Der zugehörige Stack Trace ist das hier:

Code:

:762e10cc win32u.NtUserWaitMessage + 0xc
:0070ec0b TApplication.Idle + $153
Vcl.Forms.TApplication.HandleMessage
Vcl.Forms.TApplication.Run

In diesem Teil von "TApplication.Run" lande ich auch, wenn ich von OnIdle weitergehe:

Delphi-Quellcode:

procedure TApplication.Run;
[...]
  repeat
    try
      HandleMessage;
    except
      HandleException(Self);
    end;
  until Terminated;
[...]

Dass die Anwendung auf Messages hört, überrascht mich jetzt eher nicht. Also ganz normales Verhalten? Oder sollte das so doch nicht sein?
Habe das mehrfach mit dem gleichen Ergebnis durchgespielt. Bringt es was, das ganz oft weiter zu wiederholen, in der Hoffnung, ein Mal wo anders zu landen beim Anhalten?

[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.