dotnet诊断工具记录

CPU爆高(cpu陡增,比如正常运行一般是x%的cpu,突然到了20% 30%甚至更高)

调试高 CPU 使用率

dotnet tool install --global dotnet-counters
和dotnet-trace配合使用收集dotnet程序信息,参见https://docs.microsoft.com/zh-cn/dotnet/core/diagnostics/debug-highcpu?tabs=windows
dotnet-trace ps # 获取pid
dotnet-counters monitor --refresh-interval 1 -p 22884 # 监视CPU使用率
dotnet-trace collect -p 22884 --providers Microsoft-DotNETCore-SampleProfiler  # --providers 是指定了所需的提供程序,是微软提供的应用程序,也可以不写
上一步收集,将收集.nettrace文件,可以使用vs 2022直接打开或者PerfView打开(推荐vs 2022)
打开后将会展示出CPU占比,自己忽略掉system等系统路径,查看到自己的代码路径,然后定位具体方法

内存泄漏(内存飙高或者出现oom)

调试内存泄露

dotnet tool install --global dotnet-dump # dotnet-counters 和 dotnet-dump 结合使用,也可以不进行监视,直接收集转储文件
dotnet-counters monitor --refresh-interval 1 -p 4807 # 查看GC Heap Size (MB) 这一行 ,可以忽略
dotnet-dump collect -p 4807 # 收集转储文件
dotnet-dump analyze core_20190430_185145 # 加载转储的文件
dumpheap -stat # 查看托管堆的整体状态,找到最后几行,给出的结果会按照从小到大排序,所以不用再往上面翻了
结果有四列 MT、Count、TotalSize、Class Name,查看TotalSize和Count最大的几个,然后用MT来做下一步
dumpheap -mt 00007faddaa50f90 # 查看当前MT对应的Class Name列表
输出结果Address、MT、Size ,然后用Address来做下一步
对Class Name实例使用 gcroot 命令,以查看对象的根方式和原因
gcroot -all 00007f6ad09421f8 # 可以将上一步的Address多查看几个,特别是size不同的,以免漏掉一些内存泄漏的地方
查看最后输出的HandleTable内容,一般就是自己所要查看内存泄漏的堆栈信息

死锁(无响应或线程累积问题)

调试 .NET Core 中的死锁

dotnet-dump collect -p 4807
dotnet-dump analyze  ~/.dotnet/tools/core_20190513_143916
threads # 如果确定已经线程飙高了,这句话可以不执行
clrstack -all # 如果确定已经线程飙高了,这句话可以不执行
syncblk # 找出实际持有监视器锁定的线程

将会出现类似于下面这种的输出,其中查看Thread这一列,对齐可以有问题,自己要看好Thread指的是死锁所在的线程ID

`
Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner
43 00000246E51268B8 603 1 0000024B713F4E30 5634 28 00000249654b14c0 System.Object
44 00000246E5126908 3 1 0000024B713F47E0 51d4 29 00000249654b14d8 System.Object

Original: https://www.cnblogs.com/spatxos/p/16664334.html
Author: spatxos
Title: dotnet诊断工具记录

原创文章受到原创版权保护。转载请注明出处:https://www.johngo689.com/582898/

转载文章受原作者版权保护。转载请注明原作者出处!

(0)

大家都在看

亲爱的 Coder【最近整理,可免费获取】👉 最新必读书单  | 👏 面试题下载  | 🌎 免费的AI知识星球