WPR/WPA in der Praxis — Einstieg in die systemweite Leistungsuntersuchung für „der ganze PC ist langsam“

„Sie sagten, der ganze PC sei langsam geworden, nachdem sie eine neue App installiert hatten. Aber wenn ich den Task-Manager ansehe, haben CPU und Speicher beide Reserve.“ „Es gibt einen PC, der 3 Minuten zum Start braucht. Ich habe keine Ahnung, was falsch ist.“ — Leistungsberatungen kommen wirklich oft in dieser Form. Gemeinsam ist ihnen, dass das Ansehen eines bestimmten Prozesses keine Antwort gibt.

Werkzeuge auf Prozessebene sind vorhanden. Datei- und Registrierungszugriff sieht man mit Process Monitor, und CPU und GC einer .NET-App lassen sich mit PerfView verfolgen. Aber ein Symptom wie „der ganze PC ist langsam“ oder „die CPU ist im Leerlauf und es ist trotzdem langsam“ beginnt damit, dass Sie nicht einmal wissen, welcher Prozess der Schuldige ist. App A kann wegen eines Antivirus-Scans langsam sein, oder weil ein anderer Dienst stark auf den Datenträger schreibt, oder wegen einer Sperrkette, die mehrere Prozesse überspannt. Was Sie brauchen, sind Daten, die nicht das Innere eines Prozesses, sondern das Betriebssystem als Ganzes auf einer einzigen Zeitachse aufgezeichnet haben.

Die Werkzeuge zum Erfassen und Lesen davon sind Windows Performance Recorder (WPR) und Windows Performance Analyzer (WPA). WPR zeichnet betriebssystemweite Aktivität auf ETW-Basis (Event Tracing for Windows) auf, und WPA analysiert diese Aufzeichnung in Grafiken und Tabellen. Wer CPU auf welchem Stack genutzt hat, auf wen ein Thread gewartet hat, welcher Prozess Datenträger-E/A an welche Datei ausgegeben hat — Fakten ein oder zwei Stufen unter dem Task-Manager bleiben alle, mit Zeitstempeln.

An IT-Personal in kleinen und mittleren Unternehmen und an Windows-App-Entwickler gerichtet, ordnet dieser Artikel die Praxis des Erfassens mit WPR und das Lesen von WPA — besonders den Unterschied zwischen der Untersuchung „wenn die CPU hoch ist“ und „wenn die CPU niedrig ist und es trotzdem langsam ist“ — gestützt auf Primärquellen Stand August 2026.

1. Zuerst das Fazit

• Die erste Wahl für eine Untersuchung „der ganze PC ist langsam“ ist WPR/WPA, das eine betriebssystemweite ETW-Aufzeichnung erfasst und liest. Probleme, die Werkzeuge auf Prozessebene (Task-Manager, Procmon, PerfView) nicht festnageln können, lassen sich verfolgen, wenn Sie jeden Prozess und den Kernel auf einer einzigen Zeitachse ansehen.¹²
• Das Erfassungswerkzeug wpr.exe wird mit Windows 8.1 und später ausgeliefert. Sie können es ohne Extra-Installation nutzen. Die GUI-Ausgabe (WPRUI) und das Analysewerkzeug WPA sind im Windows ADK enthalten.¹²
• Die Grundprozedur sind drei Zeilen. Als Administrator wpr -start GeneralProfile -filemode → das Problem reproduzieren → wpr -stop C:\temp\trace.etl. Merken Sie sich nur das, und Sie können mit dem Erfassen beginnen.³
• Die Feldbasis ist eine Aufteilung „in der Kundenumgebung nur mit wpr.exe erfassen; das Lesen ist WPA auf der eigenen Maschine“. Sie können selbst auf einem Server erfassen, auf dem Sie keine Software installieren können. Es ist dieselbe Idee wie bei Paketerfassung „mit einem Standardwerkzeug erfassen, in Wireshark lesen“.¹
• Das Lesen von WPA beginnt damit, „CPU, Warten oder E/A“ zu klassifizieren. Wenn die CPU brennt, CPU Usage (Sampled); wenn die CPU im Leerlauf ist und es trotzdem langsam ist, Warteanalyse in CPU Usage (Precise); wenn der Datenträger verdächtigt wird, Disk Usage — der Pfad teilt sich am Anfang.⁴⁵
• CPU Usage (Sampled) zeigt „welche Funktion CPU genutzt hat“ aus einer Stichprobe etwa alle 1 Millisekunde. Sie können die Aufschlüsselung der „50 %“ des Task-Managers von Prozess → Thread → Stack → Funktion durchgehen.⁶
• CPU Usage (Precise) ist eine vollständige Aufzeichnung von Kontextwechseln und sagt Ihnen, „auf wen ein Thread gewartet hat“. Das Durchgehen von Waits (Wartezeit), ReadyingProcess (wer ihn aufweckte) und ReadyThreadStack (der Stack des Aufweckers) ist die Technik, die dieser Artikel am meisten vermitteln will.⁴⁷
• Einen Stack zu lesen erfordert Symbolkonfiguration. WPA verweist standardmäßig auf Microsofts öffentlichen Symbolserver. Um Funktionsnamen in Ihrer eigenen App zu sehen, fügen Sie den Pfad zu Ihren eigenen PDBs hinzu.⁸
• Eine ETL-Datei enthält interne Systeminformationen wie Prozessnamen und Dateipfade. Halten Sie die Erfassung auf das nötige Minimum, und entscheiden Sie, wie sie behandelt wird, wenn sie das Unternehmen verlässt, bevor Sie erfassen.

2. Wo die Werkzeuge sitzen — WPR erfasst, WPA liest

Windows Performance Toolkit (WPT) ist der Leistungsuntersuchungs-Werkzeugsatz im Windows ADK (Windows Assessment and Deployment Kit); die Mitte ist das Paar WPR und WPA.² Die Rollen sind klar geteilt.

• WPR (Windows Performance Recorder) = Erfassung. Es bündelt Gruppen von ETW-Anbietern in eine Einheit namens „Profil“, startet und stoppt die Aufzeichnung und erzeugt eine ETL-Datei. Die Kommandozeilenausgabe, wpr.exe, wird mit Windows 8.1 und später ausgeliefert, ohne Extra-Installation. Die GUI-Ausgabe (WPRUI.exe) ist im ADK enthalten.¹
• WPA (Windows Performance Analyzer) = Analyse. Es öffnet eine ETL-Datei und analysiert sie in Grafiken und Tabellen. Eine ADK-Installation ist erforderlich.²

Mit anderen Worten: Es gibt nichts, das Sie in der Kundenumgebung platzieren müssen. Mit dem betriebssystemeigenen wpr.exe erfassen, die ETL-Datei mitnehmen und sie in WPA auf dem eigenen PC lesen — dieselbe Aufteilung wie bei der Paketerfassung „mit pktmon erfassen, in Wireshark lesen“ hält.

flowchart TB
    accTitle: Die Aufteilung von Erfassen mit WPR und Lesen mit WPA
    accDescr: In der Kundenumgebung mit dem betriebssystemeigenen wpr.exe aufzeichnen und eine ETL-Datei erzeugen; mitnehmen und in WPA analysieren, das über das ADK auf dem eigenen PC installiert ist
    subgraph customer["Kunden-PC（keine Extra-Installation）"]
        wpr["wpr start → reproduzieren → stop"] --> etl["ETL-Datei"]
    end
    subgraph office["Ihr PC（WPA über ADK）"]
        wpa["Grafiken und Tabellen analysieren"]
    end
    etl -->|"Mitnehmen"| wpa

Abbildung 1: In der Kundenumgebung mit dem betriebssystemeigenen wpr.exe aufzeichnen und eine ETL-Datei erzeugen; mitnehmen und in WPA analysieren, das über das ADK auf dem eigenen PC installiert ist.

Wie es sich von ähnlichen Werkzeugen unterscheidet, lohnt sich ebenfalls zuerst zu ordnen.

Wenn Procmon ein Operationsprotokoll von „was es getan hat“ ist und PerfView „was innerhalb von .NET passierte“, ist WPA ein Werkzeug, das über jeden Prozess hinweg auditiert, „wo Zeit verschwunden ist“. Die Mechanik von ETW selbst und wie Sie Ihre eigene App mit ETW instrumentieren, sind in „Einführung in Windows-Ereignisprotokoll und ETW“ behandelt. Wenn Ihre eigene App ETW-Ereignisse ausgibt, werden die Prüfpunkte Ihrer App in derselben Aufzeichnung festgehalten und das Aufreihen wird viel leichter. WPR zeichnet allerdings nur Ereignisse von Anbietern auf, die das von Ihnen gewählte Aufzeichnungsprofil aktiviert. GeneralProfile enthält Ihre eigenen Anbieter nicht, wenn Sie sie also mischen wollen, bereiten Sie ein benutzerdefiniertes Aufzeichnungsprofil (.wprp) vor, das Ihre Anbieter aktiviert, und kombinieren Sie es als wpr -start GeneralProfile -start MyApp.wprp!MyAppProfile, wobei Sie den Profilnamen innerhalb der .wprp-Datei mit ! angeben³.

3. Erfassung in der Praxis (WPR) — start, reproduzieren, stop

Die Grundprozedur in einem Administratorterminal.

:: List of built-in profiles you can use
wpr -profiles

:: 1. Start capture (general-purpose profile, file mode)
wpr -start GeneralProfile -filemode

:: 2. Reproduce the issue (check capture status with wpr -status)

:: 3. Stop and save (you can attach a description of the problem).
::    Create the destination folder in advance (without it, -stop fails to save)
mkdir C:\temp 2>nul
wpr -stop C:\temp\slow-pc.etl "Reproduced the issue where the whole PC becomes slow while starting App X"

:: To abandon without saving
wpr -cancel

Was Sie an -start übergeben, ist ein Profil, ein Bündel der ETW-Anbieter, die die Untersuchung braucht.³ Nur die zu merken, die Sie oft nutzen, reicht.⁹

Sie können mehrere Profile auf einmal angeben, indem Sie -start aneinanderreihen (zum Beispiel wpr -start GeneralProfile -start FileIO -filemode).³

flowchart TB
    accTitle: WPR-Erfassungsablauf und wie Sie einen Modus wählen
    accDescr: Ein Problem, das Sie vor Ort reproduzieren können, wird kurz und zuverlässig im File-Modus erfasst; ein Problem, dessen Zeitpunkt Sie nicht kennen, wird im standardmäßigen Memory-Modus-Ringpuffer abgewartet. Ein Problem während Boot oder Anmeldung nutzt eine Boot-Aufzeichnung. In jedem Fall ist die Prozedur start / reproduzieren / stop dieselbe
    q{"Wann tritt es auf?"}
    q -->|"Vor Ort"| file["File-Modus: kurze Erfassung"]
    q -->|"Zeitpunkt unbekannt"| mem["Memory-Modus: warten（3.1）"]
    q -->|"Boot oder Anmeldung"| boot["Boot-Aufzeichnung（Kap. 8）"]
    file --> s1["start → reproduzieren → stop"]
    mem --> s1

Abbildung 2: Ein Problem, das Sie vor Ort reproduzieren können, wird kurz und zuverlässig im File-Modus erfasst; ein Problem, dessen Zeitpunkt Sie nicht kennen, wird im standardmäßigen Memory-Modus-Ringpuffer abgewartet. Ein Problem während Boot oder Anmeldung nutzt eine Boot-Aufzeichnung. In jedem Fall ist die Prozedur start / reproduzieren / stop dieselbe.

3.1. Memory-Modus und File-Modus — können Sie reproduzieren, oder warten Sie

WPR hat zwei Aufzeichnungsziel-Modi; der Standard ist der Memory-Modus (ein zirkulärer Puffer im Speicher). Es ist ein Ringpuffer, der von den ältesten Ereignissen an überschreibt, er eignet sich also dafür, die Erfassung laufen zu lassen, während Sie auf ein Problem warten, dessen Zeitpunkt Sie nicht kennen, und zu stoppen, wenn es eintritt. Das Hinzufügen von -filemode schaltet auf den File-Modus, und alles wird in eine durchgehende Datei geschrieben. Das wird nicht wegüberschrieben; die einzige Decke ist freier Datenträgerplatz, und die Datei wächst ohne Grenze.¹⁰

flowchart TB
    accTitle: Wie Memory-Modus und File-Modus aufzeichnen
    accDescr: Der Memory-Modus zeichnet in einen zirkulären Puffer im Speicher auf; ältere Ereignisse werden überschrieben und nur die jüngsten bleiben, er eignet sich also zum Warten. Der File-Modus behält alles in einer Datei, aber die einzige Decke ist freier Datenträgerplatz, er eignet sich also für eine kurze, zuverlässige Reproduktion
    ev["ETW-Ereignisse"] --> ring["Memory-Modus: Ringpuffer"]
    ev --> filem["File-Modus: eine Datei wachsen lassen"]
    ring -.-> use1["Auf unbekannten Zeitpunkt warten"]
    filem -.-> use2["Kurze, zuverlässige Reproduktion"]

Abbildung 3: Der Memory-Modus zeichnet in einen zirkulären Puffer im Speicher auf; ältere Ereignisse werden überschrieben und nur die jüngsten bleiben, er eignet sich also zum Warten. Der File-Modus behält alles in einer Datei, aber die einzige Decke ist freier Datenträgerplatz, er eignet sich also für eine kurze, zuverlässige Reproduktion.

Eine Faustregel für die Wahl ist wie folgt.

• Vor Ort reproduzierbar → File-Modus. Knapp vor der Reproduktion starten, knapp danach stoppen und die Erfassung bei wenigen Minuten halten
• Zeitpunkt unbekannt → Im Memory-Modus warten (der Standard). Sobald es auftritt, wpr -stop
• Selbst wenige Minuten GeneralProfile können eine ETL in der Größenordnung von Hunderten MB bis GB erzeugen. Eine zu große Datei kann in WPA unanalysierbar werden, also ist „je länger Sie erfassen, desto besser“ kontraproduktiv¹⁰¹¹

Um aus der GUI zu erfassen, starten Sie WPRUI, wählen ein Profil und Logging mode und Start/Save. Das offizielle How-to fasst die Prozedur zusammen.¹¹ Wenn Sie einen Ansprechpartner vor Ort bitten zu erfassen, können die drei Befehle oben unverändert in eine Prozedur.

4. Die Grundlagen des Lesens von WPA — Grafiken, die goldene Regel der Tabellen und das Einengen der Zeit

Wenn Sie eine erfasste ETL in WPA öffnen, listet der Graph Explorer links Grafikminiaturen in Kategorien wie System Activity, Computation, Storage und Memory.¹² Ziehen Sie eine Grafik, die Sie sehen wollen, auf die Analysis-Registerkarte rechts, und oben erscheint eine Grafik und unten eine Tabelle. Die ersten drei Dinge, die Sie aufnehmen sollten, sind diese.

1. Die goldene Regel der Tabellen — die Spaltenreihenfolge entscheidet die Gruppierung. Eine WPA-Tabelle hat zwei senkrechte Balken, gold und blau, und Spalten links vom Goldbalken hierarchisieren (gruppieren) die Daten in dieser Reihenfolge, und Spalten rechts vom Blaukalken sind Aggregate.¹³ Ordnen Sie sie Prozess → Stack und Sie erhalten eine Stack-Aggregation pro Prozess; Stack → Prozess und Sie erhalten eine Aggregation jedes Prozesses, der denselben Stack nutzt — das Ziehen von Spalten zum Umsortieren ist selbst eine Analyseoperation. Verstehen Sie diesen einen Punkt, und jede WPA-Tabelle wird gleich gelesen.

flowchart TB
    accTitle: Die goldene Regel der Tabellen — die zwei Balken und die Rolle der Spalten
    accDescr: Spalten links vom Goldbalken hierarchisieren die Daten in dieser Reihenfolge; Spalten zwischen Gold- und Blaubalken sind Anzeigespalten; Spalten rechts vom Blaubalken sind Aggregate. Das Ziehen von Spalten zum Umsortieren ist selbst eine Analyseoperation
    left["Links vom Gold: Gruppierung"] --> gold["Goldbalken"]
    gold --> mid["Zwischen den Balken: Anzeige"]
    mid --> blue["Blaubalken"]
    blue --> right["Rechts vom Blau: Aggregate"]
    left -.-> op["Spalten ziehen zum Analysieren"]

Abbildung 4: Spalten links vom Goldbalken hierarchisieren die Daten in dieser Reihenfolge; Spalten zwischen Gold- und Blaubalken sind Anzeigespalten; Spalten rechts vom Blaubalken sind Aggregate. Das Ziehen von Spalten zum Umsortieren ist selbst eine Analyseoperation.

1. Engen Sie den Zeitbereich ein. Ziehen Sie auf der Grafik, um einen Bereich auszuwählen, dann Rechtsklick und „Zoom“, und die Aggregation schaltet auf dieses Intervall allein. Leistungsuntersuchung sieht grundsätzlich immer nur „das Intervall, in dem das Problem geschah“ (Kapitel 9).
2. Konfigurieren Sie Symbole. Um einen Stack nach Funktionsname zu lesen, führen Sie Trace > Load Symbols aus dem Menü aus.¹⁴ Standardmäßig verweist es auf Microsofts öffentlichen Symbolserver (msdl.microsoft.com), Windows’ eigene Stacks können also aufgelöst werden, wenn Sie eine Internetverbindung haben. Um Funktionsnamen in Ihrer eigenen App zu sehen, fügen Sie den Ordner der PDBs Ihrer App in Trace > Configure Symbol Paths hinzu.⁸ Was eine PDB ist und warum Sie sie auch für einen Release-Build immer behalten sollten, ist in „Was ist eine PDB (Program Database)?“ zusammengefasst. Für native NGen-Abbilder von .NET Framework erzeugt WPR NGen-PDBs (.ngenpdb) zur Erfassungszeit und legt sie in einem Ordner neben der Aufzeichnung ab, und WPA verweist automatisch darauf.⁸ Das ist ein Mechanismus nur für NGen-Abbilder, und gewöhnlicher JIT-.NET-App-Code Ihrer eigenen ist außerhalb des Geltungsbereichs. Die Abbildung von einer JIT-Code-Adresse auf einen Funktionsnamen wird aus JIT-Ereignissen aufgelöst, die die CLR ausgibt, wenn Sie also eine .NET-App untersuchen, bereiten Sie ein Aufzeichnungsprofil (.wprp) vor, das die CLR-Anbieter (Microsoft-Windows-DotNETRuntime und das passende Rundown) aktiviert, und kombinieren Sie es wie Ihre eigenen Anbieter in Kapitel 3, wpr -start GeneralProfile -start MyDotNet.wprp!profile-name, sodass CLR-Ereignisse in der Aufzeichnung enthalten sind (Sie können prüfen, welche eingebauten Profile Ihr lokales WPR anbietet, mit wpr -profiles). Darüber hinaus behalten Sie die vom Build erzeugten PDBs für die Abbildung auf Quellzeilen und fügen sie dem Symbolpfad oben hinzu.

flowchart TB
    accTitle: Symbolauflösung zum Lesen eines Stacks nach Funktionsname
    accDescr: Das Ausführen von Trace Load Symbols löst Windows selbst vom öffentlichen Symbolserver von Microsoft auf und Ihre eigene App von Build-PDBs, die dem Symbolpfad hinzugefügt wurden. NGen-Abbilder nutzen NGen-PDBs, die WPR erzeugt; JIT-.NET-Code wird aus CLR-JIT-Ereignissen in der Aufzeichnung plus Build-PDBs aufgelöst
    load["Trace > Load Symbols"] --> ms["Windows: öffentliche Symbole"]
    load --> own["Eigene App: Build-PDBs"]
    ms -.-> ngen["NGen: WPR .ngenpdb"]
    own -.-> jit["JIT: CLR-Ereignisse + PDBs"]

Abbildung 5: Das Ausführen von Trace Load Symbols löst Windows selbst vom öffentlichen Symbolserver von Microsoft auf und Ihre eigene App von Build-PDBs, die dem Symbolpfad hinzugefügt wurden. NGen-Abbilder nutzen NGen-PDBs, die WPR erzeugt; JIT-.NET-Code wird aus CLR-JIT-Ereignissen in der Aufzeichnung plus Build-PDBs aufgelöst.

Sobald Sie vorbereitet sind, treten Sie über den nächsten Zweig ein. War in diesem Intervall die CPU hoch oder niedrig? Wenn hoch, Kapitel 5 (Sampled); wenn niedrig und trotzdem langsam, Kapitel 6 (Precise).

flowchart TB
    accTitle: Verzweigung zur Wahl einer WPA-Grafik aus dem Symptom
    accDescr: Zoomen Sie auf das Problemintervall; wenn die CPU hoch ist, gehen Sie zu CPU Usage Sampled; wenn niedrig und trotzdem langsam, prüfen Sie eine Ein-Kern- / Ein-Thread-Festnadelung und dann Warteanalyse in CPU Usage Precise; wenn der Datenträger verdächtigt wird, Disk Usage und File IO
    zoom["Auf das Problemintervall zoomen"] --> cpu{"CPU in diesem Intervall?"}
    cpu -->|"Hoch"| sampled["Kap. 5: Sampled"]
    cpu -->|"Niedrig, trotzdem langsam"| core{"1-Kern- / 1-Thread-Pin?"}
    core -->|"Ja"| sampled
    core -->|"Nein"| precise["Kap. 6: Precise"]
    cpu -->|"Datenträger verdächtigt"| disk["Kap. 7: Datenträger / Datei-E/A"]

Abbildung 6: Zoomen Sie auf das Problemintervall; wenn die CPU hoch ist, gehen Sie zu CPU Usage Sampled; wenn niedrig und trotzdem langsam, prüfen Sie eine Ein-Kern- / Ein-Thread-Festnadelung und dann Warteanalyse in CPU Usage Precise; wenn der Datenträger verdächtigt wird, Disk Usage und File IO.

5. Wenn die CPU hoch ist — „Wer verbrennt welche Funktion“ mit CPU Usage (Sampled)

Wenn die CPU festgenagelt ist, schauen Sie auf CPU Usage (Sampled). Das sind Stichprobendaten, die etwa alle 1 Millisekunde auf jeder CPU aufgezeichnet haben, „welcher Stack welches Prozesses läuft jetzt“, und das Verhältnis der Stichprobenzahlen ist die Aufschlüsselung der CPU-Zeit als solche.⁶

flowchart TB
    accTitle: Wie CPU Usage Sampled funktioniert
    accDescr: Etwa alle 1 Millisekunde wird der auf jeder CPU laufende Stack aufgezeichnet, und das aggregierte Stichprobenverhältnis ist die Aufschlüsselung der CPU-Zeit. Lesen Sie von Prozess zu Thread, Stack und Funktion. Kurze Aktivität, die zwischen Stichproben endet, erscheint nicht
    tick["Unterbrechung etwa alle 1 ms"] --> snap["Den laufenden Stack aufzeichnen"]
    snap --> agg["Stichprobenverhältnis = CPU-Aufschlüsselung"]
    agg --> drill["Prozess → Thread → Stack"]
    snap -.-> miss["Aktivität zwischen Stichproben wird verpasst"]

Abbildung 7: Etwa alle 1 Millisekunde wird der auf jeder CPU laufende Stack aufgezeichnet, und das aggregierte Stichprobenverhältnis ist die Aufschlüsselung der CPU-Zeit. Lesen Sie von Prozess zu Thread, Stack und Funktion. Kurze Aktivität, die zwischen Stichproben endet, erscheint nicht.

1. Aus Computation des Graph Explorer legen Sie CPU Usage (Sampled) auf die Analysis-Registerkarte und wählen die Vorgabe Utilization by Process, Stack.⁵
2. Sehen Sie Prozesse in absteigender Reihenfolge von Weight (oder Count) an. Die Identität dessen, was im Task-Manager „50 %“ war, wird zuerst auf Prozessebene klar.
3. Erweitern Sie die Stack-Spalte des schuldigen Prozesses. Stacks sind als Baum aggregiert, und das Gehen des Pfads, auf dem die Zahl an einer Verzweigung nicht stark fällt, landet Sie auf der Funktion, die CPU verbrennt. Wenn Symbole aufgelöst sind, ist es eine gerade Linie zu welcher Funktion in Ihrem eigenen Code.
4. Wenn das Erweitern des Baums mühsam ist, schalten Sie die Grafikanzeige auf Flame. Sie wird mit Breite = Anteil der CPU-Zeit gezeichnet, welcher Aufrufpfad dominiert, ist also auf einen Blick offensichtlich. CPU Usage (Sampled) hat auch eine Vorgabe Flame by Process, Stack.¹³

Es gibt eine Vorsicht. Weil es Stichproben sind, erscheint kurze Aktivität, die zwischen Stichproben endet, nicht.⁶ Merken Sie es sich als Werkzeug, um „wo CPU in der Summe genutzt wurde“ zu sehen, nicht als Werkzeug, um die genaue Dauer pro Aufruf zu messen.

6. Wenn die CPU niedrig ist und es trotzdem langsam ist — CPU Usage (Precise) und Warteanalyse

Das ist der Kern des Artikels. Bevor Sie zur Warteanalyse übergehen, gibt es allerdings eines zu bestätigen. „Die Gesamt-CPU-Auslastung ist niedrig“ bedeutet nicht „CPU ist nicht der Engpass“. Auf einem 16-Kern-PC sieht serielle Arbeit, die an einem Kern festgenagelt ist (ein einziger UI-Thread, der voll durchläuft), nur wie etwa 6 % insgesamt aus. Prüfen Sie zuerst in Kapitel 5 Sampled (oder Utilization by CPU von CPU Usage (Precise)), dass es keine Festnadelung auf einem bestimmten Kern oder Thread gibt, und wenn nicht, kommen Sie zu diesem Kapitel — die Arbeit ist nicht unfähig zu laufen, sie wartet. Was Ihnen sagt, worauf sie wartet, ist CPU Usage (Precise).

Wo Sampled Stichproben sind, ist Precise eine vollständige Aufzeichnung von Kontextwechseln (Threadwechseln). Ein Thread tritt in ein Warten ein, wird von jemandem aufgeweckt (Ready) und landet auf einer CPU — dieser Hin- und Rückweg bleibt eine Zeile nach der anderen, und Sie können die folgenden Spalten lesen.⁷⁴

flowchart TB
    accTitle: Ein Warte-Hin-und-Rückweg und wie die Spalten entsprechen
    accDescr: Ein Thread tritt auf dem Stack, der in NewThreadStack bleibt, ins Warten ein und wartet die Waits-Zeit. Wenn jemand ihn aufweckt, bleibt diese Partei in ReadyingProcess und ReadyThreadStack; er wartet die Ready-Zeit auf CPU-Konkurrenz und läuft dann wieder
    run1["Läuft"] -->|"Ins Warten eintreten"| waitst["Warten（Waits us）"]
    waitst -->|"Jemand weckt ihn"| ready["Ready（CPU-Konkurrenz）"]
    ready -->|"Landet auf einer CPU"| run2["Läuft wieder"]
    waitst -.-> col["NewThreadStack / ReadyingProcess"]

Abbildung 8: Ein Thread tritt auf dem Stack, der in NewThreadStack bleibt, ins Warten ein und wartet die Waits-Zeit. Wenn jemand ihn aufweckt, bleibt diese Partei in ReadyingProcess und ReadyThreadStack; er wartet die Ready-Zeit auf CPU-Konkurrenz und läuft dann wieder.

Das Lesemuster ist wie folgt.⁴

1. Wenden Sie die Vorgabe Utilization by Process, Thread an und fügen Sie NewThreadStack und ReadyThreadStack zu den Spalten hinzu.
2. Identifizieren Sie zuerst den Thread, der die verzögerte Operation ausführte (den UI-Thread, den Thread, der die betreffende Anfrage behandelte). Nur in absteigender Reihenfolge der gesamten Waits zu schauen, verwirrt, weil Threads, die „die ganze Zeit absichtlich warten“, etwa eine Nachrichtenschleife oder ein Timer, die Spitze belegen. Sobald Sie den Zielthread gefunden haben: Wenn seine CPU Usage (ms) groß ist, ist es ein CPU-Problem aus Kapitel 5; wenn Waits dominieren, ist es ein Warteproblem.
3. Erweitern Sie NewThreadStack und sehen Sie was er tat, als er stoppte. WaitForSingleObject oder EnterCriticalSection ist ein Sperrwarten; innerhalb synchroner E/A wie ReadFile ist es ein E/A-Warten; innerhalb eines Socket-Empfangs ist es das Warten auf die Antwort der Gegenseite.
4. Sehen Sie als Nächstes wer das Warten löste. Erweitern Sie ReadyThreadStack und prüfen Sie ReadyingProcess / ReadyingThreadId. Wenn er aus dem KiTimerExpiration des Kernels aufgeweckt wurde, war es ein Timer (= er schlief bis zu einem Timeout); wenn er aus der E/A-Abschlussbehandlung aufgeweckt wurde, bestätigt das ein E/A-Warten.⁴
5. Wenn die Partei, die ihn aufweckte, ein anderer Thread oder ein anderer Prozess ist, untersuchen Sie diesen Thread mit derselben Prozedur. „A wartete darauf, dass B eine Sperre löst, B wartete auf C’s RPC-Antwort, C wartete auf Datenträger-E/A“ — was Sie haben, wenn Sie diese Kette bis zur Wurzel gegangen sind, ist der kritische Pfad der Verzögerung.⁷

flowchart TB
    accTitle: Die Kritischer-Pfad-Kette, die Sie in der Warteanalyse gehen
    accDescr: Sehen Sie im NewThreadStack des verzögerten Threads A, was er tat, als er stoppte, identifizieren Sie den Aufwecker B aus ReadyThreadStack und ReadyingProcess, und untersuchen Sie B mit derselben Prozedur bis zur Wurzel-Datenträger-E/A
    a["Thread A（verzögerte Arbeit）"] -->|"Sperrwarten"| b["Thread B（hält die Sperre）"]
    b -->|"RPC-Warten"| c["Prozess C"]
    c -->|"Sync-E/A-Warten"| d["Datenträger-E/A（Wurzel）"]
    d -.->|"Abschluss weckt C"| c
    c -.->|"Antwort weckt B"| b
    b -.->|"Sperrlösung weckt A"| a

Abbildung 9: Sehen Sie im NewThreadStack des verzögerten Threads A, was er tat, als er stoppte, identifizieren Sie den Aufwecker B aus ReadyThreadStack und ReadyingProcess, und untersuchen Sie B mit derselben Prozedur bis zur Wurzel-Datenträger-E/A.

In einem Fall wie „wir haben es multithreadet und es wurde nicht schneller“ zeigt diese Prozedur jeden Worker auf einer einzigen Sperre aufgereiht als solchen. Sperrkonkurrenz entwurfsseitig zu vermeiden ist in „Praktische Best Practices für Multithreading: .NET-Edition“ behandelt, und der Windows-Mechanismus, der auf einer Abschlussbenachrichtigung läuft statt in synchroner E/A zu warten, in „I/O-Completion-Ports (IOCP) und der .NET-Thread-Pool“. „Auf wen es wartete“ in WPA festzunageln und es mit diesen Entwurfsargumenten zu beheben, ist ein durchgehender Fluss.

7. Datenträger und Datei-E/A — „Jemand scannt den Datenträger“ identifizieren

Ein klassischer Schuldiger von „der ganze PC ist langsam“ ist nicht die CPU, sondern der Datenträger. Sie untersuchen mit Disk Usage und File I/O in der Kategorie Storage.¹⁵

Disk Usage ist eine Aufzeichnung von Datenträger-E/A, und zwei Spalten zählen. Disk Service Time ist die Zeit, die das Datenträgergerät tatsächlich mit der Verarbeitung dieser E/A verbracht hat; IO Time ist die Zeit vom Eintritt der E/A in die Betriebssystemwarteschlange bis zum Abschluss. IO Time ist immer mindestens Service Time um den Betrag der Warteschlange, also wenn IO Time viel länger als Service Time ist, hat diese E/A „in der Warteschlange gewartet“.⁶ Das allein entscheidet allerdings nicht, ob der Schuldige, der die Warteschlange gemacht hat, ein anderer Prozess ist, oder nur die eigene schwere E/A dieses Prozesses, die auf einem langsamen Gerät aufgereiht ist. Ziehen Sie die Schlussfolgerung hier nicht; klären Sie sie mit Service Time (der eigenen Antwort des Geräts) und der nächsten Aufschlüsselung nach Prozess, Pfad und Stack.

Dann, mit der Vorgabe Utilization by Process, Path Name, Stack, sehen Sie, welcher Prozess E/A an welche Datei von welchem Stack ausgegeben hat, in absteigender Reihenfolge von IO Time oder Size.¹⁵ Die Antworten, die im Feld oft auftauchen, sind diese zwei.

• Antivirus hat jede Datei gescannt. Im Fenster, in dem die App langsam startete, sieht man den Antivirus-Prozess ein großes Lesevolumen ausgeben. Prozessname, Pfad und Volumen sind Beweise als solche für eine Ausschlussdiskussion.
• Ein anderer Prozess hat stark geschrieben. Sicherung, der Indexer, zu viel geschriebene Protokolle und Ähnliches. Wann ein Schreiben den Datenträger erreicht, involviert den Cache-Manager, also ist die Tatsache, dass „der Moment, in dem Sie geschrieben haben“ und „der Moment, in dem der Datenträger beschäftigt ist“ auseinanderlaufen können, auch in „Cache-Manager — Wann erreicht Ihr WriteFile tatsächlich die Festplatte?“ behandelt.

File I/O ist eine Schicht höher, eine Aufzeichnung der Dateioperationen, die die App ausgegeben hat (Create/Read/Write und Ähnliches), und Vorgaben wie Duration by Process, Thread, Type können Zeit pro Dateiname und pro Operation aggregieren.¹⁵ Ein Fall, der Zeit im Dateisystem oder einem Filtertreiber verbringt, bevor er den Datenträger erreicht, erscheint nicht in Disk Usage, also ist die Abweichung selbst — „Disk Usage ist friedlich, aber File I/O ist langsam“ — ein Hinweis. Wenn Sie von der Mechanik synchroner und asynchroner E/A starten wollen, siehe „Synchrones und asynchrones I/O — Was OVERLAPPED wirklich bedeutet“.

flowchart TB
    accTitle: Die unterschiedlichen Schichten, die File IO und Disk Usage sehen
    accDescr: Die Dateioperation einer App reist durch Dateisystem und Filtertreiber von der Betriebssystem-E/A-Warteschlange zum Datenträgergerät. File IO zeichnet Operationen auf der oberen Schicht auf; Disk Usage zeichnet E/A auf, die den Datenträger erreicht hat; die Differenz zwischen IO Time und Disk Service Time ist Wartezeit
    app["App: ReadFile / WriteFile"] --> fio["FS und Filter（File I/O）"]
    fio --> queue["Betriebssystem-E/A-Warteschlange"]
    queue --> dev["Datenträgergerät（Disk Usage）"]
    fio -.-> n1["Von Disk Usage verpasst"]
    queue -.-> n2["IO Time − Service Time"]
    dev -.-> n3["Service Time = Gerät"]

Abbildung 10: Die Dateioperation einer App reist durch Dateisystem und Filtertreiber von der Betriebssystem-E/A-Warteschlange zum Datenträgergerät. File IO zeichnet Operationen auf der oberen Schicht auf; Disk Usage zeichnet E/A auf, die den Datenträger erreicht hat; die Differenz zwischen IO Time und Disk Service Time ist Wartezeit.

Die Überlegung „vielleicht fehlt Speicher und es wird ausgelagert“ kann eine erste Isolierung in Task-Manager und Ressourcenmonitor erhalten, bevor Sie zu WPA gehen. Weisen Sie sie allerdings nicht allein aus committed memory zurück — selbst mit Commit-Reserve ist eine Situation möglich, in der physischer Speicherdruck den Working Set beschneidet und Hard Faults weiterlaufen. Prüfen Sie auch verfügbaren physischen Speicher und „Hard Faults/sec“ des Ressourcenmonitors. Wie man sie liest, steht in „Was bedeutet Windows’ „Speicherauslastung“ eigentlich?“.

8. Langsamer Boot und Anmeldung — Der Eingang zu einer Boot-Aufzeichnung

Ein Typ „es braucht 3 Minuten zum Start“ endet, bevor Sie wpr -start von Hand ausführen können. WPR hat eine Boot-Aufzeichnung, und Sie können veranlassen, dass das Betriebssystem beim nächsten Boot automatisch mit dem Aufzeichnen beginnt.³

:: 1. Arrange automatic recording on the next boot
wpr -boottrace -addboot GeneralProfile -filemode

:: 2. Restart (reproduce the slow boot)

:: 3. After boot, stop recording and save (the arrangement is also cleared)
mkdir C:\temp 2>nul
wpr -boottrace -stopboot C:\temp\boot.etl "Issue where boot takes 3 minutes"

flowchart TB
    accTitle: Ablauf der Boot-Aufzeichnung
    accDescr: Nachdem Sie die automatische Aufzeichnung beim nächsten Boot mit addboot veranlasst und neu gestartet haben, beginnt das Betriebssystem beim Boot automatisch aufzuzeichnen. Das Speichern mit stopboot nach der Anmeldung löscht auch die Veranlassung. Zum Abbrechen löschen Sie sie mit cancelboot
    add["wpr -boottrace -addboot"] --> rebootpc["Neu starten（langsamer Boot）"]
    rebootpc --> auto["Das Betriebssystem zeichnet beim Boot auf"]
    auto --> stop2["Nach der Anmeldung: -stopboot"]
    add -.-> cancel["Abbrechen: -cancelboot"]

Abbildung 11: Nachdem Sie die automatische Aufzeichnung beim nächsten Boot mit addboot veranlasst und neu gestartet haben, beginnt das Betriebssystem beim Boot automatisch aufzuzeichnen. Das Speichern mit stopboot nach der Anmeldung löscht auch die Veranlassung. Zum Abbrechen löschen Sie sie mit cancelboot.

Die Boot- und Herunterfahr-Messung, die früher xbootmgr gehörte, kann in aktuellem WPR auch mit Optionen wie -onoffscenario Boot ausgeführt werden.³ Eine erfasste Aufzeichnung wird mit demselben Werkzeugsatz wie die vorherigen Kapitel gelesen. Sehen Sie auf einer Zeitachse in der Processes-Grafik, welcher Prozess wann geboren wurde, zoomen Sie auf das Fenster, in dem der Boot hängt, und klassifizieren Sie CPU, Warten oder Datenträger — eine Start-App, die der Reihe nach auf etwas wartet, ein Dienststart, der an einer bestimmten E/A hängt, und Ähnliches werden sichtbar. Boot-Analyse ist eine tiefe Spezialität für sich, dieser Artikel geht also nur bis zum Eingang: „ein Problem, das Sie nicht von Hand fangen können, kann trotzdem mit WPR erfasst werden“. Beginnen Sie damit, das Gesamtbild mit einer GeneralProfile-Boot-Aufzeichnung zu erfassen.

9. Ein Arbeitsmuster — Klassifizieren → Zoomen → Stack, wiederholt

Jetzt, da die Werkzeuge klar sind, hier das Muster für die Untersuchung als Ganzes.

1. Nageln Sie die Zeit des Phänomens fest. Nicht „es war langsam“, sondern „10:23:40–10:24:10 war langsam“. App-Protokolle, das Ereignisprotokoll, eine Notiz der Person, die bedient hat — alles tut es. Wenn Ihre eigene App Prüfpunkte in ETW oder das Ereignisprotokoll schreibt, werden Ereignisse innerhalb der Aufzeichnung zu Zeitpflöcken als solchen.
2. Zoomen Sie nur auf dieses Intervall. Eine Aggregation der ganzen Aufzeichnung wird gemittelt, und die Anomalie, die zählt, wird verdünnt. WPA-Analyse ist immer ein Vergleich von „dem Intervall, das anormal war“ gegenüber „dem Intervall, das normal war“.
3. Klassifizieren Sie zuerst „CPU, Warten oder E/A“. Sehen Sie CPU Usage (Sampled) an; wenn es brennt, Kapitel 5. Wenn es nicht brennt, Waits in CPU Usage (Precise) (Kapitel 6). Wenn Disk Usage IO Time aufgebläht ist, Kapitel 7. Diese Dreiwege-Gabel zuerst zu nehmen, hält Sie davon ab, sich zu verlieren.
4. Wiederholen Sie Hypothese → Zoom → Stack. Wenn Sie „Antivirus?“ denken, engen Sie auf diesen Prozess ein und stützen Sie es mit dem Stack. Wenn es nicht hält, die nächste Hypothese. Keine Schlussfolgerung zu ziehen, bevor Sie bis zum Stack gegangen sind und es gestützt haben, ist die Disziplin dieser Art von Untersuchung.

flowchart TB
    accTitle: Die iterative Schleife einer Leistungsuntersuchung
    accDescr: Nageln Sie die Zeit des Phänomens fest, zoomen Sie auf das Intervall, klassifizieren Sie CPU / Warten / E/A, bilden Sie eine Hypothese und engen Sie ein, und stützen Sie sie mit dem Stack. Wenn sie hält, ist die Ursache bestätigt; wenn nicht, wiederholen Sie mit der nächsten Hypothese
    time["Die Zeit festnageln"] --> zoomstep["Auf dieses Intervall zoomen"]
    zoomstep --> triage["CPU / Warten / E/A klassifizieren"]
    triage --> hypo["Hypothese und einengen"]
    hypo --> stack["Mit dem Stack stützen"]
    stack -->|"Hält"| fix["Ursache bestätigt"]
    stack -->|"Hält nicht"| hypo

Abbildung 12: Nageln Sie die Zeit des Phänomens fest, zoomen Sie auf das Intervall, klassifizieren Sie CPU / Warten / E/A, bilden Sie eine Hypothese und engen Sie ein, und stützen Sie sie mit dem Stack. Wenn sie hält, ist die Ursache bestätigt; wenn nicht, wiederholen Sie mit der nächsten Hypothese.

Schließlich der Umgang mit der Erfassungsdatei. Eine ETL-Datei spiegelt das Innere des Systems weit: die Namen jedes Prozesses, Pfade von Dateien, die geöffnet wurden, Module, die geladen wurden, und (je nach Profil) Registrierungsschlüsselnamen. Eine Standard-GeneralProfile-Erfassung enthält keine Datenkörper wie Kommunikationsinhalte, aber wenn Sie einen benutzerdefinierten Anbieter aktiviert haben, geht die Nutzlast dieses Ereignisses (Zeichenfolgen, die die App aufgezeichnet hat, und Ähnliches) unverändert hinein. Nachdem Sie bestätigt haben, was die von Ihnen aktivierten Anbieter ausgeben, behandeln Sie sie als Datei, die vertraulich genug ist, das Unternehmen zu verlassen. Wie bei der Paketerfassung falten Sie die nötige Mindesterfassung, die Vereinbarung mit der Partei, der Sie sie übergeben, und eine Aufbewahrungsfrist und Löschung in die Prozedur.

flowchart TB
    accTitle: Was eine ETL-Datei spiegelt, und wie Sie sie behandeln
    accDescr: Eine ETL spiegelt jeden Prozessnamen, Pfade geöffneter Dateien, Module und je nach Profil Registrierungsschlüsselnamen; das Aktivieren eines benutzerdefinierten Anbieters schließt auch seine Nutzlast ein. Behandeln Sie sie als vertraulich: nötige Mindesterfassung, Vereinbarung mit der anderen Partei sowie Aufbewahrungsfrist und Löschung
    etl["ETL-Datei"] --> a1["Namen, Pfade, Module"]
    a1 --> a2["Registrierungsschlüssel（einige）"]
    a2 --> a3["Benutzerdefinierte Nutzlast"]
    a3 -.-> rule["Als vertraulich behandeln"]

Abbildung 13: Eine ETL spiegelt jeden Prozessnamen, Pfade geöffneter Dateien, Module und je nach Profil Registrierungsschlüsselnamen; das Aktivieren eines benutzerdefinierten Anbieters schließt auch seine Nutzlast ein. Behandeln Sie sie als vertraulich: nötige Mindesterfassung, Vereinbarung mit der anderen Partei sowie Aufbewahrungsfrist und Löschung.

10. Zusammenfassung

• Ein „der ganze PC ist langsam“, das der Task-Manager nicht erklären kann, wird mit einer betriebssystemweiten ETW-Aufzeichnung untersucht — mit WPR erfassen, mit WPA lesen. wpr.exe wird mit Windows 8.1 und später ausgeliefert, eine Aufteilung von Erfassen in der Kundenumgebung, Mitnehmen der ETL und Lesen in WPA auf der eigenen Maschine hält also.
• Erfassung sind die drei Schritte wpr -start GeneralProfile -filemode → reproduzieren → wpr -stop trace.etl. Wenn Sie reproduzieren können, File-Modus innerhalb weniger Minuten; wenn Sie warten, Memory-Modus (Ringpuffer). Länger ist nicht besser.
• WPA können Sie starten, sobald Sie drei Punkte aufgenommen haben: die goldene Regel der Tabellen (links vom Goldbalken = Gruppierung), das Zoomen des Zeitbereichs und die Symbolkonfiguration (Ihre eigene App braucht PDBs).
• Wenn die CPU hoch ist, gehen Sie Prozess → Stack → Funktion in CPU Usage (Sampled). Wenn die CPU niedrig ist und es trotzdem langsam ist, gehen Sie die Kette NewThreadStack (was es tat, als es stoppte) → Waits (wie lange es wartete) → ReadyingProcess und ReadyThreadStack (wer es aufweckte) in CPU Usage (Precise) bis zur Wurzel.
• Für den Datenträger sehen Sie „in der Warteschlange verbrachte Zeit“ aus der Differenz zwischen Disk Usage IO Time und Service Time, und identifizieren Sie die Ursache (ob das Gerät selbst langsam ist, oder wer die Warteschlange gemacht hat) aus Service Time und der Aufschlüsselung nach Prozess, Pfad und Stack. Langsamer Boot kann mit wpr -boottrace erfasst werden.
• Das Arbeitsmuster ist (1) die Zeit festnageln (2) auf das Intervall zoomen (3) CPU, Warten oder E/A klassifizieren (4) Hypothese → Zoom → Stack wiederholen. Behandeln Sie eine ETL als vertraulich, weil sie interne Informationen enthält.

WPAs Bildschirm ist einschüchternd, und jeder verirrt sich in der ersten Stunde. Sobald die zwei Rückgrate — „links vom Goldbalken ist Gruppierung“ und „Sampled ist, wo es gebrannt hat, Precise ist, auf wen es gewartet hat“ — sitzen, ist der Rest dieselbe Operation wiederholt. Das nächste Mal, wenn eine Beratung kommt, dass „die CPU Reserve hat und es trotzdem langsam ist“, schließen Sie den Task-Manager und erfassen Sie eine Aufzeichnung.

Weiterführende Artikel

• Mit PerfView und dotnet-trace die Ursache von „langsam“ finden — Praxis-Einstieg in die .NET-Performanceanalyse
• Process Monitor (ProcMon) Praxisleitfaden — „Konfiguration wird nicht gelesen“ und ACCESS DENIED in 10 Minuten identifizieren
• Einführung in Windows-Ereignisprotokoll und ETW ── Protokolle von Geschäftsanwendungen in die Standardmechanismen des Betriebssystems einordnen
• Was bedeutet Windows’ „Speicherauslastung“ eigentlich? — Working Set, Private Bytes, Commit und die Auslagerungsdatei richtig lesen
• Windows-Prozessorzeitplanung – Hintergrunddienste und P-/E-Kerne
• Was ist eine PDB (Program Database)? — Debugging-Informationen, Symbole und Source Link verstehen

Zugehörige Beratungsfelder

KomuraSoft LLC übernimmt die Untersuchung systemweiter Leistungsprobleme wie „der ganze PC ist langsam geworden und ich weiß nicht warum“, „die CPU hat Reserve und die App ist trotzdem langsam“ und „nur eine bestimmte Umgebung startet extrem langsam“. Wir übernehmen als durchgehendes Engagement die Erfassungsplanung mit WPR/WPA (in welcher Umgebung, welches Profil, wie viel erfassen), die Aufzeichnungsanalyse und die daraus folgende Korrektur auf der App-Seite und der Einstellungsseite.

• Windows-Anwendungsentwicklung
• Fehleruntersuchung und Ursachenanalyse
• Technische Beratung und Design-Review
• Kontakt

Quellen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Wo bekomme ich WPR und WPA? Kann ich sie in einer Kundenumgebung nutzen, in der ich keine Software installieren kann?

Das Erfassungswerkzeug wpr.exe (die Kommandozeilenausgabe) wird mit Windows 8.1 und später ausgeliefert, Sie können es also ohne Extra-Installation nutzen. Die GUI-Ausgabe, WPRUI, und das Analysewerkzeug WPA (Windows Performance Analyzer) sind im Windows ADK (Windows Assessment and Deployment Kit) enthalten und erfordern eine separate Installation. In der Praxis: Wenn Sie die Arbeit so aufteilen — „in der Kundenumgebung nur eine ETL-Datei mit dem betriebssystemeigenen wpr.exe erfassen, mitnehmen und auf der eigenen Maschine in WPA analysieren“ — können Sie systemweite Leistung auch an einem Standort untersuchen, an dem Sie keine Software hinzufügen können.

Warum ist es langsam, obwohl der Task-Manager CPU-Reserve zeigt? Was kann ich in WPA sehen?

Wenn die CPU-Auslastung niedrig ist und es trotzdem langsam ist, kann die Arbeit die CPU nicht nicht nutzen — sie ist gestoppt, weil sie „auf etwas wartet“. Sperrkonkurrenz, Warten auf das Ende synchroner E/A und Warten auf die Antwort eines anderen Prozesses sind typisch. Der Task-Manager zeigt nur das Ergebnis, die Auslastung; WPA's CPU Usage (Precise) zeigt aus einer Aufzeichnung pro Kontextwechsel, wo der Thread zu warten begann (NewThreadStack), wie lange er wartete (Waits) und wer ihn aufweckte (ReadyingProcess, ReadyThreadStack). Indem Sie die Partei verfolgen, die ihn warten ließ, können Sie „den Schuldigen der Langsamkeit“ bis zur Funktion identifizieren.

Wie lange soll ich eine Aufzeichnung erfassen? Wird die Datei nicht riesig?

Wenn Sie das Problem reproduzieren können, ist die Basis, knapp vor der Reproduktion zu starten, knapp danach zu stoppen und es bei wenigen Minuten zu halten. WPRs Standard ist der Memory-Modus, der in einen zirkulären Puffer im Speicher schreibt; ältere Ereignisse werden überschrieben, er eignet sich also zum Warten auf ein Problem, dessen Zeitpunkt Sie nicht kennen. Der File-Modus mit -filemode behält alles in einer durchgehenden Datei, aber die einzige Decke ist freier Datenträgerplatz, und eine zu große Datei kann in WPA unanalysierbar werden. Nutzen Sie den Memory-Modus für langes Warten, den File-Modus für eine kurze, zuverlässige Reproduktion.

Wie soll ich zwischen PerfView und WPA wählen?

Beide Werkzeuge verarbeiten ETW-Aufzeichnungen, aber ihre Stärken unterscheiden sich. PerfView versteht die .NET-Laufzeit tief und ist stark bei untersuchungsspezifischen Themen verwalteter Apps wie GC, Allokation und JIT. WPA eignet sich, betriebssystemweite CPU, Datenträger, Datei-E/A, Energie und Ähnliches über Grafiken und Tabellen zu lesen, und ist die erste Wahl, wenn „nicht eine bestimmte App, sondern der ganze PC langsam ist“, „mehrere Prozesse beteiligt sind“ oder „etwas außerhalb der App (Antivirus, ein Treiber, ein anderer Prozess) verdächtigt wird“. Eine Faustregel: PerfView für Langsamkeit der eigenen .NET-App allein, WPR/WPA für Langsamkeit des ganzen Systems.

Ist es in Ordnung, WPR in der Produktionsumgebung eines Kunden auszuführen?

Eine kurze Erfassung ist in der Praxis üblich, aber nicht bedingungslos sicher. ETW ist leichtgewichtig, aber das Aufzeichnen eines großen Ereignisvolumens mit Stacks verbraucht trotzdem eine gewisse Menge CPU und Speicher. Falten Sie Überlegungen wie Start knapp vor dem Reproduktionsschritt und Stopp knapp danach, Halten der Erfassung bei wenigen Minuten und Ausführen zu einem Zeitpunkt mit geringem Geschäftseinfluss in denselben Freigabeprozess wie jede gewöhnliche Änderung. Außerdem enthält eine ETL-Datei interne Systeminformationen wie Prozessnamen, Dateipfade und ausführbare Informationen, Sie sollten also im Voraus entscheiden, wie sie behandelt wird, wenn sie das Unternehmen verlässt (Minimierung, Aufbewahrungsfrist, Löschung).

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.