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

回收

回收通常是在IIS启动一个新的进程作为你的应用程序的一个容器，然后让旧的ShutdownTimeLimit在被杀之前离开自己的意志。

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

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

但默认情况下是重叠的 – 意味着中断的持续时间被最小化，因为新的进程开始并被连接到请求队列，在老的被告知“你有[ShutdownTimeLimit]秒钟离开，请遵守”。

设置

对于你的问题：该页面上的所有设置以某种方式控制回收。 “关机”可以被描述为“积极回收” – 过程本身决定了该走的时间，并有序地退出。

无功回收是WAS检测到问题并开始处理的地方（在build立合适的替代W3WP之后）。

现在，这里有一些可以导致某种forms的回收的东西：

• 一个ISAPI决定它是不健康的
• 任何模块崩溃
• 空闲超时
• CPU限制
• 调整应用程序池属性
  • 因为你的妈妈可能曾经有过一个尖叫：“停止接受 ，否则永远不会变好！”
• “ping”失败*本身并不实际ping，因此它使用命名pipe道 – 更多的“生命探测”
• 上面截图中的所有设置

该怎么办：

通常：

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

• 禁用常规时间间隔 – 29小时默认值被各方描述为“疯狂”，“烦人”和“聪明”。 其实只有两个是真的

• （可选）如果您不能停止使用它，则可以打开DisallowRotationOnConfigChange （上面的， 禁用Reycling以进行configuration更改 ） – 这样，您可以更改任何应用程序池设置，而不必立即向工作人员进程发送信号， 您需要手动回收应用程序池以使设置生效，这可让您预先设置设置，然后使用更改窗口通过回收过程应用设置。

这足以使一个乖巧的过程永远活着。 如果它死了，当然，它会被取代。 如果挂起，ping应该select它，并且应该在2分钟内启动一个新的应用程序（默认情况下，最坏的情况下计算应该是：在请求重新开始工作之前，最多可以ping通频率 + ping超时 + 启动时间限制 ）。

CPU限制通常不是很有意思，因为默认情况下，CPU限制closures，而且它也被configuration为什么都不做; 如果它被configuration为杀死进程，当然，这将是一个回收触发器。 丢开。 注意IIS 8.x，CPU Throttling也成为一个选项。

但是…然后我们进入.Net域，AppDomain回收，这也会造成状态的丢失。

您可以通过触摸内容文件夹中的web.config文件（再次select！），或通过在该文件夹中创build一个文件夹来实现这一点，这与App Pool回收一样具有破坏性，减去本机代码启动成本（它纯粹是一个托pipe代码的概念，所以只有托pipe代码的东西在这里发生）。 防病毒也可以触发这个，因为它扫描web.config文件，导致更改通知，造成….

请检查，

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

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

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

真的需要更多地关注.NET中的内存pipe理 ，并确保我们的应用程序能够保持正常运行。

基于OP场景（启动/预热时的长时间初始化），另一个要检查的是启动时间限制 （秒），其默认值为90秒。 如果初始化需要超过启动时间限制，则可以终止工作进程。