为什么 IIS 工作进程每 29 小时而不是每 24 小时回收一次？

Question

当您在 IIS 上设置站点时，它默认工作进程每 1740 分钟（29 小时）循环一次。为什么是像 29 小时这样的奇数，而不是例如 24 或 48 小时？

Answer 1

在 Tech Ed 2003 上，演示者被问到了这个问题，答案是他们想要一个不规则的周期，以防止它发生在每天的边界上（例如，以区别于服务器/域上安排的其他日常任务）。

这里的网站（链接已死）推测：

...（29 是 24 之后的第一个素数，使其与任何其他服务器进程以规则模式发生的机会最少；简化对问题的调查

另一个网站似乎证实了这一点：

( Wade Hilmo ) 建议 29 小时的原因很简单，因为它是 24 中最小的质数。他想要一种交错且不重复的模式，每天出现的频率不会超过一次

Answer 2

好吧，这让我很烦恼，所以我四处寻找，终于找到了一个显然是 IIS 团队成员的帖子：

IIS6 默认每 29 小时回收一次的原因（我们有一个原因

IIS6 默认情况下每 29 小时回收一次（我们有理由选择 29 小时作为默认值）的原因很可能是因为在其上运行的 Web 应用程序不可靠并且确实需要频繁重启。

因此，IIS6 是围绕用户的 Web 应用程序不会连续运行超过 24 小时的前提（诚然是愤世嫉俗的）构建的，相应地计划了功能，并选择了默认值。工作进程每 29 小时循环一次，监控进程启动和关闭，不断 ping 进程以确保它正在运行，进程句柄被跟踪并在意外终止时发出信号等。

意识到回收是操作的正常部分，IIS6 还确保将此类回收与最终用户隔离——由于某些内核模式魔法，最终用户的 TCP 连接在回收期间永远不会终止。结合在进程外存储会话状态的用户模式应用程序（如 ASP.Net 会话状态服务），一个几乎可以保证可靠的正常运行时间，没有用户可见的数据丢失，即使 Web 应用程序在处理每个单个后崩溃用户请求。

这与 IIS6 所能做到的一样好——给定一个不可靠的 web 应用程序，让它对最终用户看起来可靠，并且不需要对不可靠的 web 应用程序进行任何修复。

当然，并不是所有不可靠的应用程序都可以看起来可靠——如果是这样，那么我们都失业了！-- 但 IIS6 肯定会尝试更多的弹性。

在您的情况下，弹性只是碰巧对非持久用户状态有副作用，但可以轻松调整。

假设您的 Web 应用程序从未出现问题并保持进程内会话状态，您将需要更改这些默认值： 1. 关闭 29 小时定期回收 2. 关闭 20 分钟空闲超时

这将防止会话状态意外丢失。

当然，如果您曾经使用具有进程外会话状态的应用程序，您可以将所有内容保留为默认值，并且永远不会注意到功能和可靠性方面的差异。