注：本文仅针对 DiscuzNT3.0, sqlserver 2000版本，其他版本请勿对号入座。

在本系列的第（4）篇中，我们提到过windbg，上次没能华丽登场的他，今天终于要一展才华了。解决问题是windbg与生俱来的功夫，他今天将怎么样来解决我们的问题，静听分解。

经过第（4）篇的优化之后，我们的论坛迎来了每日100万pv的突破性指标，相对于我们其他项目来说，这个量虽然不值一提，但毕竟这个项目是一切从0开始，能达到这个量也算是一个小突破，值得小庆祝一下。不过问题也随之而来了。我们的iis服务器的cpu占用率从之前的约30%,上升到了80%，按照我们的经验，这是不合理的，80%已经是一个危险的信号，随时都有可能引发server too busy。

从公司的利益角度来考虑，为了节约服务器资源和成本，当然要把cpu降下来；从技术人员的角度来考虑，如果你之前没解决过，这将是对自己的一个挑战，如果你解决了，就刚好是你价值的体现，正所谓乱世出英雄，这是一样的道理。好了，废话不多说，有请我们的今日之星windbg。  

关于windbg，网上有很多介绍，我就不再累述了。我只发表自己对他的两点认识，比较通俗：

1）可以抓取内存包，即dump文件；

2）通过命令输出内存中正在执行的动作；

第3）步是技术人员自己要做的事情，通过命令输出的信息，分析找出问题的症结。这一步windbg是帮不了你的。

网上关于windbg的最常解决的问题一般是

1）程序崩溃；

2）程序挂起，比如死锁，超时；

3）高cpu；

4）内存泄露；

我们今天就来看看他是怎么找到 3）高cpu 的问题的。

windbg定位高cpu一般常用的方法和步骤是：

1）在高cpu的时候间隔约5秒钟抓一个包，抓3个左右,用adplus 命令；

2）通过 !runaway 命令找出每个包的前几个线程（约10个）；

3）然后找出在每次的前10个线程里都出现的线程id；

4）通过 !clrstack 命名输出该线程的执行动作；

5）通过 第 4) 输出的信息找出问题的症结 

关于第5）点，我提点自己的看法，我一般就看这些个线程id都在干什么，如果他们10个里面有8个都停留在一个方法，那这个方法就很值得怀疑，是需要重点检查的，那到底dnt3.0情况如何，我们一步一步来看看。

1）首先抓包，在cmd下 通过adplus抓包，间隔10秒连抓3个（windbg命令的用法，不是本文的重点，google可以有一箩筐）；

2）用windbg分别打开3个dump文件，运行!runaway命令，找到耗时的线程；

 3个文件的截图如下：

第1张

 

第2张



第3张

3）找到10个最耗时的线程：11，12，21，22，34，38，40，46，47，48 。

4）通过!clrstack命令输出他们都在干什么（因为太多，这里只选几个代表性的） 

线程 11 :

---------------- 

 0:000> ~11s

24         } 

再看看 

再看 

挺复杂的，再看 

哦，到这里看明白了， SelectSingleNode 经过了如下流程最终得到了结果： 

创建 XmlDocument ——》 创建 XPathNavigator ——》 获取所有的节点Nodes ——》 返回第一个节点 

这样一个流程下来会耗多少性能呢，这个每个人的测试方式不一样，所以结果可能也会不一样，感兴趣的童鞋可以自己测试一下，因为我不熟悉这种缓存方案，无法预知他的性能，我只好改成自己熟悉的，最后用的系统自带的HttpRuntime.Cache来做缓存。 

改了缓存策略的效果还不错，cpu从之前的 >80% 降到了 <30%，抓个图：

作者: 鸽子飞扬 发表于 2011-06-18 18:41 原文链接