最近发布在windows server2012 IIS8.0上的一个WebAPI项目,才几十个人在线,CPU就会出现过百情况,并且CPU一旦过百应用程序池就自动暂停掉,看到这个问题我感觉应该是程序哪个地方出了问题, 8盒16G 应该配置还是可以的。打算使用windbg找到这个问题。
为了快速定位问题我就直接在生产环境安装了windbg,为了采集dump文件,我选择Procdump。Procdump无需安装,下载下来直接放到一个目录下即可。以下是解决问题的过程+截图:
步骤一:
安装windbg,注意32和64,要安装相应的版本,直接点击下一步即可。
步骤二:
Copy Procdump 文件到服务器上的一个目录下,目录没有限制
如图:C:\software\Procdump,这里的dbghelp.dll是从windbg安装目录下copy过来的,是我为了解决下面这个坑:调试High CPU问题的时候经常用到的一个命令是!runaway,但是有些时候!runway在ProcDump抓取的dump中提取不出来。解决的方法是将Debug Tools for Windows (windbg)安装目录下的dbghelp.dll拷贝到procdump目录下,然后再运行命令抓取dump。
0:000> !runaway ERROR: !runaway: extension exception 0x80004002.
"Unable to get thread times - dumps may not have time information"

步骤三:
在doc窗口下执行procdump命令,cd /d c:\Software\Procdump

步骤四:
执行procdum命令,执行 procdump -c 50 -s 4 -ma -n 3 w3wp 命令含义为:当w3wp.exe cpu超过50%,并且持续4秒,抓取3个dump文件存储起来,存储位置默认为procdump文件所在的目录。
如图:

出现如图结果证明已经进入监控状态。接下来就是等着CPU超过50%了。
没过一会就看到效果了

dump文件已经抓取到,我们来看下dump文件存储位置:

那么接下来就是开始分析了。
步骤五:
启动已经安装好的Windbg,开始分析采集的dump文件

步骤六:
为了不影响正在运行的项目,我将发布的项目文件单独从copy了一份出来,如图所示:我是web api项目

步骤七:
设置系列目录:
Windbg->file->Symbol File Path

Windbg->file->Source File Path

步骤八:
加载dump文件
Windbg->file->open Crash Dump

先选择第一个dump文件。

步骤九:
载入sos.dll 执行.load C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.DLL
我是4.0 的 注意版本 64位

步骤十:
!threadpool 查看当前CPU状况 线程数等等

步骤十一:
执行 !runaway 命令 查看那几个线程使用的高

步骤十二:
~线程IDs 跳转到那个线程

步骤十三:
!clrstack 看看这个线程再干嘛 执行那些方法

步骤十四:
将图中红框列出来的方法去项目中查找下,发现了问题:

重载方法的时候参数传递不正确,出现了死循环,至此问题得到了解决。
原文出处:http://www.mamingbo.com/page/yunwei/109/index.htm |