AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Sprachen und Entwicklungsumgebungen Sonstige Fragen zu Delphi Delphi Ursache für dauerhafte CPU-Auslastung finden

Ursache für dauerhafte CPU-Auslastung finden

Ein Thema von CodeX · begonnen am 8. Feb 2021 · letzter Beitrag vom 23. Feb 2021
Antwort Antwort
Seite 3 von 4     123 4   
TiGü

Registriert seit: 6. Apr 2011
Ort: Berlin
2.605 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#21

AW: Ursache für dauerhafte CPU-Auslastung finden

  Alt 10. Feb 2021, 16:06
Ist das Projekt zufällig ein MDI-Projekt und verwendet Actions?
Nein, "leider" nicht.
Ich nehme an, das Nein bezog sich auf MDI.
Bitte trotzdem mal alle TAction-Instanzen checken, ob da nicht doch irgendwo ein OnUpdate angemeldet ist, was dein Problem verursacht.
Ein Debuggen von TApplication.Idle und all der Aufrufe darin ist vielleicht auch noch ganz hilfreich, wenn du Timer und Threads ausschließen kannst.

Oder wenn jemand noch eine Idee hat, was es mit der Stack-Info "TMethodImplementationIntercept" im Process Explorer auf sich haben könnte, auch gerne mitteilen.
Der Process Explorer schnappt sich einfach die erstbeste exportierte Funktion des Binary für den Mainthread, dass hat mit deinem Problem eher wenig zu tun.
Nimm mal ne neue und leere Applikation und öffne die im Dependency Walker oder Dependencies (https://github.com/lucasg/Dependencies).
Du wirst sehen, auch hier wird TMethodImplementationIntercept exportiert und der Mainthread wird in Process Explorer damit benannt.
  Mit Zitat antworten Zitat
TiGü

Registriert seit: 6. Apr 2011
Ort: Berlin
2.605 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#22

AW: Ursache für dauerhafte CPU-Auslastung finden

  Alt 10. Feb 2021, 16:11
Ganz stumpf ist noch die Möglichkeit, das Programm auszuführen und mehrmals im Debugger anzuhalten (Pause).
Je nach Zufall landest du dann an der gesuchten "rechenintensiven" Codestelle.

Ein normaler Call Stack vom Mainthread sieht zumeist so aus:
Code:
:74e510cc win32u.NtUserWaitMessage + 0xc
:005c5e72 TApplication.Idle + $14E
Vcl.Forms.TApplication.HandleMessage
Vcl.Forms.TApplication.Run
Project2.Project2
:7607fa29 KERNEL32.BaseThreadInitThunk + 0x19
:76fd75f4 ntdll.RtlGetAppContainerNamedObjectPath + 0xe4
:76fd75c4 ntdll.RtlGetAppContainerNamedObjectPath + 0xb4
Das sollte bei dir dann abweichen, wenn du erfolgreich bist.
  Mit Zitat antworten Zitat
CodeX

Registriert seit: 30. Okt 2004
456 Beiträge
 
Delphi 10.3 Rio
 
#23

AW: Ursache für dauerhafte CPU-Auslastung finden

  Alt 10. Feb 2021, 16:28
Keine Verwendung von MDI oder TAction.

Ich habe alle Timer, die im gesamten Projekt vorkommen (Fremdkomponenten ausgenommen), in die Watch List hinzugefügt und das Programm im Debugger im Leerlauf angehalten: Alle Timer sind entweder Enabled:=False oder Inaccessible value, da in nicht initialisierten Forms oder Objekten.

Threads werden theoretisch verwendet, aber nicht automatisch nach dem Programmstart, sondern nur bei bestimmten Aktionen. Breakpoints bei deren Erstellung springen entsprechend auch nicht an. Der Process Explorer bestätigt das meiner Meinung ja auch, da dort die Auslastung im HauptThread liegt.

Wenn ich im Debugger auf Pause drücke, lande ich in der CPU Ansicht immer hier:
Code:
ntdll.RtlUserThreadStart:
775E3BE0 833DBC69697700   cmp dword ptr [$776969bc],$00
Darüber und darunter ist halt viel Assembler, aber keine Funktionsnamen o.ä. die mir irgendetwas sagen würden.
Lässt sich aus dieser Zeile schon etwas ableiten, was mir entgeht?

> Debuggen von TApplication.Idle
Was meinst Du damit genau? Im OnIdle Event von TApplication irgendwas einfügen, darauf einen Breakpoint setzen und schauen, was davor passiert ist? Oder wie?
Nur Delphi schafft es, einem ein Lächeln zu schenken, wenn man sich beim Schreiben von := vertippt und stattdessen ein :) erscheint.
  Mit Zitat antworten Zitat
TiGü

Registriert seit: 6. Apr 2011
Ort: Berlin
2.605 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#24

AW: Ursache für dauerhafte CPU-Auslastung finden

  Alt 10. Feb 2021, 17:34
Für beide Fragen habe ich mal zwei kleine TeamViewer-Meetings aufgezeichnet, vielleicht wird's dann eher klar was ich von dir möchte.
https://drive.google.com/drive/folde...D6wFeYfGq1iese

How_to_Debug.tvs:
Der erste Thread in der Threadübersicht ist immer der Mainthread in der IDE.

How_to_Debug_2.tvs:
Debuggen der TApplication.Idle.
Voraussetzung: Project Options -> Delphi-Compiler -> Compiling -> Use debug .dcus muss auf True stehen.
Wenn deine IDE auf deutsch steht dann entsprechend die deutschen Begriffe.
  Mit Zitat antworten Zitat
CodeX

Registriert seit: 30. Okt 2004
456 Beiträge
 
Delphi 10.3 Rio
 
#25

AW: Ursache für dauerhafte CPU-Auslastung finden

  Alt 10. Feb 2021, 18:28
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?
Nur Delphi schafft es, einem ein Lächeln zu schenken, wenn man sich beim Schreiben von := vertippt und stattdessen ein :) erscheint.
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
8.157 Beiträge
 
Delphi 10.4 Sydney
 
#26

AW: Ursache für dauerhafte CPU-Auslastung finden

  Alt 10. Feb 2021, 18:57
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.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
TiGü

Registriert seit: 6. Apr 2011
Ort: Berlin
2.605 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#27

AW: Ursache für dauerhafte CPU-Auslastung finden

  Alt 10. Feb 2021, 19:23
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?
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
37.478 Beiträge
 
Delphi 10.4 Sydney
 
#28

AW: Ursache für dauerhafte CPU-Auslastung finden

  Alt 10. Feb 2021, 19:38
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
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014
  Mit Zitat antworten Zitat
Monday

Registriert seit: 24. Aug 2012
81 Beiträge
 
FreePascal / Lazarus
 
#29

AW: Ursache für dauerhafte CPU-Auslastung finden

  Alt 10. Feb 2021, 20:40
Könnte ein Profiler hier weiterhelfen?!
  Mit Zitat antworten Zitat
CodeX

Registriert seit: 30. Okt 2004
456 Beiträge
 
Delphi 10.3 Rio
 
#30

AW: Ursache für dauerhafte CPU-Auslastung finden

  Alt 10. Feb 2021, 21:04
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?
Nur Delphi schafft es, einem ein Lächeln zu schenken, wenn man sich beim Schreiben von := vertippt und stattdessen ein :) erscheint.
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 05:15 Uhr.
Powered by vBulletin® Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf