CPU 及内存占用过大,这也是我们日常调试工作中最常见的两个问题
首先附上两链接
一个样例演示
http://www.cnblogs.com/xioxu/archive/2009/09/04/1560326.html
一点文档信息
http://www.cnblogs.com/kissdodog/p/3731743.html
- 抓取 Dump 文件
可以用工具或系统自带的命令抓取Minidump文件,但是用任务管理器抓取的是FullDump文件比较大,信息比较多,但多余的信息也多 - 使用 Windbg 调试 Dump 文件
(1) 启动 Windbg 打开 Dump 文件 (File -> Open Crash Dump...)
(2) 载入 SOS.dll
--1、元命令loadby加载SOS .net版本相同
0:000> .load sos
0:000> .loadby sos mscorwks
Unable to find module 'mscorwks'
--2、元命令load加载SOS .net版本不相同
如果使用的.Net版本不同,那么还可以手动指定版本,如手动指定载入4.0版本命令:
.load C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/sos.dll
.load C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/sos.dll
如果是64位,那么应该加载如下sos.dll
.load C:/Windows/Microsoft.NET/Framework64/v2.0.50727/sos.dll
.load C:/Windows/Microsoft.NET/Framework64/v2.0.50727/sos.dll
(3) 对于 CPU 占用过高的问题,别忘了 ThreadPool 也可能是造成问题的根源。
0:000> !threadpool
可以看到线程池对cpu的利用率,线程数量,上限
(4) 我们看看是哪个线程占用 CPU 时间过多。
0:000> !runaway
(5) 切换到该线程,查看调用堆栈。
0:000> ~3 s
这里3是要切换的线程id序号在上面runaway里会显示序号
0:003> !clrstack
会显示当前线程托管代码的调用堆栈
(6) 看看这个 "Learn.CUI.Program.
0:003> !name2ee * dumptest.Program
name2ee显示指定模块中指定类型或方法的MethodTable结构和EEClass结构,然后就能看到模块或方法表的地址了
(7)导出模块
0:003> !dumpdomain
就可以使用MSIL反汇编器 (Ildasm.exe) 浏览模块或方法表 也可以用Reflector.exe 或者最新流行的ILSpy.exe(推荐)
然后可以查看是否是gc出了问题
大对象堆在进行full gc会耗时比较久
0:003> !eeheap -gc
显示被公共语言运行时内部数据结构使用的进程内存的有关信息
可以发现是否有内存占用比较大的段
(8) 查证这些大户的身份。
0:003> !dumpheap -min 85000 -stat
大于等于85000KB的就是大对象了
然后看是那种类型的大对象造成的
(9) 找出大户的具体内存地址。
0:003> !dumpheap -type Byte[] -min 85000
这里你找出的假设是Byte[]类型
然后会列出这种类型大对象的地址
(10) 挑一个出来,看看谁持有该大户的引用。
0:003> !gcroot 022d3250
显示对在指定地址上的一个对象的引用(或根)信息。
往上接着找找到调用它的根对象或你觉得能看出猫腻的对象
0:003> !do 012d2e2c
然后会列出对象的字段信息,和名字
然后你能根据包含的类型,和根对象的名字,根对象类型取代码里找到可能出问题的地方了。
如果cpu占用率高可以通过前面的!threadpool 或其它方式看到CPU utilization 99%,找到可能出问题的线程在压缩或者计算啥的
ProcInfo [-env] [-time] [-mem]
显示针对该进程的环境变量、内核CPU时间和内存使用统计
另外建议直接使用Jetbrains的dotMemory看内存对象数量泄露等 和 dotTrace工具看哪些东西被调用多少次,占用率等