秋色园CPU高温优化-两天两夜吐血失败经验总结

前言：

 

前N天，一直在优化 秋色园 ，仍然纠结于access数据库锁问题，因为一旦被锁，只在网站涉及到读取数据库，基本上就不用打开了，下场仅有重启IIS。

 

为了解决这个并发锁问题，我是用心良苦，频繁出招，这些留下到“秋色园技术原理解析 系列”里写了。

 

过程：

 

这几天，对 秋色园 首页进程了极致优化，完全避开了Access数据库操作，利用Cookie+文本外置+后台线程，完全可以不理会数据库打开首页了，首页不用担心锁问题了。

 

经过重重优化，这几天没再发access锁住问题。

 

终于：前两天，却让人纠心的起了另一个问题：cpu高温不退，70%的时间维持在80%的使用率上，偶尔下降。

 

虽然不影响运行，但为了把这个率降下来，一直忙碌调整测试代码两天了。

 

最终：还没正面解决问题，现在好了，cpu基本0-10%以下，可是还是没正面纠出问题，只好做一下失败的总结。

 

CPU 基本就这状态：

 

CPU高温前，我都做了些什么[其实优化了很多，这里提最近的两点]：

 

1：优化生成静态页面的策略：

 

旧策略：页面被访问时概率性即时产生线程后台重新请求生成新数据页面。

新策略：页面被访问时，概率性将url添加到队列中，同一线程定时按顺序更新。

 

2：优化访问统计策略：

 

旧策略：缓存用户访问和文章访问计数，概率性更新。

新策略：是将计数器放入队列，定时更新。

 

 

CPU高温是我在修改了这些策略后，才发生的，是偶尔，还是非偶尔，不得而知，但然改的不止这些，还有很多。。。

 

CPU高温后，我都做了些什么：

 

1：怀疑是不是新策略的问题引起的，做了以下措施：

 

1：降低重新生成界面的概率，加大生成页面间的休眠时间，然后更新dll，不见效。

2：直接屏蔽线程代码，更新，不见效。

3：加大访问统计的休眠时间，更新，不见效。

4：屏蔽访问统计，更新，不见效。

5：还有其它，比如输出统计url信息或统计信息，查看对象等。。。效果不大。

 

2：本地开线程，模拟并发请求，做本地CPU测试：

 

1：写了个程序，本地开500线程，访问本机的iis，发现cpu上到50%。

2：注释掉生命周期代码，从代码的一开始加return,一步一步观察并发下的CPU状态，一路上，优化了不少，可惜更新到服务器上就是不见效。

 

 

这里不得不说，更新dll真是个地狱，缓存严重无法代替的地步：

 

1：编绎后上传复盖，仅是缓存失效，dll还是原来的。

2：回收应用程序池，也仅是新开进程，dll还是原来的。

3：重启IIS，这下好了吧，dll还是原来的。

4：把dll删除了，访问正常，再回收内存，新开了进程，提示加载错误，再上传，终于更新了。

---------------多么让人纠结的缓存。

 

3：vps有个一开始就装好的小骑士浏览监控工具，开了看一下：

 

有以下信息：

1：网站监控

2：流量监控

3：CPU监控

4：内存监控

5：硬盘写监控

6：硬盘读监控

可是都是一些大的统计，发现不了细节问题，纠结的又跳过了。

 

所以很纠结的说，自己的方法不成，只好走正规则手段，不得已学人家dump一下：

 

4：终于还是走正规路线，下个专业的分析工具dotTrace，折腾了两下，没了：

 

1：下了个最新版本，本地上折腾一下，只能随便看看不得要领，定位不到问题：

然后想到服务器试试，下了一个，装上，运行。

纠结的它，服务器运行不起来，还弹了不少错误，把应用程序池都给挂了，不知道是啥原因，只好卸载了。

2：还是dotTrace，下个早期版本V3.1试试，结果本地都运行不起来，只好又给卸载了。

 

 

5：好了，专业点，用windb，下了个新版本，2009年的，网上看了下教程，勉强学会几条命令和步骤：

 

1：下载，微软那下，地址忘了，搜索吧。

2：安装，运行。

3：要dump一个*.dmp文件出来[几百M]，附加w3wp进程：

这一步我很纠结，网上写着执行用vbs 什么命令的，找不到这命令到哪执行...

我只好附加进程，然后才看到命令，输入：.dump /ma d:\1.dmp，这才产生了一个几百M的文件。

这里又有个问题，附加进程后，原来进程IIS访问不了，cpu看到的是0，可是dump出来显示的cpu还是80%多，不知道是啥怪现象。

还有一个问题，停止debug后，原来的w3wp进程竟然挂了，这让我很纠结。



因为：网上教程都是dump几个文件，然后比较相同的线程时间，来判断一个线程执行的时长定为问题点。

可是我dump一个原来进程就挂了，再重新dump的进程就不一样了，这个怎么比较。

只好随便看看一个文件了。

4：配置symbol符号：

5：加载*.dmp文件。

6：开始敲命令了：

！threads 输出非托管线程

!runaway 输出每个线程的执行时间

.time 输出汇总时间

~124s: 124是线程id，切换到124线程中

.clrstack 输出栈信息

好像就记得这么几个命令了，不是要领，发现不了问题，研究不下去。

 

6：专业不成，又非专业一下，procxp.exe，一个小工具。

 

朋友给我发了一个procxp.exe，轻轻一运行，基本轻松可以看到上面辛苦dump的信息。

还可以看到有四个线程，一直占用着cpu，可惜除了线程ID之后，再看不了详细信息，还是定位不到具体问题。

 

见截图2张：

1：基本状态：

 

2：4个高线程：点击上图那个threads看到的。

 

纠结的，CPU莫名的好了，稳定了，不发烧了

 

再之后，不理了，把秋色园剩下的优化代码给写完，准备更新，这时候cpu又回落正常了，更新之后，cpu到目前为，正常了，不再发现高温现象。

 

留下的是失败的测试的可能性：

 

1：access数据库操作，Lock操作引起并发访问线程阻塞，导致cpu高。

2：搜索引擎发狂访问，见IIS日志和平时没两样，一样大小，应该不太可能。

3：大量网页同时发文章？只有发文章时，才会频繁写access数据库，可是数据库没有产生*.ldb文件，cpu也一样很高，不知道咋解释。

4：4个线程占用高的，是何许线程，没解。

5：其它....等一次再来过。

 

 

带着些许纠结，写下这没结局的总结，夜静更深，4点了，纠结的睡了。

 

现在 秋色园 应该稳定了，大伙访问看看：http://www.cyqdata.com