40

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

所以，我的问题有两个：

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

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

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

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

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

4

4 回答 4

31

a) 由于重叠回收。有一个“旧”进程等待新进程启动的时间段。

b) 没有。据我所知。

于 2008-12-24T17:54:21.383 回答
15

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

于 2008-12-24T17:52:09.017 回答
6

根据这个链接，

停止- 通过停止应用程序池，您指示所有为该应用程序池服务的 IIS 工作进程关闭，并防止任何其他工作进程启动，直到应用程序池再次启动。这将启动工作进程的正常关闭，每个工作进程都试图耗尽它的所有请求，然后退出。

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

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

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

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

于 2018-07-28T17:54:46.987 回答
1

停止

  1. 优雅地停止此应用程序池的所有现有工作进程。
  2. 不允许为此应用程序池启动新的工作进程。

回收

  1. 优雅地停止此应用程序池的所有现有工作进程。
  2. 允许为此应用程序池启动新的工作进程。
  3. 重置应用程序状态和缓存

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

于 2021-04-27T20:38:02.507 回答