[汇报]昨天晚上博客园的程序又出现了问题

    首先我再次向大家道歉!请大家谅解!
    昨天晚上我九点钟回来, 发现博客园又出现了老问题,访问速度很慢,几乎无法访问,经常出现“Server Application Unavailable ”错误,灵感之源反映晚上6点多钟就出现问题了。自从程序升级之后,这个问题一直困扰着博客园。以前也偶尔出现过这个问题,但升级之后,更频繁了。
    昨天早上,我将程序从CSDN提供的服务器上迁移到原来的服务器,以便找出问题的真正原因。迁移后,昨天白天运行很正常。
    出现问题时,服务器CPU一直处于100%。主要是SQL Server与asp.net 进程占用了CPU。我用SQL事件探查器进行跟踪,发现blog_GenericGetEntries_10与blog_GenericGetPagedEntries_10这两个存储过程执行时间很长,有时长达5、6秒,这是博客园的程序使用最频繁的存储过程,程序升级后,增加了对这两个存储过程的调用,首页与每个网站分类都会调用这两个存储过程。SQL事件探查器中,偶尔出现的audit logout,执行时间更长,要几十秒,有时甚至要几分钟。audit logout究竟是什么?是什么引起audit logout?audit logout与.Net SqlClient Data Provider有什么关系?在SQL事件探查器中,audit logout事件的ApplicationName是.Net SqlClient Data Provider。请高手指点。
    我仔细分析了blog_GenericGetEntries_10与blog_GenericGetPagedEntries_10,blog_GenericGetPagedEntries_10是一个分页的存储过程,调用了blog_GenericGetEntryIDs_10。唯一怀疑有问题的地方就是在这两个存储过程(blog_GenericGetEntries_10、blog_GenericGetPagedEntries_10)中每个查询语句都用到了with(nolock)。不知.Text中什么要使用with(nolock)?我的猜测是有可能是with(nolock) 引起了SQL Server死锁。现在我已经去掉了查询语句中 的with(nolock) , 看看是否还会出现问题?
    希望大家献计献策,分析一下这个问题的原因并提供一些解决方案。
    我在网上找到的一些相关文章:
    http://forums.aspfree.com/t22127/s.html
    http://www.devmanclub.com/showpost.aspx?postid=2432#2432
posted @ 2004-08-04 09:24 dudu 阅读(5553) 评论(31) 编辑 收藏

 回复 引用   
#1楼 2004-08-04 09:43 steeven
建议利用页面缓存把首页等几个常用页面根据参数缓存60Sec。

 回复 引用   
#2楼 2004-08-04 09:47 dudu
一直在采用缓存, 几乎每个页面都有缓存, 首页缓存设的就是60Sec.
 回复 引用   
#3楼 2004-08-04 09:50 Meyer
.text默认就是有缓存
cnblogs也一直使用缓存

 回复 引用   
#4楼 2004-08-04 09:52 steeven
哦?这两个sp单独执行要多长时间?
是不是导数据库把索引弄丢了?

 回复 引用   
#5楼 2004-08-04 10:11 smilnet
1.安装一个资源回收工具看看~~~~SQL和.Net占用的资源太多啦~~
 回复 引用   
#6楼 2004-08-04 10:12 dudu
索引都在。
 回复 引用   
#7楼 2004-08-04 10:20 dudu
事件日志情况:
1、2004-08-03 14:46
aspnet_wp.exe  (PID: 2432) was recycled because memory consumption exceeded the 306 MB (60 percent of available RAM).
2、2004-08-03 14:46
aspnet_wp.exe  (PID: 2520) stopped unexpectedly.
3、2004-08-03 15:50
aspnet_wp.exe  (PID: 2236) was recycled because memory consumption exceeded the %2 MB (%3 percent of available RAM).

从2004-08-03 17:53开始
先是出现
事件ID 1001: aspnet_wp.exe  (PID: 1728) was recycled because memory consumption exceeded the %2 MB (%3 percent of available RAM).
然后是每分钟出现一次
事件ID 1000: aspnet_wp.exe  (PID: 1696) stopped unexpectedly.
直到博客园恢复正常。

 回复 引用   
#8楼 2004-08-04 14:10 鞠强
dudu,你可以使用adplus把dump文件抓下来。如果你和M$的人有商务关系,可以把dump提交给上海M$的技术支持中心。

我们遇到过这个问题,最后分析dump文件,是我的一段调用unmanged  code发生了缓冲区溢出,而在GC回收的时候导致了错误。当时重现这个错误的时候,只要把GC立刻执行的全局变量设置上,立刻就能看到这个错误。

aspnet_wp crash掉,反正原因有n种。我想你最好是分析dump文件,否则不好找。

 回复 引用   
#9楼 2004-08-04 14:31 Wintle
弱 弱 的问一句,MDAC是不是已经是最新版? 

之前我们的服务器在访问量很大的时候,也会出现这个错误,一直和你现在一样找不到原因,后来想起,当时正好是重装系统后才出的问题,然后把MDAC升到最新版,就OK了...


 回复 引用   
#10楼 2004-08-04 15:15 dudu
晕!刚才检查了一下MDAC的版本,竟然是2.7。现在已经安装了MDAC 2.8。
难道是这个原因?但本来CSDN提供的服务器上的MDAC是2.8.

 回复 引用   
#11楼 2004-08-04 15:38 Wintle
刚才又看到一次报错信息,发现首页的博客排行榜,每行记录似乎都要再到数据库中去找二次链接信息,可能这里的开销很大,可不可以试图通过视图的方式一次性取出来,直接绑到repeater上,这样也许会好一些。

没有看到源码,不确切哈。

 回复 引用   
#12楼 2004-08-04 15:52 dudu
刚才不知为什么SQL Server将CPU占光了。重启SQL Server才恢复正常。
博客排行榜是一次查询, 然后再绑定到repeater, 没有进行二次查询。

 回复 引用   
#13楼 2004-08-05 02:28 rickie
DUDU,

1,关于“事件日志情况”的问题
我曾工作的一家公司的Web Server/IIS也出现这种现象,后来将操作系统Windows 2000 Adv. Server进行升级到services Pack 4,就解决了这个问题(M$建议);

2,关于SQL查询语句中with (nolock)
我认为这是非常必要的,针对一些Traffic非常高的SQL Server中的Table, 采用with nolock,可以不添加共享锁和排它锁,提高SQL Server并发效率,因此对一些实时性要求不高的系统,with nolock是非常重要的。

 回复 引用   
#14楼 2004-08-05 02:34 rickie
In addition, there is a web server monitor tool in my blog, which can be used to check web server status.
* I hope it's helpful to overcome the current problem. thanks.

 回复 引用   
#15楼 2004-08-05 07:28 dudu
@rickie
1. 博客园的服务器用的是Windows 2000 Adv, 早就升级到services Pack 4.
2. 你对with (nolock)分析很有道理, .Text的作者可能也是出于这个目的.
3. 你的server monitor tool好像只能监视请求的内容长度.


 回复 引用   
#16楼 2004-08-05 11:30 吕震宇
blog_GenericGetEntries_10存储过过程的内容是什么?为什么我下载的.TEXT 0.95中没有呀?
 回复 引用   
#17楼 2004-08-05 11:45 dudu
博客园的程序是在.Text 0.96上修改的。
存储过程下载: http://www.cnblogs.com/Files/dudu/cnblogsSP.rar
解压密码: cnblogs.com

 回复 引用   
#18楼 2004-08-05 12:04 吕震宇
正在下载。有个建议:

如果确认存储过程本身没有什么问题,估计是在什么资源上出现争用,造成某个线程等待时间过长。SQL 企业管理器左侧管理里面有个当前活动,可以获得一个当前所有进程的快照,并提供那些进程正在阻塞、那些进程造成阻塞,还有当前执行的命令是什么。可以看看什么进程造成了阻塞。

同时使用命令:SELECT * FROM master.dbo.sysprocesses where ecid = 0也可以获取相应资源,关于master.dbo.sysprocesses 可以参考SQL Server联机帮助。建议将其放到你的存储过程中,将结果输出到一个临时表什么的,然后查找一下到底是谁造成了阻塞。

CodeProject中有篇文章《Finding 'who is' using SQL Server》介绍的就是这方面的东西。你可以找找。

 回复 引用   
#19楼 2004-08-05 13:49 dudu
@吕震宇
非常感谢你的建议!
出现问题时, 我查看过进程信息, 没发现什么异常。但也有可能是我没看仔细。
现在在首页我已经减少对blog_GenericGetEntries_10的调用。到现在为止还没出现问题。
现在还有一个问题就是下面的异常:
aspnet_wp.exe (PID: 2268) was recycled because memory consumption exceeded the 306 MB (60 percent of available RAM).
aspnet_wp.exe (PID: 1628) stopped unexpectedly.



 回复 引用   
#20楼 2004-08-09 21:16 韩磊[未注册用户]
CSDN Blog也大量调用了这两个存储过程,没有出现任何问题。
 回复 引用   
#21楼 2004-08-10 07:11 dudu
这两个存储过程的确不是引起问题的原因。
我通过两种处理方法解决了问题:
1、换了一台更好的服务器, 内存比以前大多了, 避免了以前asp.net进程因为可用内存太小频繁被回收的问题。
2、将更新阅读数改在当前线程进行, .Text原来是在另外一个线程的队列中通过定时调度完成阅读数的更新。可能.Text这部分的多线程处理有问题, 会发生死锁情况, 而造成CPU 100%负荷。这部分代码正在研究之中。

我也有你们上述的相关情况,我解决了一部分自己的事情

不过,能不能和各位联系啊?
我的qq:15468277
e-mail:yehaibo@hnpmi.com

 回复 引用 查看   
#23楼[楼主] 2005-08-02 14:51 dudu      
@花开花落俩不知
这个问题已经解决。

 回复 引用 查看   
#24楼 2005-08-17 13:49 齐国老兵      
aspnet_wp.exe (PID: 2268) was recycled because memory consumption exceeded the 306 MB (60 percent of available RAM).
aspnet_wp.exe (PID: 1628) stopped unexpectedly.
翻译成汉语不就很明显了吗?这个可以在machine.config里配置

 回复 引用   
#25楼 2005-10-18 15:06 outdll[未注册用户]
看看你的系统内存是不是被Sql server吃光了
 回复 引用   
#26楼 2005-11-11 20:39 cjcjcj[未注册用户]
怎么解决的?是程序代码的问题吗?
 回复 引用   
#27楼 2007-03-30 16:48 SQL[未注册用户]
@dudu
请贴出解决方法啊!我被这个问题困扰很久了!

 回复 引用   
#28楼 2007-06-07 23:39 hahaha[未注册用户]
我也想知道
 回复 引用   
#29楼 2007-11-19 10:24 云淡風清[未注册用户]
我們公司的HR網站,在3W人用的時候都還ok,前幾天增加了5000人,最近幾天訪問就超慢,用trace跟蹤發現也是audit logout占用cpu大量的時間,請各位高手指教。