网站间断性假、死

[shineran]

请各位朋友有经验的帮一下忙。
我负责了几个网站的开发，但现在有1-2个站点会出现间隔性的假死。
现象是，一般30分钟到1个小时，出现网站的所有页面访问等待状态，短则数十秒，长则2-3分钟，
期间任务页面请求包括静态页，都一至在等待，好象网站死掉一样。
这一段时间一过，又恢复正常的访问状态。
同时，在同一服务器上另外的几个站点访问是正常的。
服务器的内存及CPU监察也没有出现异常。

服务器内存是16G，
同一服务器上配置了四个站点，各自建立应用程序池。
还有一两个数据库服务。

初步断定是程序结构不良，并发数过高引起的。现在已经在SQL和代码上尽量优化了，好象有一定效果，但始终没完全解决。
请朋友指点一下，看看到底是什么原因，有什么方法能解决。

[CutBug]

如果是sqlserver2005+,用sql server profiler跟踪一下,看看哪条语句或存储过程执行比较慢
针对性的去优化

[Jcomet]

连接数太多了，可能是楼主你没有释放sql连接，我建议楼主使用2.0新增加的功能 using 来管理你的数据连接！

[叶子]

代码服务器和数据库服务器是同一台机器？
数据库日志增长速度快吗？

[cppfaq]

内存和CPU都正常的话，那就数据库连接的嫌疑最大了
....

[walkghost]

会不会是IIS的配置有问题？

[shengyongwang]

这个问题我也遇到过。主要是连接已满。首先你要关闭所有的连接。在就是在连接字符串中设置连接池:min pool size=200; max pool size=800;因为连接池默认是100，当访问量过多，连接满后就会出现假死。所以要手动根据实际的情况设置连接池的大小！

[shineran]

谢谢各位朋友的指点。
现在连接池加了：min pool size=200; max pool size=2000;
WEB.CONFIG也加： <runtime><legacyUnhandledExceptionPolicy enabled="true" /></runtime>
IIS的内存回收也取消掉了。
现在运行了近四小时，出现了两次假死状况。
在系统日志里同步出现：
Faulting application w3wp.exe, version 6.0.3790.3959, stamp 45d69572, faulting module kernel32.dll, version 5.2.3790.4062, stamp 462644ee, debug? 0, fault address 0x0000000000027d8d.

上网找了，很多朋友都有碰到，可惜都没有明确的解决方法。
站点的访问量在10万左右(含蜘蛛的访问) ，都是有使用伪静态：URLRewriter.dll
不知道会不会是URLRewriter.dll的冲突问题？

[lxf2000104]

根据报错的日志时间，看看是不是报错后立即就假死还是？。。。

[新时代新目标新征程]

帮顶。关注下

[shineran]

数据库引用方式改为useing了，
似乎好点，约一个小时后又出现一次。
检查了系统日志，发现出现网站假死的同时，有一个错误日志，详细是：
Faulting application w3wp.exe, version 6.0.3790.3959, stamp 45d69572, faulting module kernel32.dll, version 5.2.3790.4062, stamp 462644ee, debug? 0, fault address 0x0000000000027d8d.

网上查了一下，都没有提到好的解决方法。

[ViewStates]

1.你的某个网站可能代码有缺陷，比如定时器中的死循环等
2.你数据库过大并且日志文件的增长设为百分之多少（日志文件过大），然后在日志文件扩容的时候，比如从10G的日志再扩大10%，这个时候可能会导致查询变慢甚至超时。

[moonshineidolon]

我怀疑不是你数据库问题，我的网站也这样，程序还没有执行数据库就停止了。

[zzxap]

一条足够烂的SQL语句，足可以把你的一切优化工作白费

[shineran]

感谢各位的回复.
现情况是sql server profiler跟踪过了,已经将占用CPU较大的语句重新优化或用缓存方式处理了,SQL倒优化了,但效果甚微,仍有假死;
也想过可能是数据库连接占用问题,每个页访问后都加了CONN.CLOSE和Dispose并=NULL,也没什么效果.

难到用using 管理数据连接会比每次引用后Dispose好很多吗?

[delphi_new]

肯定是数据库连接池太多了，如果不是你的站点访问者太多的话，那就是你程序问题了
，建议显示释放数据库连接对象

[datahandler2]

数据层检验下。另外程序代码容易有问题的。你也可以去看看

[readfuture]

[Quote=引用 5 楼 shineran 的回复:]
感谢各位的回复.
现情况是sql server profiler跟踪过了,已经将占用CPU较大的语句重新优化或用缓存方式处理了,SQL倒优化了,但效果甚微,仍有假死;
也想过可能是数据库连接占用问题,每个页访问后都加了CONN.CLOSE和Dispose并=NULL,也没什么效果.

难到用using 管理数据连接会比每次引用后Dispose好很多吗?
[/Quote]
using 与dispose都是释放资源;
但using在对象超出作用域时会自动调用Dispose()。

[shineran]

现在在各方面做了优化，并监控错误的SQL语句，发现确实有不少的错误SQL，有的是超时，有的是死锁，然后清理了一遍，现情况算是基本稳定了，一整天下来假死两次，算是比较好了。

谢谢各位朋友的帮助。