我看到在iis 7.5中，我可以为应用程序池指定一段时间来设置CPU％利用率限制 。 如果违反这个限制，我也可以杀死工作进程。 如果告诉它这样做，工作进程会在死亡后自动重启，还是需要手动干预？
在堆栈溢出有提及，它可以重新启动时间间隔完成…
这看起来就像仿真（或源代码访问…>叹息<）的情况之一，可能是唯一的方式来看到什么行为是任何程度的自信。
有关CPU配额回收的事件日志条目的文档介绍如何回收利用：
默认情况下，应用程序池回收是重叠的，这意味着要closures的工作进程将保持运行，直到启动新的工作进程。 在新的工作进程开始之后，新的请求被传递给它。 旧工作进程在处理完现有请求后closures，或在configuration的超时之后（以先到者为准）closures。 这种回收方式确保为客户提供不间断的服务。 但是，如果应用程序池中的应用程序一次不能运行多个自身的实例，则可以禁用重叠旋转。
在我看来，根据定义，由于CPU消耗过多而终止工作进程意味着待处理的请求将不被允许完成（因为它们耗尽了CPU配额）。
对您的主要担忧说话：我没有看到任何让我相信新的工作stream程不会自动化的东西。 您的堆栈溢出链接中的声明确实让我怀疑，如果IIS使用的algorithm可能实际上将循环与用于测量CPU配额耗尽的计时器的分辨率联系起来。 我知道确定的最好方法是编写一个CPU浪费的服务器端组件，将其部署到testing环境中，并了解它的回收行为是如何工作的。 一个简单的组件，坐在一个紧密的循环中几秒钟，然后返回一个已知的string，结合一个客户端运行一个testing工具，像一个平行的“wget”进程池可能就足够了。 用一堆来自客户端的并行请求来锤击它，并报告请求如何得到正确的响应与错误消息等等（这让我感到非常愚蠢，不得不求助于像这样的事情而不是去看看在源代码…）
鉴于其他答复的意见，我做了我自己的testing，我将在这里复制。
在我的testing中，启用KillW3WP操作将应用程序池（v4.0集成）限制为小的CPU限制（0.01％）和较小的间隔（1分钟），超过此限制通过停止应用程序池来杀死w3wp。
达到间隔限制后，应用程序池将自动重新启动 。
将操作更改为“ 无操作”不会改变w3wp进程。
在这两种情况下，都会logging系统事件5025。