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

Question

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

Answer 1

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

网站这里（链接失效）推测：

...（29 是）24 之后的第一个素数，这使得它以最小的概率与任何其他服务器进程一起定期出现；从而简化了对问题的调查

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

（韦德·希尔默) 建议 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 分钟空闲超时

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

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