秋色园CPU百分百的原因分析
事件发生前：
近些天没事重构了秋色园的许多代码，更新后，一开始没觉的有啥问题，多次更新后，秋色园这两天变的不稳定了，经常性的出现Cpu满100%的情况。
CPU百分百问题是很纠结的：
CPU百分百问题，是我一直很纠结的问题，问题不好寻，搜遍互联网，也没一个可靠简单的解决方案，只能靠经验来折腾排查。
那些Dump的，几年前就折腾过，找不到源头。。。
怀疑最近对秋色园的可能性改动：
由于CPU问题，是近几天才发现，但是近些天改动的代码，被重的好像还不少，一时不知从何下手。
于是从CYQ.Data的CacheManager下手，这是cyq.data内部的缓存类，最近对内部存储缓存附加信息的数据字典，进行了并发加锁的改进，一开始以为是lock机制导致了死锁引发的。
开始初步排查：
于是还原代码。。还停掉了同步缓存和附加信息机制的内部线程，最终发现，CPU问题，还是一样存在，初步排除了这个原因。
接下来又检查了所有的线程代码，查了一次又一次，发现子线程，检测所有while循环的代码，也没啥过火的事。
还是排查一下，停掉了所有的子线程，等了一些时间，终于出来Cpu百分百，所以好像也不是这问题。
顺带的代码优化改进：
接着，又重找所有的逻辑代码，觉的在代码的优雅和性能提升上，还是选择性能好了，于是改进了整个逻辑的代码：
优雅些的：
int count;
using (MAction action = new MAction(U_QBlogAdEnum.Blog_Ad))
{
action.Select(Pager1.PageIndex, Pager1.PageSize, GetSearchWhere(), out count).Bind(rptList);
Pager1.RecordCount = count;
}
性能些的：
int count;
MDataTable dt = null;
using (MAction action = new MAction(U_QBlogAdEnum.Blog_Ad))
{
dt = action.Select(Pager1.PageIndex, Pager1.PageSize, GetSearchWhere(), out count);
}
dt.Bind(rptList);
Pager1.RecordCount = count;
大体类似这么些代码，其实就一个原则，尽最快的速度，释放数据库链接的占用。
问题还有,迷茫状态：
暂停掉了页面缓存，直接访问，感觉好像爽多了。
不过这仍不是问题所在，过了近个小时，CPU问题又来临了。
于是查了事件查看器，看看有没有未捕获的异常，发现了几个特殊小点，解决了。
又查下了数据库操作异常的日志，发现没啥特别。
又查了下CYQ.Data Log记录的非数据库操作记录下的文本异常，也没发觉异常的事。
之后又上网查了查，看了几篇文章，基本也没啥头绪。
回忆起昨日时光：
突然想去下午，我停掉了数据库，让秋色园处于无数据库状态运行，然后去吃饭的场影。
意思大概就是，没有数据库，秋色园可以依赖静态页面，也基本不影响访问功能。
会不会是数据库链接引发的？
数据库排查一：
于是把研究方向，临时转向了查数据库。
去掉页面缓存，通过按住F5按钮，持续刷新，来观察远程的CPU，发现CPU瞬时变化很快。
（中间改进了整体框架的代码，尽量早的关键链接，发现瞬时下降的速度也快了）
说明这VPS的CPU经不起动荡啊~~~
不过好像怎么刷，CPU虽临时高，但也瞬时降下来了，没发现持续百分百状态。
数据库排查二：
之后，我在服务器开启了SQL 事件探查器，偶尔发现一条搜索的like查询，被频繁的调用，而这个查询的时间基本上是300多毫秒，cpu也是其它查询的10倍时长，于是我对这条查询感兴趣了。
之个查询是：秋色园的关键字产生的（人称“TAG”标签，搜索引擎抓取的时候，会产生瞬时数据库查询，抓的多，把CPU也抓完了）
于是我的策略是优化搜索引擎引发的实时查询，通过简化语句，但还是存在查义气，感觉好像CPU似乎是正常了，这时候，都早上快八点了，天都亮了好久，我以为没啥事了，跑去睡觉了。
数据库排查三：
中午十二点多起床，发现又存在CPU高温问题，查看了下，好像CPU被引发时，该查询产生比较多，因为一些开着SQL探查器，所以可以看到。
于是，取消优化机制，直接屏蔽搜索引擎的实时查询，然后优化了该查询语句，目前基本手工的查询，时间和cpu占用和其它的查询语句差不多。
目前，过去两三个小时了，一切正常。。。有等持续继续观望。。。
秋色园是QBlog的官方站点,由路过秋天创建,基于cyqdata数据层框架开发的支持多用户、多语言、多数据库(access,mssql,oracle)、目录级url等功能强大的博客系统
"2013/3/22 16:30:59 | 记录点滴 | |
- #5游客[注册][122.224.230.*]2013/3/26 9:06:44
- 曾经被搜索引擎这样搞过，链接字符串中默认连接池的连接数的默认值改大，是连接数被占光引起的。
- #4Mr.Right2013/3/26 4:46:42
- 很受用，赞！
- #3路过秋天2013/3/23 21:54:57
- 目前已重了很多的代码。。。
- #2游客[注册][124.236.246.*]2013/3/22 20:49:29
- 只看最后一个截图 Year(CreateTime)用函数实在不咋地
回复： 那个应该是文章档案的年份查询日志。
- #1游客[注册][58.30.28.*]2013/3/22 17:21:21
- 是滴是滴