ASP.NET - 回收应用程序池指示更大的问题？

Question

是否必须在ASP.NET中回收一个App-Pool，表明Web-App中存在更大的问题？或者这只是ASP.NET和IIS的'事物的方式'？

编辑：由于其中一个错误是“OutOfMemory”异常，您对行动方案的建议是什么？你会添加内存吗？介绍应用程序？ （重要的是要注意我对此有自己的想法，并且有一条路径排成一行，但是想听听你的答案）。

Answer 1

就个人而言，我认为这是一个更大问题的迹象。我有几周没有回收的应用程序。他们回收的唯一原因是我们推动代码更新。我认为您应该查看您的事件日志，看看您是否可以找到应用程序池回收的任何原因。我已经看到它经常发生内存泄漏，最终会导致内存不足，迫使你的应用池重启。

Answer 2

IIS的运行状况监视功能可以自动回收应用程序池。因此，仅仅回收自己的应用程序池并不一定表示存在问题;它可能只是启用了IIS的预防功能。我们的想法是，如果您的应用程序有内存泄漏或忘记解除分配，我们可以通过每隔一段时间重新启动它来提高应用程序的整体可用性，就像您在桌面上运行一个月后重新启动Windows一样。许多应用程序的小坏行为的净效应开始造成损失。

在其他一些平台上，您可能不会快速地注意到这些问题，尤其是在CGI环境中，因为整个框架已经设置好，然后随着每个页面请求被拆除。

理想情况下，您永远不必重新启动应用程序池，并且必须这样做通常是某种问题的迹象。回收功能是针对我们自己的错误的一种责任保险，或者是那些“刚刚对齐的行星”错误，这些错误非常难以追踪，重新创建，并且很少发生，以至于它们可能不值得进行故障排除。

Answer 3

应用程序池可以回收的原因很多。未处理的异常或线程挂起是常见原因。如果您没有关闭所有SqlConnections并且连接池为空，则会导致它也回收。死锁超时是另一个，如果你有一个死锁，它将挂起工作进程，这将导致回收。此外，如果IIS在服务器上使用了异常数量的资源，它将回收（我认为默认值为60％）

还有很多iis设置会触发它。有定期回收的设置（为了清除会话状态），我认为默认情况下每24小时一次。我们有大约40个中等到重型公共物业，我们设定在低谷期回收。

我很确定还有其他原因。失去会话的人可能比应用程序崩溃或服务器挂起更好，这就是内置于IIS的原因。不幸的是，它可能使诊断问题变得非常困难。我会在回收发生的时候看看你的事件查看器，看看有没有什么有趣的地方可以开始。跟踪内存使用情况将是我的下一步，然后是一些详细的日志记录。