IIS 应用程序池 - 停止/启动与回收答案

【问题标题】：IIS App Pools - Stop/Start vs RecycleIIS 应用程序池 - 停止/启动与回收
【发布时间】：2010-09-28 08:36:26
【问题描述】：

我注意到，在我的一个生产 Web 应用程序中，当我手动回收应用程序池时，根据在任务管理器中的观察，回收的工作进程可能需要超过 60 秒才能完全销毁。但是，如果我完全停止应用程序池，工作进程几乎会在 1-2 秒内立即消失。

所以，我的问题有两个：

a) 当应用程序池被回收而不是停止时，为什么销毁进程需要这么长时间（更有意义的是释放它使用/锁定的资源）；和

b) 假设我已停止将流量定向到服务器，是否有任何理由不停止/启动而不是回收？

编辑：
为了澄清，在我回收或停止应用程序池之前，我停止将流量发送到有问题的服务器（服务器位于负载平衡集群中，我从负载平衡器中删除了服务器）。因此，理论上，当我对应用程序池执行任何操作时，应该不会有任何请求进入网站。

编辑第二部分：
阅读 Igal 的链接后，对我来说发生了什么似乎很明显。当我回收应用程序池时，新进程启动，但由于根本没有流量，它没有将新进程注册为正常运行，因此它不会关闭旧进程，直到超时（即 90秒）。

有了这些知识，我很清楚“回收”功能专门用于实时服务器的中游，并且由于我事先手动排出流量，我应该改用停止/启动。

【问题讨论】：

标签： iis application-pool worker-process recycle

【解决方案1】：

a) 因为Overlapped Recycling。 “旧”进程有一段时间等待新进程启动。

b) 没有。据我所知。

【讨论】：

@igal 嗨，假设服务器有一个 John 的会话（inProc）。现在假设管理员创建了recycle。现在发生了重叠回收。并且所有请求都已完成。新进程启动。 john 现在会有相同的会话 ID 吗？（重启肯定不会保存它。问题是回收）。
@RoyiNamir 嗨。回收将无济于事。回收后 Session ID 和 Session 数据丢失。

【解决方案2】：

如果我没记错的话，回收允许所有现有请求完成，然后它将回收应用程序池。停止只是在您停止它的那一刻结束它。

【讨论】：

这是一个非常古老的答案，有一些赞成，但我想这不是一个准确的答案。请在下面查看我的答案并给你一些想法。

【解决方案3】：

根据this link，

停止 – 通过停止应用程序池，您指示所有服务于该应用程序池的 IIS 工作进程关闭，并防止启动任何其他工作进程，直到应用程序池再次启动。 这会启动一个优雅的关闭工作进程，每个工作进程都在尝试耗尽所有请求，然后退出。

如果工作进程没有在指定的时间内退出通过 processModel 中的 shutdownTimeLimit 配置属性每个应用程序池定义的元素（默认值：90 秒），WAS 将强制终止它（如果本机调试器不会发生这种情况已附上）。

因此，停止应用程序池是一种破坏性操作，导致卸载 ASP.NET 应用程序域、FastCGI 子进程、并丢失任何正在进行的应用程序状态。

回收 – 回收应用程序池会导致该应用程序池中所有当前运行的 IIS 工作进程正常运行关闭，但与停止池不同，新的 IIS 工作进程可以按需启动以处理后续请求。

回收应用程序池是导致重置的好方法应用程序状态和 IIS 工作者缓存的任何配置不会自动刷新的进程（主要是全局的注册表项），而不会中断服务器的运行。这使回收应用程序池成为一个很好的替代方案 IISRESET 在大多数情况下。

【讨论】：

【解决方案4】：

停止

正常停止此应用程序池的所有现有工作进程。
不要允许为此应用程序池启动新的工作进程。

回收

正常停止此应用程序池的所有现有工作进程。
允许为此应用程序池启动新的工作进程。
重置应用程序状态和缓存

注意： 两者的第 1 点完全相同。第 3 点不适用于 Stopping，因为进程已经消失，因此状态显然消失了。

【讨论】：