.NET Core-全局性能診斷工具

本文轉載自查看原文 2021-05-09 20:30 2793 診斷工具/ DUMP/ ASP.NET Core

前言：

　現在.NET Core 上線后，不可避免的會出現各種問題，如內存泄漏、CPU占用高、接口處理耗時較長等問題。這個時候就需要快速准確的定位問題，並解決。

　這時候就可以使用.NET Core 為開發人員提供了一系列功能強大的診斷工具。

　接下來就詳細了解下：.NET Core 全局診斷工具

dotnet-counters
dotnet-dump
dotnet-gcdump
dotnet-trace
dotnet-symbol
dotnet-sos

1、dotnet-counters：

　簡介：dotnet-counters 是一個性能監視工具，用於初級運行狀況監視和性能調查。它通過 EventCounter API 觀察已發布的性能計數器值。例如，可以快速監視CUP使用情況或.NET Core 應用程序中的異常率等指標

　安裝：通過nuget包安裝：

dotnet tool install --global dotnet-counters

　主要命令：　

dotnet-counters ps
dotnet-counters list
dotnet-counters collect
dotnet-counters monitor

　a）dotnet-counters ps：顯示可監視的 dotnet 進程的列表

　b）dotnet-counters list命令：顯示按提供程序分組的計數器名稱和說明的列表

　包括：運行時和Web主機運行信息

　c）dotnet-counters collect 命令：定期收集所選計數器的值，並將它們導出為指定的文件格式

dotnet-counters collect [-h|--help] [-p|--process-id] [-n|--name] [--diagnostic-port] [--refresh-interval] [--counters <COUNTERS>] [--format] [-o|--output] [-- <command>]

　參數說明：

　示例：收集dotnet core 服務端所有性能計數器值，間隔時間為3s

　d）dotnet-counters monitor命令：顯示所選計數器的定期刷新值

dotnet-counters monitor [-h|--help] [-p|--process-id] [-n|--name] [--diagnostic-port] [--refresh-interval] [--counters] [-- <command>]

　　示例： dotnet-counters monitor --process-id 18832 --refresh-interval 2

2、dotnet-dump：

　簡介：通過 dotnet-dump 工具，可在不使用本機調試器的情況下收集和分析 Windows 和 Linux 核心轉儲。
　安裝：

dotnet tool install --global dotnet-dump

　命令：

dotnet-dump collect
dotnet-dump analyze

　a) dotnet-dump collect：從進程生成dump

dotnet-dump collect [-h|--help] [-p|--process-id] [-n|--name] [--type] [-o|--output] [--diag]

　　參數說明：


-h\|--help	顯示命令行幫助。
-p\|--process-id <PID>	指定從中收集轉儲的進程的 ID 號。
-n\|--name <name>	指定從中收集轉儲的進程的名稱。
--type <Full\|Heap\|Mini>	指定轉儲類型，它確定從進程收集的信息的類型。有三種類型： Full - 最大的轉儲，包含所有內存（包括模塊映像）。 Heap - 大型且相對全面的轉儲，其中包含模塊列表、線程列表、所有堆棧、異常信息、句柄信息和除映射圖像以外的所有內存。 Mini - 小型轉儲，其中包含模塊列表、線程列表、異常信息和所有堆棧
-o\|--output <output_dump_path>	應在其中寫入收集的轉儲的完整路徑和文件名。如果未指定：在 Windows 上默認為 .\dump_YYYYMMDD_HHMMSS.dmp 。在 Linux 上默認為 ./core_YYYYMMDD_HHMMSS 。 YYYYMMDD 為年/月/日，HHMMSS 為小時/分鍾/秒。
--diag	啟用轉儲收集診斷日志記錄。

示例：dotnet-dump collect -p 18832

　b）dotnet-dump analyze：啟動交互式 shell 以了解轉儲

dotnet-dump analyze <dump_path> [-h|--help] [-c|--command]

　　示例：dotnet-dump analyze dump_20210509_193133.dmp 進入dmp分析，查看堆棧和未處理異常

　　Sos命令列表：

命令	函數
`soshelp`	顯示所有可用命令
`soshelp\|help <command>`	執行指定的命令。
`exit\|quit`	退出交互模式。
`clrstack <arguments>`	僅提供托管代碼的堆棧跟蹤。
`clrthreads <arguments>`	列出正在運行的托管線程。
`dumpasync <arguments>`	顯示有關垃圾回收堆上異步狀態機的信息。
`dumpassembly <arguments>`	顯示有關指定地址處程序集的詳細信息。
`dumpclass <arguments>`	顯示有關指定地址處的 `EEClass` 結構的信息。
`dumpdelegate <arguments>`	顯示有關指定地址處的委托的信息。
`dumpdomain <arguments>`	顯示所有 AppDomain 和指定域中的所有程序集的信息。
`dumpheap <arguments>`	顯示有關垃圾回收堆的信息和有關對象的收集統計信息。
`dumpil <arguments>`	顯示與托管方法關聯的 Microsoft 中間語言 (MSIL)。
`dumplog <arguments>`	將內存中壓力日志的內容寫入到指定文件。
`dumpmd <arguments>`	顯示有關指定地址處的 `MethodDesc` 結構的信息。
`dumpmodule <arguments>`	顯示有關指定地址處的模塊的信息。
`dumpmt <arguments>`	顯示有關指定地址處的 `MethodTable` 的信息。
`dumpobj <arguments>`	顯示有關位於指定地址處的對象的信息。
`dso\|dumpstackobjects <arguments>`	顯示在當前堆棧的邊界內找到的所有托管對象。
`eeheap <arguments>`	顯示有關內部運行時數據結構所使用的進程內存的信息。
`finalizequeue <arguments>`	顯示所有已進行終結注冊的對象。
`gcroot <arguments>`	顯示有關對指定地址處的對象的引用（或根）的信息。
`gcwhere <arguments>`	顯示傳入參數在 GC 堆中的位置。
`ip2md <arguments>`	顯示 JIT 代碼中指定地址處的 `MethodDesc` 結構。
`histclear <arguments>`	釋放由 `hist*` 命令系列使用的任何資源。
`histinit <arguments>`	從保存在調試對象中的壓力日志初始化 SOS 結構。
`histobj <arguments>`	顯示與 `<arguments>` 相關的垃圾回收壓力日志重定位。
`histobjfind <arguments>`	顯示在指定地址處引用對象的所有日志項。
`histroot <arguments>`	顯示與指定根的提升和重定位相關的信息。
`lm\|modules`	顯示進程中的本機模塊。
`name2ee <arguments>`	顯示 `<argument>` 的 `MethodTable` 和 `EEClass` 結構。
`pe\|printexception <arguments>`	顯示從 Exception 類派生的 `<argument>` 的任何對象。
`setsymbolserver <arguments>`	啟用符號服務器支持
`syncblk <arguments>`	顯示 SyncBlock 持有者信息。
`threads\|setthread <threadid>`	設置或顯示 SOS 命令的當前線程 ID。

3、dotnet-gcdump：

　簡介：dotnet-gcdump 工具可用於為活動 .NET 進程收集 GC（垃圾回收器）轉儲。

　　dotnet-gcdump 全局工具使用 EventPipe 收集實時 .NET 進程的 GC（垃圾回收器）轉儲。創建 GC 轉儲時需要在目標進程中觸發 GC、開啟特殊事件並從事件流中重新生成對象根圖。此過程允許在進程運行時以最小的開銷收集 GC 轉儲。

　　這些轉儲對於以下幾種情況非常有用：

比較多個時間點堆上的對象數。
分析對象的根（回答諸如“還有哪些引用此類型的內容？”等問題）。
收集有關堆上的對象計數的常規統計信息。

　安裝：

dotnet tool install --global dotnet-gcdump

　示例：從當前正在運行的進程中收集 GC 轉儲

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

　參數說明：

參數	說明：
-h\|--help	顯示命令行幫助。
-p\|--process-id <pid>	可從中收集 GC 轉儲的進程 ID。
-o\|--output <gcdump-file-path>	應寫入收集 GC 轉儲的路徑。默認為 .\YYYYMMDD_HHMMSS_<pid>.gcdump。
-v\|--verbose	收集 GC 轉儲時輸出日志。
-t\|--timeout <timeout>	如果收集 GC 轉儲的時間超過了此秒數，則放棄收集。默認值為 30。
-n\|--name <name>	可從中收集 GC 轉儲的進程的名稱。

　生成示例：dotnet-gcdump collect -p 18832

　查看生成文件：使用perfview查看：

4、dotnet-trace：

　簡介：分析數據通過 .NET Core 中的 EventPipe 公開。通過 dotnet-trace 工具，可以使用來自應用的有意思的分析數據，這些數據可幫助你分析應用運行緩慢的根本原因。
　安裝：

dotnet tool install --global dotnet-trace

　命令：

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

　常用命令：

命令	說明
dotnet-trace collect	從正在運行的進程中收集診斷跟蹤，或者啟動子進程並對其進行跟蹤（僅限 .NET 5+）。若要讓工具運行子進程並自其啟動時對其進行跟蹤，請將 `--` 追加到 collect 命令。
dotnet-trace convert	將 `nettrace` 跟蹤轉換為備用格式，以便用於備用跟蹤分析工具。
dotnet-trace ps	列出可從中收集跟蹤的 dotnet 進程。
dotnet-trace list-profiles	列出預生成的跟蹤配置文件，並描述每個配置文件中包含的提供程序和篩選器。

　示例：收集進程18832診斷跟蹤：

使用Vs打開生成的跟蹤文件如下：

5、dotnet-symbol：

　簡介：dotnet-symbol 用於下載打開核心轉儲或小型轉儲所需的文件（符號、DAC/DBI、主機文件等）。如果需要使用符號和模塊來調試在其他計算機上捕獲的轉儲文件，請使用此工具。
　安裝：

dotnet tool install --global dotnet-symbol

　命令：

dotnet-symbol [-h|--help] [options] <FILES>

　options：

參數	說明
--microsoft-symbol-server	添加“http://msdl.microsoft.com/download/symbols”符號服務器路徑（默認）。
--server-path <symbol server path>	將符號服務器添加到服務器路徑。
authenticated-server-path <pat> <server path>	使用個人訪問令牌 (PAT) 將經過身份驗證的符號服務器添加到服務器路徑。
--cache-directory <file cache directory>	添加緩存目錄。
--recurse-subdirectories	處理所有子目錄中的輸入文件。
--host-only	僅下載 lldb 加載核心轉儲所需的主機程序（即 dotnet）。
--symbols	下載符號文件（.pdb、.dbg 和 .dwarf）。
--modules	下載模塊文件（.dll、.so 和 .dylib）。
--debugging	下載特殊的調試模塊（DAC、DBI 和 SOS）。
--windows-pdbs	當可移植的 PDB 也可用時，會強制下載 Windows PDB。
-o, --output <output directory>	設置輸出目錄。否則，請在輸入文件旁邊寫入（默認）。
-d, --diagnostics	啟用診斷輸出。
-h\|--help	顯示命令行幫助。