必须在 ASP.NET 中回收 App-Pool 是否表明 Web-App 中存在更大的问题？或者这只是 ASP.NET 和 IIS 的“现状”？
编辑：由于其中一个错误是“OutOfMemory”异常，您对行动方案有何建议？你会加内存吗？分析应用程序？ （重要的是要注意，我对此有自己的想法，并且已经排好路，但想听听您的回答。
【问题讨论】：
IIS 的运行状况监控功能可自动回收应用程序池。所以一个应用程序池只是回收自身并不一定表明存在问题；它可能只是 IIS 的预防功能已打开。这个想法是，如果您的应用程序发生内存泄漏或忘记释放某些内容，我们可以通过每隔一段时间重新启动它来提高应用程序的整体可用性，就像您在桌面上运行一个月后重新启动 Windows 一样许多应用程序的小不良行为的净影响开始产生影响。
在其他一些平台上，您可能不会很快注意到这些问题，尤其是在 CGI 环境中，因为整个框架都是先设置好的，然后随着每个页面请求而拆除。
理想情况下，您永远不必重新启动应用程序池，而必须这样做通常是某种问题的征兆。回收功能是一种责任保险，可以防止我们自己的错误，或者那些“行星只是如此对齐”的错误，这些错误很难追踪、重现，而且发生频率如此之低，以至于它们可能不值得排除故障。
【讨论】：
就个人而言，我认为这是更大问题的迹象。我的应用程序运行了数周而没有回收。他们回收的唯一原因是因为我们推送代码更新。我认为您应该查看您的事件日志，看看您是否可以找到应用程序池回收的任何原因。我见过这种情况经常发生，内存泄漏最终会导致您的内存耗尽，从而迫使您的应用程序池重新启动。
【讨论】：
应用程序池可以回收利用的原因有很多。未处理的异常或线程挂起是常见原因。如果您没有关闭所有 SqlConnections 并且连接池为空也可能导致它回收。死锁超时是另一个，如果你有一个死锁，它会挂起工作进程，这将导致回收。另外，如果IIS在服务器上使用了异常数量的资源，它会回收（我认为默认是60%）
还有很多 iis 设置会触发它。有一些设置可以定期回收（为了清除会话状态），我认为默认情况下它是每 24 小时一次。我们有大约 40 处中型到大型面向公众的房产，我们将在淡季进行回收利用。
我很确定还有其他原因。人们失去他们的会话可能比应用程序崩溃或服务器挂起更好，这就是为什么它内置在 IIS 中。不幸的是，它会使诊断问题变得非常困难。我会在回收发生时查看您的事件查看器，看看是否有任何有趣的事情可以作为开始的地方。跟踪内存使用情况将是我的下一步，然后是一些详细的日志记录。
【讨论】：