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

Question

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

不幸的是，IIS 似乎相当定期地循环使用该进程。所以我试图更改应用程序池上的设置以确保 IIS 不会回收应用程序。到目前为止，我已经更改了以下内容：

• CPU 下的限制间隔从 5 到 0。
• 进程模型下的空闲超时从 20 到 0。
• 循环下的规则时间间隔从 1740 到 0。

这够了吗？我对我更改的项目有具体问题：

1. CPU下的Limit Interval设置具体是什么意思？是不是意味着如果超过一定的CPU使用率，应用程序池会被回收？
2. “回收”究竟是什么意思？应用程序是否完全拆除并重新启动？
3. “工作进程关闭”和“应用程序池回收”有什么区别？进程模型下空闲超时的文档讨论了关闭工作进程。而 Recycling 下的 Regular Time Interval 文档讨论了应用程序池回收。我不太明白两者之间的区别。我认为 w3wp.exe 是运行应用程序池的工作进程。有人可以解释两者之间的应用程序的区别吗？

使用 IIS7 和 IIS7.5 标记的原因是应用程序将在两者中运行，并希望版本之间的答案相同。

图片供参考：

Answer 1

回收

回收通常是* IIS 启动一个新进程作为应用程序的容器，然后将旧进程交给 ShutdownTimeLimit 以在它被杀死之前自行消失。

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

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

但默认情况下它是重叠的- 这意味着中断的持续时间被最小化，因为新进程启动并连接到请求队列，然后旧进程被告知“你有 [ShutdownTimeLimit] 秒可以离开。请遵守。”

设置

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

反应式回收是 WAS 检测到问题并启动流程的地方（在建立合适的替代 W3WP 之后）。

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

• 一个 ISAPI 认为它不健康
• 任何模块崩溃
• 空闲超时
• cpu限制
• 调整应用程序池属性
  • 因为你妈妈可能曾在某一时刻尖叫：“别再挑剔它了，否则它永远不会好转！”
• “ping”失败 * 实际上并不是 ping 本身，因为它使用了命名管道 - 更多的“生命检测”
• 上面截图中的所有设置

该怎么办：

一般来说：

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

• 禁用常规时间间隔- 29 小时的默认设置已被各方描述为“疯狂”、“烦人”和“聪明”。事实上，只有两个是正确的。

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

• 作为一般原则，请启用pinging。那是你的安全网。我见过有人把它关掉，然后网站有时会无限期地挂起，导致恐慌……所以如果设置对于你的明显非常非常缓慢响应的应用程序来说太激进了，让他们关掉一点看看你得到了什么，而不是把它关掉。（除非您通过自己的监控过程为挂起的 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文件，或..其他的东西......这就是关于与 App Pool 回收一样具有破坏性，减去本机代码启动成本（它纯粹是托管代码 (.Net) 概念，因此这里只发生托管代码）。

防病毒软件也可以在它扫描 web.config 文件时触发它，导致更改通知，导致....

Answer 2

好心检查，

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

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

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

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