9

我们大约每月遇到一次这个问题。很难查明原因,因此我们将不胜感激。这会导致应用程序池停止并关闭站点。我们浏览了所有的日志文件,没有任何结论。我们在 IIS 6 上使用 2.0.3 版本。

4

3 回答 3

18

我注意到 IIS 将 Web 应用程序默认为 29 小时回收计划,这可能会很麻烦,因为它可能会在您的用户不期望它的时候回收。

例如:web 应用程序从上午 12 点开始,这意味着它在第二天早上 5 点回收,第二天早上 10 点,第二天下午 3 点,等等(这是假设你的应用程序有足够的请求活动来保持它活着,所以它不会因为不活动而关闭)

如果您的 Web 应用程序严重依赖内存中的会话状态,这尤其糟糕,因为回收会终止会话并可能迫使用户重新进行身份验证并丢失任何未保存的工作。(如果您不设计您的应用程序与回收无缝工作)

检查回收计划并确保它在您期望的时间回收。请参阅此屏幕截图:http ://remy.supertext.ch/2010/08/iis7-worker-process-reached-its-allowed-processing-time-limit/

不确定无限循环建议......听起来你只是有一个回收配置问题要解决。

于 2012-11-09T18:09:46.627 回答
3

这可能表明您的应用程序代码中存在无限循环。

基本上,每次请求进入 Web 服务器时,IIS 都会将请求交给工作进程。您可以在 IIS 中配置这些工作人员的数量,以及超时值是多少。超时是为了在应用程序代码挂起的情况下保持运行——它被终止,因此线程可以返回池中以继续为新请求提供服务。

因此,请查看您的代码以查找可能的无限循环。或者,它可能是一个运行时间极长的数据库查询,它可能最终完成但超过了超时值。也许您的 Web 应用程序为最终用户提供了一个机会来进行过于宽泛的查询,从而返回过多的数据或需要过多的数据库处理时间。

当然,很难给你一个具体的原因,但试着沿着这些思路思考。

于 2009-05-04T20:36:23.140 回答
2

如果您因此遇到崩溃(听起来像您),那么您可能想要获取一份Debugging Tools for Windows的副本并花一些时间阅读Tess Ferrandez的博客——她提供了关于执行死后崩溃分析的好建议并使 WinDbg 更加平易近人。

于 2009-05-05T06:54:46.993 回答