dotnet-trace-Hilfsprogramm für Leistungsanalysen

  • Artikel

Dieser Artikel gilt für: ✔️ dotnet-trace 3.0.47001 und höhere Versionen

Installieren

Es gibt zwei Möglichkeiten, dotnet-trace herunterzuladen und zu installieren:

  • Globales dotnet-Tool:

    Verwenden Sie zum Installieren der neuesten Releaseversion des NuGet-Paketsdotnet-trace den Befehl dotnet tool install:

    dotnet tool install --global dotnet-trace

  • Direkter Download:

    Laden Sie die ausführbare Datei für das Tool herunter, die Ihrer Plattform entspricht:

    OS Plattform
    Windows x86 | x64 | Arm | Arm-x64
    Linux x64 | Arm | Arm64 | musl-x64 | musl-Arm64

Hinweis

Sie benötigen eine entsprechende x86-Version des Tools, um dotnet-trace für eine x86-App verwenden zu können.

Übersicht

dotnet-trace [-h, --help] [--version] <command>

Beschreibung

Das dotnet-trace-Tool:

  • Bei diesem Tool handelt es sich um ein plattformübergreifendes .NET Core-Tool.
  • Es ermöglicht das Sammeln von .NET Core-Ablaufverfolgungen eines ausgeführten Prozesses ohne nativen Profiler.
  • Es basiert auf der Komponente EventPipe der .NET Core-Runtime.
  • Das Tool bietet unter Windows, Linux und macOS die gleiche Oberfläche.

Optionen

  • -h|--help

    Zeigt die Hilfe für die Befehlszeile an.

  • --version

    Mit dieser Option wird die Version des Hilfsprogramms „dotnet-trace“ angezeigt.

  • --duration

    Gewünschte Ausführungsdauer der Ablaufverfolgung. --duration 00:00:00:05 wird 5 Sekunden lang ausgeführt.

Befehle

Befehl
dotnet-trace collect
dotnet-trace convert
dotnet-trace ps
dotnet-trace list-profiles
dotnet-trace report

dotnet-trace collect

Erfasst eine Diagnoseablaufverfolgung aus einem laufenden Prozess oder startet einen untergeordneten Prozess und verfolgt ihn (.NET 5 und höher). Damit das Tool einen untergeordneten Prozess ausführen und vom Start aus verfolgen kann, fügen Sie -- an den Befehl „collect“ an.

Übersicht

dotnet-trace collect [--buffersize <size>] [--clreventlevel <clreventlevel>] [--clrevents <clrevents>]
    [--format <Chromium|NetTrace|Speedscope>] [-h|--help] [--duration dd:hh:mm:ss]
    [-n, --name <name>] [--diagnostic-port] [-o|--output <trace-file-path>] [-p|--process-id <pid>]
    [--profile <profile-name>] [--providers <list-of-comma-separated-providers>]
    [-- <command>] (for target applications running .NET 5 or later)
    [--show-child-io] [--resume-runtime]
    [--stopping-event-provider-name <stoppingEventProviderName>]
    [--stopping-event-event-name <stoppingEventEventName>]
    [--stopping-event-payload-filter <stoppingEventPayloadFilter>]

Optionen

  • --buffersize <size>

    Legt die Größe des In-Memory-Puffers in Megabyte fest. Standard: 256 MB.

    Hinweis

    Wenn der Zielprozess Ereignisse schneller ausgibt, als sie auf die Festplatte geschrieben werden können, kann dieser Puffer überlaufen, und einige Ereignisse werden verworfen. Sie können dieses Problem entschärfen, indem Sie die Puffergröße erhöhen oder die Anzahl der aufgezeichneten Ereignisse verringern.

  • --clreventlevel <clreventlevel>

    Ausführlichkeit von auszugebenden CLR-Ereignissen. Die folgende Tabelle zeigt die verfügbaren Ereignisebenen.

    Zeichenfolgenwert Numerischer Wert
    logalways 0
    critical 1
    error 2
    warning 3
    informational 4
    verbose 5

  • --clrevents <clrevents>

    Diese Option generiert eine Liste der zu aktivierenden Schlüsselwörter für CLR-Anbieter, die durch +-Zeichen getrennt wird. Mit dieser einfachen Zuordnung können Sie Schlüsselwörter für Ereignisse über Zeichenfolgenaliase anstelle von Hexadezimalwerten angeben. dotnet-trace collect --providers Microsoft-Windows-DotNETRuntime:3:4 fordert beispielsweise die gleichen Ereignisse wie dotnet-trace collect --clrevents gc+gchandle --clreventlevel informational an. Die folgende Tabelle ist eine Liste der verfügbaren Schlüsselwörter:

    Zeichenfolgenalias des Schlüsselworts Hexadezimalwert des Schlüsselworts
    gc 0x1
    gchandle 0x2
    fusion 0x4
    loader 0x8
    jit 0x10
    ngen 0x20
    startenumeration 0x40
    endenumeration 0x80
    security 0x400
    appdomainresourcemanagement 0x800
    jittracing 0x1000
    interop 0x2000
    contention 0x4000
    exception 0x8000
    threading 0x10000
    jittedmethodiltonativemap 0x20000
    overrideandsuppressngenevents 0x40000
    type 0x80000
    gcheapdump 0x100000
    gcsampledobjectallocationhigh 0x200000
    gcheapsurvivalandmovement 0x400000
    gcheapcollect 0x800000
    gcheapandtypenames 0x1000000
    gcsampledobjectallocationlow 0x2000000
    perftrack 0x20000000
    stack 0x40000000
    threadtransfer 0x80000000
    debugger 0x100000000
    monitoring 0x200000000
    codesymbols 0x400000000
    eventsource 0x800000000
    compilation 0x1000000000
    compilationdiagnostic 0x2000000000
    methoddiagnostic 0x4000000000
    typediagnostic 0x8000000000

    Weitere Informationen zu CLR-Anbietern finden Sie in der Referenzdokumentation zu .NET-Runtimeanbietern.

  • --format {Chromium|NetTrace|Speedscope}

    Legt das Ausgabeformat für die Konvertierung der Ablaufverfolgungsdatei fest. Der Standardwert ist NetTrace.

  • -n, --name <name>

    Der Name des Prozesses, von dem die Ablaufverfolgung erfasst werden soll.

  • --diagnostic-port <path-to-port>

    Hierbei handelt es sich um den Namen des zu erstellenden Diagnoseports. Informationen dazu, wie Sie diese Option zum Erfassen einer Überwachung ab dem App-Start verwenden, finden Sie unter Verwenden von Diagnoseports zum Erfassen einer Überwachung ab dem App-Start.

  • --duration <time-to-run>

    Die Zeitspanne, für die die Ablaufverfolgung ausgeführt werden soll. Verwenden Sie das Format dd:hh:mm:ss. Zum Beispiel wird mit 00:00:00:05 eine Ausführung für 5 Sekunden festgelegt.

  • -o|--output <trace-file-path>

    Der Ausgabepfad für die gesammelten Ablaufverfolgungsdaten. Wenn Nichts anderweitiges angegeben ist, wird <appname>_<yyyyMMdd>_<HHmmss>.nettrace verwendet, z. B. „myapp_20210315_111514.nettrace“.

  • -p|--process-id <PID>

    Dies ist die Prozess-ID, von der die Ablaufverfolgung erfasst werden soll.

  • --profile <profile-name>

    Ein benannter vordefinierter Satz von Anbieterkonfigurationen, mit dem gängige Ablaufverfolgungsszenarien kurz und präzise angegeben werden können. Die folgenden Profile sind verfügbar:

Profil Beschreibung
cpu-sampling Nützlich für die Nachverfolgung der CPU-Auslastung und allgemeine .NET-Laufzeitinformationen. Dies ist die Standardoption, wenn kein Profil oder Anbieter angegeben wird.
gc-verbose Verfolgt GC-Sammlungen und Beispielobjektzuordnungen.
gc-collect Verfolgt GC-Sammlungen nur mit sehr geringem Mehraufwand nach.

  • --providers <list-of-comma-separated-providers>

    Eine durch Trennzeichen getrennte Liste von EventPipe-Anbietern, die aktiviert werden sollen. Diese Anbieter ergänzen die durch --profile <profile-name> implizierten Anbieter. Wenn für einen bestimmten Anbieter eine Inkonsistenz vorliegt, hat diese Konfiguration Vorrang vor der impliziten Konfiguration aus dem Profil.

    Diese Liste der Anbieter hat das folgende Format:

    • Provider[,Provider]
    • Provider hat das Format: KnownProviderName[:Flags[:Level][:KeyValueArgs]].
    • KeyValueArgs hat das Format: [key1=value1][;key2=value2].

    Weitere Informationen zu einigen der bekannten Anbieter in .NET finden Sie unter Bekannte Ereignisanbieter.

  • -- <command> (für Zielanwendungen, die .NET 5 oder höher ausführen)

    Nach den Sammlungskonfigurationsparametern kann der Benutzer -- gefolgt von einem Befehl anfügen, um eine .NET-Anwendung mit mindestens Common Language Runtime 5.0 zu starten. Das kann beim Diagnostizieren von Problemen hilfreich sein, die am Anfang des Prozesses auftreten, wie Leistungsprobleme beim Start oder Assemblylade- und Binderfehler.

    Hinweis

    Mit dieser Option wird der erste .NET 5-Prozess überwacht, der an das Tool zurückmeldet. Das bedeutet: Wenn Ihr Befehl mehrere .NET-Anwendungen startet, wird nur die erste Anwendung erfasst. Sie sollten daher diese Option für eigenständige Anwendungen oder die Option dotnet exec <app.dll> verwenden.

  • --show-child-io

    Zeigt die Eingabe- und Ausgabestreams eines gestarteten untergeordneten Prozesses in der aktuellen Konsole an.

  • --resume-runtime

    Fortsetzen der Laufzeit, nachdem die Sitzung initialisiert wurde, wird standardmäßig auf „true“ festgelegt. Deaktivieren Sie das Wiederaufnehmen der Laufzeit mit --resume-runtime:false.

  • --stopping-event-provider-name

    Eine Zeichenfolge, die wie folgt analysiert wird, beendet die Ablaufverfolgung beim Treffen eines Ereignisses mit dem entsprechenden Anbieternamen. Stellen Sie zusätzlich --stopping-event-event-name und/oder --stopping-event-payload-filter für ein spezifisches Stoppereignis zu Verfügung. z. B. --stopping-event-provider-name Microsoft-Windows-DotNETRuntime, um die Ablaufverfolgung zu beenden, wenn sie auf das erste Ereignis trifft, das vom Microsoft-Windows-DotNETRuntime Ereignisanbieter ausgegeben wurde.

  • --stopping-event-event-name

    Eine Zeichenfolge, die wie folgt analysiert wird, beendet die Ablaufverfolgung beim Treffen eines Ereignisses mit dem entsprechenden Ereignisnamen. Erfordert, dass --stopping-event-provider-name festgelegt wird. Stellen Sie für ein spezifischeres Stoppereignis zusätzlich --stopping-event-payload-filter bereit. Wenn Sie z. B. --stopping-event-provider-name Microsoft-Windows-DotNETRuntime --stopping-event-event-name Method/JittingStarted die Ablaufverfolgung beenden möchten, wenn sie auf das erste Method/JittingStarted-Ereignis treffen, das vom Microsoft-Windows-DotNETRuntime-Ereignisanbieter ausgegeben wurde.

  • --stopping-event-payload-filter

    Eine Zeichenfolge, die als [payload_field_name]:[payload_field_value]-Paare getrennt durch Kommas analysiert wird, sodass die Ablaufverfolgung beim Treffen eines Ereignisses mit allen angegebenen Nutzlastpaaren beendet wird. Erfordert --stopping-event-provider-name, und --stopping-event-event-name muss festgelegt werden. z. B. --stopping-event-provider-name Microsoft-Windows-DotNETRuntime --stopping-event-event-name Method/JittingStarted --stopping-event-payload-filter MethodNameSpace:Program,MethodName:OnButtonClick zum Beenden der Ablaufverfolgung beim ersten Method/JittingStarted-Ereignis für die Methode OnButtonClick im Program-Namespace, ausgegebenen vom Microsoft-Windows-DotNETRuntime-Ereignisanbieter.

Hinweis

  • Das Beenden der Überwachung dauert bei großen Anwendungen möglicherweise lang (bis zu mehrere Minuten). Die Runtime muss den Typcache für den gesamten verwalteten Code senden, der bei der Überwachung erfasst wurde.
  • Unter Linux und macOS erwartet dieser Befehl, dass die Zielanwendung und dotnet-trace die gleiche TMPDIR-Umgebungsvariable verwenden. Andernfalls führt der Befehl zu einem Timeout.
  • Wenn Sie eine Ablaufverfolgung mit dotnet-trace erfassen möchten, muss der Befehl vom Root-Benutzer oder dem Benutzer ausgeführt werden, der den Zielprozess ausführt. Andernfalls kann das Tool keine Verbindung mit dem Zielprozess herstellen.
  • Wenn eine Fehlermeldung wie [ERROR] System.ComponentModel.Win32Exception (299): A 32 bit processes cannot access modules of a 64 bit process. angezeigt wird, versuchen Sie, eine dotnet-trace-Version mit nicht übereinstimmender Bitanzahl für den Zielprozess zu verwenden. Stellen Sie sicher, dass Sie die richtige Bitanzahl des Tools im Link für die Installation herunterladen.
  • Wenn bei der Ausführung von dotnet-trace collect eine unbehandelte Ausnahme auftritt, führt dies zu einer unvollständigen Ablaufverfolgung. Wenn Ihr Hauptanliegen darin besteht, die Ursache der Ausnahme zu finden, navigieren Sie zu Erfassen von Speicherabbildern bei Abstürzen. Als Folge der unbehandelten Ausnahme wird die Ablaufverfolgung beim Herunterfahren der Laufzeitumgebung abgeschnitten, um andere unerwünschte Verhaltensweisen wie z. B. einen Stillstand oder eine Datenbeschädigung zu verhindern. Aber selbst wenn die Ablaufverfolgung unvollständig ist, können Sie sie dennoch öffnen und überprüfen, was zu dem Fehler geführt hat. Es fehlen jedoch Rundowninformationen (diese sind erst am Ende einer Ablaufverfolgung verfügbar), sodass Stapel (abhängig vom aktivierten Anbieter) möglicherweise nicht aufgelöst werden. Öffnen Sie die Ablaufverfolgung, indem Sie PerfView mit dem Flag /ContinueOnError an der Befehlszeile ausführen. Die Protokolle enthalten auch den Ort, an dem die Ausnahme ausgelöst wurde.
  • Wenn Sie ein Stoppereignis über die --stopping-event-*-Optionen angeben, während der EventStream asynchron analysiert wird, gibt es einige Ereignisse, die zwischen dem Zeitpunkt übergeben werden, an dem ein Ablaufverfolgungsereignis mit den angegebenen Stoppereignisoptionen übereinstimmt, und die EventPipeSession wird beendet.

dotnet-trace convert

Konvertiert nettrace-Ablaufverfolgungen in alternative Formate zur Verwendung mit alternativen Tools für die Ablaufverfolgungsanalyse.

Übersicht

dotnet-trace convert [<input-filename>] [--format <Chromium|NetTrace|Speedscope>] [-h|--help] [-o|--output <output-filename>]

Argumente

  • <input-filename>

    Die zu konvertierende Eingabe-Ablaufverfolgungsdatei. Standard: trace.nettrace.

Optionen

  • --format <Chromium|NetTrace|Speedscope>

    Legt das Ausgabeformat für die Konvertierung der Ablaufverfolgungsdatei fest.

  • -o|--output <output-filename>

    Ausgabedateiname. Die Erweiterung des Zielformats wird hinzugefügt.

Hinweis

Das Konvertieren von nettrace-Dateien in chromium- oder speedscope-Dateien kann nicht rückgängig gemacht werden. speedscope- und chromium-Dateien enthalten nicht alle Informationen, die zum Rekonstruieren von nettrace-Dateien erforderlich sind. Mit dem convert-Befehl bleibt die ursprüngliche nettrace-Datei jedoch erhalten. Löschen Sie daher diese Datei nicht, wenn Sie beabsichtigen, sie später irgendwann zu öffnen.

dotnet-trace ps

Listet die dotnet-Prozesse auf, aus denen Ablaufverfolgungen erfasst werden können. Ab dotnet-trace 6.0.320703 werden auch die Befehlszeilenargumente angezeigt, mit denen jeder Prozess gestartet wurde (sofern verfügbar).

Übersicht

dotnet-trace ps [-h|--help]

Beispiel

Angenommen, Sie starten eine zeitintensive App mit dem Befehl dotnet run --configuration Release. In einem anderen Fenster führen Sie den Befehl dotnet-trace ps aus. Die Ausgabe sieht wie folgt aus. Sofern vorhanden, werden die Befehlszeilenargumente ab dotnet-trace-Version 6.0.320703 angezeigt.

> dotnet-trace ps
  
  21932 dotnet     C:\Program Files\dotnet\dotnet.exe   run --configuration Release
  36656 dotnet     C:\Program Files\dotnet\dotnet.exe

dotnet-trace list-profiles

Listet vordefinierte Ablaufverfolgungsprofile mit einer Beschreibung der Anbieter und Filter in den einzelnen Profilen auf.

Übersicht

dotnet-trace list-profiles [-h|--help]

dotnet-trace report

Erstellt einen Bericht in stdout aus einer zuvor generierten Ablaufverfolgung.

Übersicht

dotnet-trace report [-h|--help] <tracefile> [command]

Argumente

  • <tracefile>

    Der Dateipfad für die Ablaufverfolgung, die analysiert wird.

Befehle

dotnet-trace report topN

Sucht die obersten N Methoden, die am längsten in der Aufrufstapel waren.

Übersicht
dotnet-trace report <tracefile> topN [-n|--number <n>] [--inclusive] [-v|--verbose] [-h|--help]
Optionen
  • -n|--number <n>

Gibt die obersten N Methoden in der Aufrufstapel an.

  • --inclusive

Geben Sie die obersten N Methoden basierend auf der inklusiven Zeit aus. Wenn keine Angabe erfolgt, wird standardmäßig die exklusive Zeit verwendet.

  • -v|--verbose

Geben Sie die Parameter jeder Methode vollständig aus. Wenn keine Parameter angegeben werden, werden sie abgeschnitten.

Sammeln einer Ablaufverfolgung mit dotnet-trace

So sammeln Sie Ablaufverfolgungen mit dotnet-trace:

  • Ermitteln Sie die Prozess-ID (PID) der .NET Core-Anwendung, von der Ablaufverfolgungen gesammelt werden sollen.

    • Unter Windows können Sie z. B. den Task-Manager oder den tasklist-Befehl verwenden.
    • Verwenden Sie unter Linux beispielsweise den ps-Befehl.
    • dotnet-trace ps

  • Führen Sie den folgenden Befehl aus:

    dotnet-trace collect --process-id <PID>

    Der oben gezeigte Befehl generiert eine Ausgabe ähnlich der folgenden:

    Press <Enter> to exit...
Connecting to process: <Full-Path-To-Process-Being-Profiled>/dotnet.exe
Collecting to file: <Full-Path-To-Trace>/trace.nettrace
Session Id: <SessionId>
Recording trace 721.025 (KB)

  • Halten Sie den Sammelvorgang durch Drücken der <Enter>-Taste an. dotnet-trace beendet das Protokollieren von Ereignissen in der Datei trace.nettrace.

Starten einer untergeordneten Anwendung und Erfassen einer Ablaufverfolgung vom Start mithilfe von „dotnet-trace“

Wichtig

Das funktioniert nur bei Anwendungen mit .NET 5 oder höher.

Manchmal kann es nützlich sein, eine Ablaufverfolgung eines Prozesses vom Start zu erfassen. Bei Apps für .NET 5 oder höher können Sie dies mithilfe von „dotnet-trace“ erreichen.

Dadurch wird hello.exe mit arg1 und arg2 als Befehlszeilenargumenten gestartet, und der Ablauf wird vom Start der Runtime verfolgt:

dotnet-trace collect -- hello.exe arg1 arg2

Der oben gezeigte Befehl generiert eine Ausgabe ähnlich der folgenden:

No profile or providers specified, defaulting to trace profile 'cpu-sampling'

Provider Name                           Keywords            Level               Enabled By
Microsoft-DotNETCore-SampleProfiler     0x0000F00000000000  Informational(4)    --profile
Microsoft-Windows-DotNETRuntime         0x00000014C14FCCBD  Informational(4)    --profile

Process        : E:\temp\gcperfsim\bin\Debug\net5.0\gcperfsim.exe
Output File    : E:\temp\gcperfsim\trace.nettrace


[00:00:00:05]   Recording trace 122.244  (KB)
Press <Enter> or <Ctrl+C> to exit...

Sie können das Erfassen der Ablaufverfolgung durch Drücken der Taste <Enter> oder <Ctrl + C> abbrechen. Dadurch wird auch hello.exe beendet.

Hinweis

Beim Starten von hello.exe über „dotnet-trace“ wird die Eingabe/Ausgabe umgeleitet, und Sie können standardmäßig nicht in der Konsole damit interagieren. Verwenden Sie den --show-child-io-Schalter, um mit „stdin/stdout“ zu interagieren. Wenn Sie das Tool über STRG+C oder SIGTERM beenden, werden sowohl das Tool als auch der untergeordnete Prozess sicher beendet. Wenn der untergeordnete Prozess vor dem Tool beendet wird, wird das Tool ebenfalls beendet, und die Ablaufverfolgung sollte sicher angezeigt werden können.

Verwenden von Diagnoseports zum Erfassen einer Überwachung ab dem App-Start

Wichtig

Das funktioniert nur bei Anwendungen mit .NET 5 oder höher.

Der Diagnoseport ist ein neues Runtimefeature, das in .NET 5 hinzugefügt wurde und es Ihnen ermöglicht, die Ablaufverfolgung beim Start der App zu starten. Dies können Sie mit dotnet-trace einrichten, indem Sie dotnet-trace collect -- <command> wie in den Beispielen oben oder die Option --diagnostic-port verwenden.

Die Verwendung von dotnet-trace <collect|monitor> -- <command> zum Starten der Anwendung als untergeordneter Prozess ist die einfachste Möglichkeit, schnell mit der Überwachung der Anwendung ab dem Start zu beginnen.

Wenn Sie allerdings präzisere Kontrolle über die Lebensdauer der überwachten App wünschen (z. B., damit die App nur in den ersten 10 Minuten überwacht und dann weiterhin ausgeführt wird) oder mithilfe der CLI mit der App interagieren müssen, können Sie die Option --diagnostic-port verwenden, um sowohl die überwachte Ziel-App als auch dotnet-trace zu steuern.

  1. Der folgende Befehl sorgt dafür, dass dotnet-trace einen Diagnosesocket namens myport.sock erstellt und auf eine Verbindung wartet.

    dotnet-trace collect --diagnostic-port myport.sock

    Ausgabe:

    Waiting for connection on myport.sock
Start an application with the following environment variable: DOTNET_DiagnosticPorts=/home/user/myport.sock

  2. Starten Sie die Zielanwendung in einer separaten Konsole mit der Umgebungsvariable DOTNET_DiagnosticPorts, die Sie auf den Wert in der dotnet-trace-Ausgabe festlegen.

    export DOTNET_DiagnosticPorts=/home/user/myport.sock
./my-dotnet-app arg1 arg2

    Dadurch sollte dotnet-trace die Ablaufverfolgung für my-dotnet-app starten können:

    Waiting for connection on myport.sock
Start an application with the following environment variable: DOTNET_DiagnosticPorts=myport.sock
Starting a counter session. Press Q to quit.

    Wichtig

    Das Starten Ihrer App mit dotnet run kann sich als problematisch erweisen, da die .NET-CLI viele untergeordnete Prozesse erzeugen kann, bei denen es sich nicht um Ihre App handelt. Diese können vor Ihrer App eine Verbindung mit dotnet-trace herstellen, wodurch Ihre App zur Laufzeit angehalten wird. Es wird empfohlen, dass Sie direkt eine eigenständige Version der App oder dotnet exec verwenden, um die Anwendung zu starten.

Anzeigen der von dotnet-trace erfassten Ablaufverfolgung

Unter Windows können Sie NETTRACE-Dateien für die Analyse in Visual Studio oder PerfView anzeigen.

Unter Linux können Sie die Ablaufverfolgung anzeigen, indem Sie das Ausgabeformat von dotnet-trace in speedscope ändern. Ändern Sie das Ausgabedateiformat mithilfe der Option -f|--format. Sie können zwischen nettrace (der Standardoption) und speedscope wählen. Die Option -f speedscope bewirkt, dass dotnet-trace eine speedscope Datei erzeugt. Speedscope-Dateien können unter https://www.speedscope.app geöffnet werden.

Bei Ablaufverfolgungen, die auf Nicht-Windows-Plattformen erfasst wurden, können Sie die Ablaufverfolgungsdatei auch auf einen Windows-Computer verschieben und sie in Visual Studio oder PerfView anzeigen.

Hinweis

Die .net Core-Laufzeit generiert Ablauf Verfolgungen im nettrace-Format. Die Ablaufverfolgungen werden nach Abschluss der Ablaufverfolgung in speedscope (sofern angegeben) konvertiert. Da bei einigen Konvertierungen Datenverluste auftreten können, wird die ursprüngliche nettrace-Datei neben der konvertierten Datei beibehalten.

Verwenden von dotnet-trace zum Sammeln von Leistungsindikatorwerten über die Zeit

dotnet-trace kann:

  • EventCounter für die grundlegende Systemüberwachung in leistungsabhängigen Umgebungen verwenden. Beispielsweise in der Produktion.
  • Ablaufverfolgungen sammeln, damit diese nicht in Echtzeit angezeigt werden müssen.

Um z. B. Laufzeit-Leistungsindikatorwerte zu sammeln, verwenden Sie den folgenden Befehl:

dotnet-trace collect --process-id <PID> --providers System.Runtime:0:1:EventCounterIntervalSec=1

Der obige Befehl sorgt dafür, dass die Laufzeit-Leistungsindikatoren einmal pro Sekunde gemeldet werden. Dies entspricht einer Systemüberwachung mit geringem Aufwand. Indem Sie EventCounterIntervalSec=1 durch einen höheren Wert ersetzen (z. B. 60), können Sie eine kleinere Ablaufverfolgung mit geringerer Granularität in den Leistungsindikatordaten sammeln.

Der folgende Befehl reduziert den Mehraufwand und die Größe der Ablaufverfolgung stärker als der vorherige Befehl:

dotnet-trace collect --process-id <PID> --providers System.Runtime:0:1:EventCounterIntervalSec=1,Microsoft-Windows-DotNETRuntime:0:1,Microsoft-DotNETCore-SampleProfiler:0:1

Der obige Befehl deaktiviert Laufzeitereignisse und den verwalteten Stapelprofiler.

Vermeiden der Eingabe langer Befehle mithilfe der .rsp-Datei

Sie können dotnet-trace mit einer .rsp-Datei starten, die die zu übergebenden Argumente enthält. Dies kann hilfreich sein, wenn Sie Anbieter aktivieren, die lange Argumente erwarten, oder wenn Sie eine Shellumgebung verwenden, die Zeichen entfernt.

Es kann z. B. mühsam sein, den folgenden Anbieter bei jeder gewünschten Überwachung komplett tippen zu müssen:

dotnet-trace collect --providers Microsoft-Diagnostics-DiagnosticSource:0x3:5:FilterAndPayloadSpecs="SqlClientDiagnosticListener/System.Data.SqlClient.WriteCommandBefore@Activity1Start:-Command;Command.CommandText;ConnectionId;Operation;Command.Connection.ServerVersion;Command.CommandTimeout;Command.CommandType;Command.Connection.ConnectionString;Command.Connection.Database;Command.Connection.DataSource;Command.Connection.PacketSize\r\nSqlClientDiagnosticListener/System.Data.SqlClient.WriteCommandAfter@Activity1Stop:\r\nMicrosoft.EntityFrameworkCore/Microsoft.EntityFrameworkCore.Database.Command.CommandExecuting@Activity2Start:-Command;Command.CommandText;ConnectionId;IsAsync;Command.Connection.ClientConnectionId;Command.Connection.ServerVersion;Command.CommandTimeout;Command.CommandType;Command.Connection.ConnectionString;Command.Connection.Database;Command.Connection.DataSource;Command.Connection.PacketSize\r\nMicrosoft.EntityFrameworkCore/Microsoft.EntityFrameworkCore.Database.Command.CommandExecuted@Activity2Stop:",OtherProvider,AnotherProvider

Darüber hinaus enthält das Argument im vorherigen Beispiel ". Da Anführungszeichen nicht von jeder Shell gleich behandelt werden, können bei der Verwendung unterschiedlicher Shells verschiedene Probleme auftreten. Beispielsweise unterscheidet sich der Befehl, der in zsh eingegeben werden muss, von dem in cmd.

Statt den Befehl jedes Mal zu tippen, können Sie den folgenden Text in einer Datei mit dem Namen myprofile.rsp speichern.

--providers
Microsoft-Diagnostics-DiagnosticSource:0x3:5:FilterAndPayloadSpecs="SqlClientDiagnosticListener/System.Data.SqlClient.WriteCommandBefore@Activity1Start:-Command;Command.CommandText;ConnectionId;Operation;Command.Connection.ServerVersion;Command.CommandTimeout;Command.CommandType;Command.Connection.ConnectionString;Command.Connection.Database;Command.Connection.DataSource;Command.Connection.PacketSize\r\nSqlClientDiagnosticListener/System.Data.SqlClient.WriteCommandAfter@Activity1Stop:\r\nMicrosoft.EntityFrameworkCore/Microsoft.EntityFrameworkCore.Database.Command.CommandExecuting@Activity2Start:-Command;Command.CommandText;ConnectionId;IsAsync;Command.Connection.ClientConnectionId;Command.Connection.ServerVersion;Command.CommandTimeout;Command.CommandType;Command.Connection.ConnectionString;Command.Connection.Database;Command.Connection.DataSource;Command.Connection.PacketSize\r\nMicrosoft.EntityFrameworkCore/Microsoft.EntityFrameworkCore.Database.Command.CommandExecuted@Activity2Stop:",OtherProvider,AnotherProvider

Wenn Sie myprofile.rsp gespeichert haben, können Sie dotnet-trace mit dieser Konfiguration über den folgenden Befehl öffnen:

dotnet-trace @myprofile.rsp

Siehe auch