什么能导致IIS应用程序池回收？

Question

我目前在会话变量中遇到了一些不稳定情况，并认为应用程序池是错误来自的地方。我无法找到的是这个问题的可能的罪魁祸首。什么会导致应用程序池自行回收，而不是预定的回收？

Answer 1

Common reasons why your application pool may unexpectedly recycle

编辑：在事件全文的链接进入404：

如果您的应用程序崩溃，挂起和死锁会引起/需要的应用程序池，以回收待解决，但有时你的应用程序池莫名其妙地回收没有明显的原因。这通常是配置问题，或者是由于您在应用程序目录中执行文件系统操作。

为了消除，我想我会列出最常见的原因。

应用程序池设置
如果您检查应用程序池的属性，你会看到许多设置回收应用程序池。在IIS6它们是：

回收工作进程（以分钟计）
回收工作进程（在请求）
回收工作进程在以下时间
最大虚拟存储器
最大使用的存储器
这些设置应如果你想了解更多，请看看这个MSDN文章

machine.config的processModel元素 如果你正在运行IIS5或在IIS5隔离模式下，您必须查看processModel元素。属性你应该最关注到有：

的memoryLimit
requestLimit
超时
的memoryLimit

的memoryLimit的默认值是60，该值仅感兴趣，如果你有一个相当小的内存32位机器。 60代表整个系统内存的60％。所以如果你有1 GB的内存，工作进程一旦达到600 MB的内存使用量就会自动重启。另一方面，如果您拥有8 GB的存储空间，理论上这个过程会在达到4.8 GB时重新启动，但由于这是一个32位的过程，它永远不会增长那么大。有关更多信息，请参阅我的32位进程文章。

requestLimit
此设置默认为“无限”，但如果它被设置为5000例如，然后ASP.NET会推出一次在投放5000个请求一个新的工作进程。

超时

默认的超时值是“无限的”，但在这里你可以设置工作进程的生存期。一旦达到超时，ASP.NET将启动一个新的工作进程，因此将其设置为“00:05:00”将每五分钟回收一次该应用程序。

其它性能

有其他可能会导致应用程序池回收，像responseDeadlockInterval processModel元素中的其他属性。但是这些其他设置通常取决于出错或触发的不正常情况。如果你有一个僵局，那么这是你最关心的问题。改变responseDeadlockInterval设置对于解决这种情况并没有太大的帮助。你需要处理死锁本身。

编辑和更新

ASP.NET 2.0依赖于文件更改通知（FCN），查看是否应用更新。根据更改，应用程序池将回收。如果您或您的应用程序正在向应用程序文件夹添加和删除目录，则每次都将重新启动应用程序池，因此请注意这些临时文件。

改变下列文件也会触发应用程序池的立即重启：

的web.config
的machine.config
Global.asax的
任何bin目录或它的子-directories
更新导致重新编译的.aspx文件等最终也会触发应用程序池的重新启动。 system.web中有一个名为numRecompilesBeforeAppRestart的编译元素的属性。默认值是20.这意味着在重新编译20次之后，应用程序池将被回收。

一种解决方法的子目录问题
如果您的应用程序实际上取决于添加和删除子目录，您可以使用LINKD创建一个目录连接。方法如下：

创建一个你想从FCN中排除的目录，例如， c：\ inetpub \ wwwroot \ WebApp \ MyDir 在wwwroot外部的某个位置创建一个单独的文件夹。例如。 c：\ MyExcludedDir 使用链接链接链接两个：链接c：\ inetpub \ wwwroot \ WebApp \ MyDir c：\ MyExcludedDir 在c：\ inetpub \ wwwroot \ WebApp \ MyDir中所做的任何更改都将实际发生在c：\ MyExcludedDir让他们不会被FCN注意到。

回收应用程序池真的很糟吗？ 您真的不应该回收应用程序池，但如果您正在处理应用程序中的内存泄漏问题，并且需要花时间修复它，那么回收应用程序池可能是个好主意。

会话状态如何？

那么，如果您正在运行进程内会话状态，那么显然它将在每次应用程序池被回收时重置。如果你需要了解你的状态服务器选项，那么我建议看看这个条目。