发表评论
建议利用页面缓存把首页等几个常用页面根据参数缓存60Sec。
一直在采用缓存, 几乎每个页面都有缓存, 首页缓存设的就是60Sec.
.text默认就是有缓存
cnblogs也一直使用缓存
哦？这两个sp单独执行要多长时间？
是不是导数据库把索引弄丢了？
1.安装一个资源回收工具看看~~~~SQL和.Net占用的资源太多啦~~
事件日志情况：
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.
直到博客园恢复正常。
dudu，你可以使用adplus把dump文件抓下来。如果你和M$的人有商务关系，可以把dump提交给上海M$的技术支持中心。
我们遇到过这个问题，最后分析dump文件，是我的一段调用unmanged code发生了缓冲区溢出，而在GC回收的时候导致了错误。当时重现这个错误的时候，只要把GC立刻执行的全局变量设置上，立刻就能看到这个错误。
aspnet_wp crash掉，反正原因有n种。我想你最好是分析dump文件，否则不好找。
弱 弱 的问一句，MDAC是不是已经是最新版？
之前我们的服务器在访问量很大的时候，也会出现这个错误，一直和你现在一样找不到原因，后来想起，当时正好是重装系统后才出的问题，然后把MDAC升到最新版，就OK了...
晕！刚才检查了一下MDAC的版本，竟然是2.7。现在已经安装了MDAC 2.8。
难道是这个原因？但本来CSDN提供的服务器上的MDAC是2.8.
刚才又看到一次报错信息，发现首页的博客排行榜，每行记录似乎都要再到数据库中去找二次链接信息，可能这里的开销很大，可不可以试图通过视图的方式一次性取出来，直接绑到repeater上，这样也许会好一些。
没有看到源码，不确切哈。
刚才不知为什么SQL Server将CPU占光了。重启SQL Server才恢复正常。
博客排行榜是一次查询, 然后再绑定到repeater, 没有进行二次查询。
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是非常重要的。
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.
@rickie
1. 博客园的服务器用的是Windows 2000 Adv, 早就升级到services Pack 4.
2. 你对with (nolock)分析很有道理, .Text的作者可能也是出于这个目的.
3. 你的server monitor tool好像只能监视请求的内容长度.
blog_GenericGetEntries_10存储过过程的内容是什么？为什么我下载的.TEXT 0.95中没有呀？
博客园的程序是在.Text 0.96上修改的。
存储过程下载: http://www.cnblogs.com/Files/dudu/cnblogsSP.rar
解压密码: cnblogs.com
正在下载。有个建议：
如果确认存储过程本身没有什么问题，估计是在什么资源上出现争用，造成某个线程等待时间过长。SQL 企业管理器左侧管理里面有个当前活动，可以获得一个当前所有进程的快照，并提供那些进程正在阻塞、那些进程造成阻塞，还有当前执行的命令是什么。可以看看什么进程造成了阻塞。
同时使用命令：SELECT * FROM master.dbo.sysprocesses where ecid = 0也可以获取相应资源，关于master.dbo.sysprocesses 可以参考SQL Server联机帮助。建议将其放到你的存储过程中，将结果输出到一个临时表什么的，然后查找一下到底是谁造成了阻塞。
CodeProject中有篇文章《Finding 'who is' using SQL Server》介绍的就是这方面的东西。你可以找找。
@吕震宇
非常感谢你的建议！
出现问题时, 我查看过进程信息, 没发现什么异常。但也有可能是我没看仔细。
现在在首页我已经减少对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.
CSDN Blog也大量调用了这两个存储过程，没有出现任何问题。
这两个存储过程的确不是引起问题的原因。
我通过两种处理方法解决了问题：
1、换了一台更好的服务器, 内存比以前大多了, 避免了以前asp.net进程因为可用内存太小频繁被回收的问题。
2、将更新阅读数改在当前线程进行, .Text原来是在另外一个线程的队列中通过定时调度完成阅读数的更新。可能.Text这部分的多线程处理有问题, 会发生死锁情况, 而造成CPU 100%负荷。这部分代码正在研究之中。
我也有你们上述的相关情况,我解决了一部分自己的事情
不过,能不能和各位联系啊?
我的qq:15468277
e-mail:yehaibo@hnpmi.com
#23楼 [
楼主]2005-08-02 14:51 |
@花开花落俩不知
这个问题已经解决。
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里配置
看看你的系统内存是不是被Sql server吃光了
@dudu
请贴出解决方法啊!我被这个问题困扰很久了!
我們公司的HR網站，在3W人用的時候都還ok，前幾天增加了5000人，最近幾天訪問就超慢，用trace跟蹤發現也是audit logout占用cpu大量的時間，請各位高手指教。