工作进程达到其允许的处理时间答案

【问题标题】：Worker process reached its allowed processing time工作进程达到其允许的处理时间
【发布时间】：2010-10-23 17:49:14
【问题描述】：

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

【问题讨论】：

【解决方案1】：

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

例如：网络应用程序从上午 12 点开始，这意味着它在第二天早上 5 点回收，第二天早上 10 点，第二天下午 3 点，等等（这是假设有足够的请求活动针对您的应用程序使其保持活动状态，因此它不会因不活动而关闭）

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

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

【讨论】：

你不应该尝试这样做；正如您已经注意到的，应用程序池可能会回收还有其他原因；根本没有办法让它“在你期望的时间”循环利用。因此，您应该始终针对Session 进行编码，就好像它可以在每个请求中被清除一样。此外，这个问题似乎在谈论应用程序崩溃，这是不同的。
让我们暂时忘记 Session 并专注于手头的问题，即应用程序在意外的时间间隔停止。许多 IIS 新用户忘记更改默认的回收间隔。该消息“工作进程达到其允许的处理时间”是 ASP.NET 在计划的回收点停止时报告的错误。所以，修复你的回收，将其设置为可预测的，然后从那里开始。对于应用程序停止的故障排除原因，ScottGu 的这个解决方案对我很有帮助：weblogs.asp.net/scottgu/archive/2005/12/14/433194.aspx
嗯...我在哪里说过要避免依赖 Session？我说过要始终编码，就好像每次请求都可以擦除 Session 一样。您必须这样做，无论您如何设置“回收间隔”，因为您无法依赖它何时回收，无论您做什么。
关于 Session 的优点。请注意，在我最初的答案中，我写道“如果您的应用程序严重依赖内存中的会话状态”，但感谢您加入讨论。但是，问题是关于应用程序停止，而不是会话。

【解决方案2】：

如果您因此遇到了崩溃（听起来像您），那么您可能想要获取一份 Debugging Tools for Windows 的副本并花一些时间阅读 Tess Ferrandez 的博客——她提供了关于执行帖子的很好的建议mortem 崩溃分析，让 WinDbg 变得更加平易近人。

【讨论】：

【解决方案3】：

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

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

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

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

【讨论】：