Heapanalysverktyg (dotnet-gcdump)

Den här artikeln gäller för: ✔️ dotnet-gcdump version 10.0 och senare versioner

Installera

Det finns två sätt att ladda ned och installera dotnet-gcdump:

• dotnet global tool:

  Om du vill installera den senaste versionen av dotnet-gcdumpNuGet-paketet använder du installationskommandot för dotnet-verktyget:

  dotnet tool install --global dotnet-gcdump
  

• Direkt nedladdning:

  Ladda ned det körbara verktyget som matchar din plattform:

  Olympiska Spelen (OS)	Plattform
  Windows	x86 | x64 | Arm | Arm64
  Linux	x64 | Arm | Arm64 | musl-x64 | musl-Arm64

Sammanfattning

dotnet-gcdump [-h|--help] [--version] <command>

beskrivning

Det dotnet-gcdump globala verktyget samlar in GC-dumpar (Skräpinsamlare) av live.NET-processer med EventPipe. GC-dumpar skapas genom att utlösa en GC i målprocessen, aktivera särskilda händelser och återskapa grafen med objektrötter från händelseströmmen. Den här processen gör att GC-dumpar kan samlas in medan processen körs och med minimala omkostnader. Dessa dumpar är användbara i flera scenarier:

• Jämföra antalet objekt på heapen vid flera tidpunkter.
• Analysera objektens rötter (besvara frågor som "vad har fortfarande en referens till den här typen?").
• Samla in allmän statistik om antalet objekt på högen.

Visa GC-dumpen som hämtats från dotnet-gcdump

I Windows .gcdump kan filer visas i PerfView för analys eller i Visual Studio. För närvarande finns det inget sätt att öppna en .gcdump på andra plattformar än Windows.

Du kan samla in flera .gcdumps och öppna dem samtidigt i Visual Studio för att få en jämförelseupplevelse.

Alternativ

• --version

  Visar versionen av dotnet-gcdump verktyget.

• -h|--help

  Visar kommandoradshjälp.

Kommandon

dotnet-gcdump collect

Samlar in en GC-dump från en process som körs.

Sammanfattning

dotnet-gcdump collect [-h|--help] [-p|--process-id <pid>] [-o|--output <gcdump-file-path>] [-v|--verbose] [-t|--timeout <timeout>] [-n|--name <name>] [--dsrouter <ios|ios-sim|android|android-emu>]

Alternativ

• -h|--help

  Visar kommandoradshjälp.

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

  Process-ID:t som GC-dumpen ska hämtas från.

  Kommentar

  I Linux och macOS kräver det här alternativet målprogrammet och dotnet-gcdump att samma TMPDIR miljövariabel delas. Annars överskrider kommandot tidsgränsen.

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

  Sökvägen där insamlade GC-dumpar ska skrivas. Standardvärdet är .\YYYYMMDD_HHMMSS_<pid.gcdump>.

• -v|--verbose

  Mata ut loggen när du samlar in GC-dumpen.

• -t|--timeout <timeout>

  Ge upp insamlingen av GC-dumpen om det tar längre tid än så här många sekunder. Standardvärdet är 30.

• -n|--name <name>

  Namnet på den process som GC-dumpen ska samlas in från.

  Kommentar

  I Linux och macOS kräver det här alternativet målprogrammet och dotnet-gcdump att samma TMPDIR miljövariabel delas. Annars överskrider kommandot tidsgränsen.

• --diagnostic-port <port-address[,(listen|connect)]>

  Anger den diagnostikport som används för att kommunicera med processen som ska dumpas. dotnet-gcdump och .NET-körningen i målprocessen måste komma överens om portadressen, där den ena lyssnar och den andra ansluter. dotnet-gcdump avgör automatiskt rätt port vid anslutning med hjälp av --process-id alternativen eller --name . Det är vanligtvis bara nödvändigt att ange porten explicit när du kommunicerar med en process som körs i en container som inte ingår i det aktuella processnamnområdet.

  Skiljer port-address sig åt beroende på operativsystem:

  • Linux och macOS – en sökväg till en Unix-domänsocket, till exempel /foo/tool1.socket.
  • Windows – en sökväg till ett namngivet rör, till exempel \\.\pipe\my_diag_port1.
  • Android, iOS och tvOS – en IP:port som 127.0.0.1:9000.

  Som standard lyssnar dotnet-gcdump på den angivna adressen. Du kan begära att dotnet-gcdump ansluter i stället genom att lägga till ,connect efter adressen. Anslut till exempel --diagnostic-port /foo/tool1.socket,connect till en .NET-körningsprocess som lyssnar på /foo/tool1.socket Unix-domänsocketen.

• '--dsrouter {ios|ios-sim|android|android-emu}

  Startar dotnet-dsrouter och ansluter till den. Kräver att dotnet-dsrouter installeras. Kör dotnet-dsrouter -h för mer information.

dotnet-gcdump ps

Visar en lista över de dotnet-processer som GC-dumpar kan samlas in för. dotnet-gcdump 6.0.320703 och senare visar även de kommandoradsargument som varje process startades med, om den är tillgänglig.

Sammanfattning

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

Exempel

Anta att du startar en tidskrävande app med kommandot dotnet run --configuration Release. I ett annat fönster kör dotnet-gcdump ps du kommandot . Utdata visas på följande sätt. Eventuella kommandoradsargument visas med version dotnet-gcdump 6.0.320703 och senare.

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

dotnet-gcdump report <gcdump_filename>

Generera en rapport från en tidigare genererad GC-dump eller från en process som körs och skriv till stdout.

Sammanfattning

dotnet-gcdump report [-h|--help] [-p|--process-id <pid>] [-t|--report-type <HeapStat>]

Alternativ

• -h|--help

  Visar kommandoradshjälp.

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

  Process-ID:t som GC-dumpen ska hämtas från.

• -t|--report-type <HeapStat>

  Vilken typ av rapport som ska genereras. Tillgängliga alternativ: heapstat (standard).

Felsöka

• Det finns ingen typinformation i gcdump.

  Före .NET Core 3.1 uppstod ett problem där en typcache inte rensades mellan gcdumps när de anropades med EventPipe. Detta resulterade i de händelser som behövs för att fastställa typinformation som inte skickas för den andra och efterföljande gcdumps. Detta har åtgärdats i .NET Core 3.1-preview2.

• COM- och statiska typer finns inte i GC-dumpen.

  Före .NET Core 3.1 uppstod ett problem där statiska typer och COM-typer inte skickades när GC-dumpen anropades via EventPipe. Detta har åtgärdats i .NET Core 3.1.

• dotnet-gcdump kan inte generera en .gcdump fil på grund av information som saknas, till exempel [Fel] Undantag under gcdump: System.ApplicationException: ETL-filen visar början på en heapdump men inte dess slutförande.. Eller så .gcdump innehåller filen inte hela heapen.

  dotnet-gcdump fungerar genom att samla in en spårning av händelser som genereras av skräpinsamlaren under en inducerad generation 2-samling. Om heapen är tillräckligt stor, eller om det inte finns tillräckligt med minne för att skala händelsebuffertarna, kan de händelser som krävs för att rekonstruera heap-grafen från spårningen tas bort. I det här fallet rekommenderar vi att du samlar in en dump av processen för att diagnostisera problem med heapen.

• dotnet-gcdump verkar orsaka ett problem med slut på minne i en minnesbegränsad miljö.

  dotnet-gcdump fungerar genom att samla in en spårning av händelser som genereras av skräpinsamlaren under en inducerad generation 2-samling. Bufferten för händelseinsamling ägs av målprogrammet och kan växa upp till 256 MB. dotnet-gcdump använder också minne. Om din miljö är minnesbegränsad måste du ta hänsyn till dessa faktorer när du samlar in en gcdump för att förhindra fel.