工作进程达到了允许的处理时间

时间:2009-05-04 20:30:50

标签: iis-6 worker-process application-pool

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

3 个答案:

答案 0 :(得分:12)

我注意到IIS在29小时的回收计划中默认使用网络应用程序,这可能很麻烦,因为它可能会在用户不期望的情况下进行回收。

例如:网络应用程序从上午12点开始,这意味着第二天它将在凌晨5点,第二天上午10点,第二天下午3点等进行回收(这是假设有足够的请求活动对您的应用程序,以使其保持活动状态,因此不会因为不活动而关闭)

如果您的Web应用程序在很大程度上依赖于内存中的会话状态,这尤其糟糕,因为回收会终止会话并可能强制用户重新进行身份验证并丢失任何未保存的工作。 (如果您没有将应用程序设计为与回收无缝协作)

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

不确定无限循环建议......听起来您只需要解决回收配置问题。

答案 1 :(得分:2)

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

基本上,每次请求进入Web服务器时,IIS都会将请求移交给工作进程。您可以在IIS中配置有多少工作者,以及超时值。超时是为了防止应用程序代码挂起 - 它会被杀死,因此线程可以返回池中以继续处理新请求。

请仔细查看代码中的无限循环。或者,它可能是一个非常长时间运行的数据库查询,最终可能已完成但超过了超时值。也许您的Web应用程序为最终用户提供了一个查询过于宽泛的查询的机会,该查询返回的数据太多或需要太多的数据库处理时间。

当然,很难为你提供具体的事业,但要尝试按照这些思路。

答案 2 :(得分:1)

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