我应该怎么做才能确保IIS不回收我的应用程序？

我在IIS中托管了WCF服务应用程序。在启动时，它会获取一个非常昂贵的资源（就时间和CPU而言）用作本地缓存。

不幸的是，IIS似乎很定期地回收该过程。因此，我尝试更改应用程序池上的设置，以确保IIS不回收应用程序。到目前为止，我已经更改了以下内容：

• 将CPU下的时间间隔从5限制为0。
• 过程模型下的空闲超时从20变为0。
• 回收中的常规时间间隔从1740到0。

这样够了吗？我对我更改的项目有特定的疑问：

1. CPU下的“限制间隔”设置具体是什么意思？这是否意味着如果超过某个CPU使用率，应用程序池将被回收？
2. “回收”到底是什么意思？应用程序是否已完全拆除并重新启动？
3. “关闭工作进程”和“回收应用程序池”有什么区别？进程模型下的空闲超时文档讨论了如何关闭工作进程。虽然“回收”下的“定期时间间隔”文档讨论了应用程序池回收。我不太理解两者之间的区别。我以为w3wp.exe是运行应用程序池的工作进程。有人可以解释两者之间的差异吗？

之所以拥有IIS7和IIS7.5标签，是因为该应用程序将同时在两者中运行，并希望答案在各个版本之间是相同的。

图片供参考：

回收利用

回收通常是*，其中IIS启动一个新进程作为您的应用程序的容器，然后将旧进程交给ShutdownTimeLimit，以便在被杀死之前免除它的意志。

*-通常：请参见DisallowOverlappingRotation /“禁用重叠回收”设置

它具有破坏性，因为原始过程及其所有状态信息都将被丢弃。使用进程外会话状态（例如，状态服务器或数据库，或者如果您的状态很小，甚至使用cookie）都可以解决此问题。

但是默认情况下它是重叠的，这意味着中断的时间可以最小化，因为新流程开始并挂接到请求队列，而新流程则被告知“您有[ShutdownTimeLimit]秒消失。请遵守。”

设定值

您的问题是：该页面上的所有设置都以某种方式控制回收。“关闭”可能被描述为“主动回收”-流程本身决定是否该走了，然后以有序的方式退出。

反应性回收是WAS发现问题并采取措施（在建立合适的替代W3WP之后）的地方。

现在，这里有一些东西可能导致一种或另一种形式的回收：

• ISAPI判定它不健康
• 任何模块崩溃
• 空闲超时
• CPU限制
• 调整应用程序池属性
  • 正如您的妈妈可能曾尖叫过：“停止采摘，否则它永远不会变得更好！”
• “ ping”失败*本身并不是真正的ping，因为它使用了命名管道-更多的“生命检测”
• 上面的屏幕截图中的所有设置

该怎么办：

通常：

• 禁用空闲超时。20分钟不活动=繁荣！下一个传入请求的新过程。将其设置为零。

• 禁用定期时间间隔 -各方将29小时默认值描述为“疯狂”，“烦人”和“聪明”。实际上，其中只有两个是正确的。

• 如果您无法停止玩，则可以选择启用DisallowRotationOnConfigChange（上面，禁用Reycling进行配置更改）-这使您可以更改任何应用程序池设置，而无需立即向工作进程发出需要杀死它的信号。您需要手动回收应用程序池以使设置生效，这使您可以预先设置设置，然后使用更改窗口通过回收过程来应用它们。

• 作为一般原则，请启用ping。那就是你的安全网。我见过有人将其关闭，然后有时该站点无限期挂起，导致出现恐慌...因此，如果设置对于您看似非常非常缓慢的应用程序而言过于激进，请稍作退后并查看您得到了什么，而不是将其关闭。（除非您通过自己的监视过程为挂起的W3WP设置了自动崩溃模式转储）

这足以使行为正常的过程永远存在。如果它死了，肯定会被替换。如果挂起，则ping应该接好，新的应该在2分钟内开始（默认；最坏情况下的计算应该是：达到ping频率 + ping超时 + 启动时间限制，然后请求才能再次开始工作）。

通常，CPU限制不是很有趣，因为默认情况下它是关闭的，并且它也被配置为什么也不做。如果将其配置为终止该进程，那么肯定是一个回收触发器。丢开。请注意，对于IIS 8.x，CPU限制也成为一个选项。

（IIS）AppPool不是（.Net）AppDomain（但可能包含一个/一些）

但是...然后，我们进入了.Net土地和AppDomain回收，这也可能导致状态丢失。（请参阅：https：//blogs.msdn.microsoft.com/tess/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles/）

短版，你这样做，在你的内容的文件夹（与采摘了！）触摸web.config文件，或创建该文件夹中的文件夹，或一个aspx文件，或..其他的东西......这就是关于与应用程序池回收一样具有破坏性，减去本地代码启动成本（它纯粹是托管代码（.Net）概念，因此此处仅发生托管代码内容）。

防病毒软件在扫描web.config文件时也会触发此操作，从而引起更改通知，从而导致...

好心检查，

为什么我们回收我们的应用程序池？

如果您浏览网络以查找将应用程序池配置为定期自动回收的原因，将很难找到与内存问题无关的合理答案。就像整个社区已经普遍接受了这样一个事实，即我们的Web应用程序（或IIS中托管的服务层）将需要回收以避免内存问题。

我一直认为，如果您的代码需要定期重新启动以保持正常工作，那么显然是错误的。您的代码中某处存在一个错误，您需要修复该错误，而不是偶尔重新启动该过程以使问题“消失”。

确实确实需要开始更多地关注.NET中的内存管理，并确保我们的应用程序可以继续运行而不会出现问题。

根据OP方案（启动/预热时长时间初始化），要检查的另一件事是启动时间限制（秒），默认值为90秒。如果初始化花费的时间超过启动时间限制，则可以终止工作进程。