IIS应用程序池 - 停止/启动 vs 回收

Question

47

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

因此，我的问题有两个方面：

a）为什么销毁进程（更具意义的是释放其使用/锁定的资源）在应用程序池重新启动而不是停止时需要这么长时间; 和

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

编辑：澄清一下，在我回收或停止应用程序池之前，我会停止发送到相关服务器的流量（该服务器位于负载平衡集群中，并且我会将该服务器从负载平衡器中移除）。因此，理论上，在我对应用程序池进行任何操作时，应该没有请求发送到网站。

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

有了这些知识，我清楚地知道“回收”功能是专门用于在活动服务器上中途使用的，而且由于我事先手动处理了流量，所以应该使用停止/启动。

- Daniel Schaffer

4个回答

15

如果我记得正确，回收站允许所有现有请求完成，然后它将回收应用程序池。停止操作仅在您停止时立即结束。

- Mitchel Sellers

这是一个很老的回答，有一些赞，但我认为它不是一个准确的答案。请查看下面我的答案并给出您的想法。 - natenho

9

根据此链接，停止 - 通过停止应用程序池，您可以指示为该应用程序池提供服务的所有IIS工作进程关闭，并防止启动任何其他工作进程，直到重新启动应用程序池。这将启动工作进程的优雅关闭，每个工作进程尝试排空所有请求然后退出。

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

因此，停止应用程序池是一种破坏性的操作，会导致卸载ASP.NET应用程序域、FastCGI子进程以及任何进程内应用程序状态的丢失。回收 - 回收应用程序池会优雅地关闭该应用程序池中当前正在运行的所有IIS工作进程，但与停止池不同，可以按需启动新的IIS工作进程来处理后续请求。

回收应用程序池是一种很好的方法，可以使应用程序状态和IIS工作进程缓存的任何未自动刷新的配置（主要是全局注册表键）重置，而不会干扰服务器的操作。这使得在大多数情况下，回收应用程序池成为IISRESET的一个很好的替代方案。

- natenho

3

停止

回收

注意：对于两者都是第1点完全相同。第3点不适用于停止，因为进程已经消失，状态显然也消失了。

- CodingYoshi

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Igal Serban · Accepted Answer

34

a) 由于 Overlap Recycling，旧进程等待新进程启动的一段时间。

b) 不，据我所知没有。

- Igal Serban

@igal 你好，假设服务器为John（inProc）保留了一个会话。现在假设管理员进行了“回收”操作。现在发生了重叠的回收，所有请求都完成了。新进程启动。John是否仍将具有相同的SESSION ID？（重启肯定不会保存它。问题是针对回收的情况）。 - Royi Namir

@RoyiNamir 你好。回收站无法帮助。在回收后，会话ID和会话数据都会丢失。 - Igal Serban