前言：
前N天，一直在优化 秋色园 ，仍然纠结于access数据库锁问题，因为一旦被锁，只在网站涉及到读取数据库，基本上就不用打开了，下场仅有重启IIS。
为了解决这个并发锁问题，我是用心良苦，频繁出招，这些留下到“秋色园技术原理解析 系列”里写了。
过程：
这几天，对 秋色园 首页进程了极致优化，完全避开了Access数据库操作，利用Cookie+文本外置+后台线程，完全可以不理会数据库打开首页了，首页不用担心锁问题了。
经过重重优化，这几天没再发access锁住问题。
终于：前两天，却让人纠心的起了另一个问题：cpu高温不退，70%的时间维持在80%的使用率上，偶尔下降。
虽然不影响运行，但为了把这个率降下来，一直忙碌调整测试代码两天了。
最终：还没正面解决问题，现在好了，cpu基本0-10%以下，可是还是没正面纠出问题，只好做一下失败的总结。
CPU 基本就这状态：
CPU高温前，我都做了些什么[其实优化了很多，这里提最近的两点]：
1：优化生成静态页面的策略：
旧策略：页面被访问时概率性即时产生线程后台重新请求生成新数据页面。
新策略：页面被访问时，概率性将url添加到队列中，同一线程定时按顺序更新。
新策略：页面被访问时，概率性将url添加到队列中，同一线程定时按顺序更新。
2：优化访问统计策略：
旧策略：缓存用户访问和文章访问计数，概率性更新。
新策略：是将计数器放入队列，定时更新。
新策略：是将计数器放入队列，定时更新。
CPU高温是我在修改了这些策略后，才发生的，是偶尔，还是非偶尔，不得而知，但然改的不止这些，还有很多。。。
CPU高温后，我都做了些什么：
1：怀疑是不是新策略的问题引起的，做了以下措施：
1：降低重新生成界面的概率，加大生成页面间的休眠时间，然后更新dll，不见效。
2：直接屏蔽线程代码，更新，不见效。
3：加大访问统计的休眠时间，更新，不见效。
4：屏蔽访问统计，更新，不见效。
5：还有其它，比如输出统计url信息或统计信息，查看对象等。。。效果不大。
2：直接屏蔽线程代码，更新，不见效。
3：加大访问统计的休眠时间，更新，不见效。
4：屏蔽访问统计，更新，不见效。
5：还有其它，比如输出统计url信息或统计信息，查看对象等。。。效果不大。
2：本地开线程，模拟并发请求，做本地CPU测试：
1：写了个程序，本地开500线程，访问本机的iis，发现cpu上到50%。
2：注释掉生命周期代码，从代码的一开始加return,一步一步观察并发下的CPU状态，一路上，优化了不少，可惜更新到服务器上就是不见效。
2：注释掉生命周期代码，从代码的一开始加return,一步一步观察并发下的CPU状态，一路上，优化了不少，可惜更新到服务器上就是不见效。
这里不得不说，更新dll真是个地狱，缓存严重无法代替的地步：
1：编绎后上传复盖，仅是缓存失效，dll还是原来的。
2：回收应用程序池，也仅是新开进程，dll还是原来的。
3：重启IIS，这下好了吧，dll还是原来的。
4：把dll删除了，访问正常，再回收内存，新开了进程，提示加载错误，再上传，终于更新了。
---------------多么让人纠结的缓存。
2：回收应用程序池，也仅是新开进程，dll还是原来的。
3：重启IIS，这下好了吧，dll还是原来的。
4：把dll删除了，访问正常，再回收内存，新开了进程，提示加载错误，再上传，终于更新了。
---------------多么让人纠结的缓存。
3：vps有个一开始就装好的小骑士浏览监控工具，开了看一下：
有以下信息：
1：网站监控
2：流量监控
3：CPU监控
4：内存监控
5：硬盘写监控
6：硬盘读监控
可是都是一些大的统计，发现不了细节问题，纠结的又跳过了。
1：网站监控
2：流量监控
3：CPU监控
4：内存监控
5：硬盘写监控
6：硬盘读监控
可是都是一些大的统计，发现不了细节问题，纠结的又跳过了。
所以很纠结的说，自己的方法不成，只好走正规则手段，不得已学人家dump一下：
4：终于还是走正规路线，下个专业的分析工具dotTrace，折腾了两下，没了：
1：下了个最新版本，本地上折腾一下，只能随便看看不得要领，定位不到问题：
然后想到服务器试试，下了一个，装上，运行。
纠结的它，服务器运行不起来，还弹了不少错误，把应用程序池都给挂了，不知道是啥原因，只好卸载了。
2：还是dotTrace，下个早期版本V3.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 输出栈信息
好像就记得这么几个命令了，不是要领，发现不了问题，研究不下去。
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之后，再看不了详细信息，还是定位不到具体问题。
还可以看到有四个线程，一直占用着cpu，可惜除了线程ID之后，再看不了详细信息，还是定位不到具体问题。
见截图2张：
1：基本状态：
2：4个高线程：点击上图那个threads看到的。
纠结的，CPU莫名的好了，稳定了，不发烧了
再之后，不理了，把秋色园剩下的优化代码给写完，准备更新，这时候cpu又回落正常了，更新之后，cpu到目前为，正常了，不再发现高温现象。
留下的是失败的测试的可能性：
1：access数据库操作，Lock操作引起并发访问线程阻塞，导致cpu高。
2：搜索引擎发狂访问，见IIS日志和平时没两样，一样大小，应该不太可能。
3：大量网页同时发文章？只有发文章时，才会频繁写access数据库，可是数据库没有产生*.ldb文件，cpu也一样很高，不知道咋解释。
4：4个线程占用高的，是何许线程，没解。
5：其它....等一次再来过。
2：搜索引擎发狂访问，见IIS日志和平时没两样，一样大小，应该不太可能。
3：大量网页同时发文章？只有发文章时，才会频繁写access数据库，可是数据库没有产生*.ldb文件，cpu也一样很高，不知道咋解释。
4：4个线程占用高的，是何许线程，没解。
5：其它....等一次再来过。
带着些许纠结，写下这没结局的总结，夜静更深，4点了，纠结的睡了。
现在 秋色园 应该稳定了，大伙访问看看：http://www.cyqdata.com
版权声明：本文原创发表于博客园，作者为路过秋天，原文链接：
http://www.cnblogs.com/cyq1162/archive/2011/07/06/2098831.html