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

Question

是否需要回收ASP.NET中的应用程序池，以指示Web应用程序中的更大问题？或者，这只是ASP.NET和IIS的“方式”？

编辑：由于其中一个错误是'OutOfMemory'异常，您对于行动方案有何建议？你会增加内存吗？简介应用程序？ （重要的是要注意我对此有自己的想法，并且有一条路线排队，但希望听到你的答案）。

Answer 1

IIS的运行状况监视功能可以自动回收应用程序池。因此，一个只是回收自己的应用程序池并不一定表示有问题;它可能只是打开IIS的预防功能。这个想法是，如果您的应用程序发生内存泄漏或忘记取消分配某些内容，我们可以通过每隔一段时间重新启动一次来提高应用程序的整体可用性，就像您可能在Windows上运行一个月后重新启动Windows一样;许多应用程序的小坏行为的净效应开始受到影响。

在其他一些平台中，您可能无法尽快注意到这些问题，特别是在CGI环境中，因为整个框架已设置，然后随每个页面请求一起拆除。

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

Answer 2

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

Answer 3

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

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

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