![IIS 7.5 中应用程序池的 CPU 限制](https://linux22.com/image/520207/IIS%207.5%20%E4%B8%AD%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E6%B1%A0%E7%9A%84%20CPU%20%E9%99%90%E5%88%B6.png)
我看到在 iis 7.5 中我可以设置CPU % 利用率限制应用程序池的指定时间。如果违反此限制,我还可以让它终止工作进程。如果告诉它这样做,工作进程在被终止后会自动重新启动吗,还是需要手动干预?
在 Stack Overflow 上其中提到它能间隔结束后重新开始...
答案1
这看起来像是其中一种情况,其中模拟(或源代码访问......>叹息<)可能是以任何程度的信心查看行为的唯一方法。
的文档CPU 配额回收的事件日志条目关于回收利用如下:
默认情况下,应用程序池回收是重叠的,这意味着要关闭的工作进程将保持运行,直到启动新的工作进程。启动新的工作进程后,将向其传递新的请求。旧的工作进程将在处理完现有请求后或配置的超时后关闭(以先到者为准)。这种回收方式可确保不间断地为客户端提供服务。但是,如果应用程序池中的应用程序无法同时运行多个自身实例,则可以禁用重叠轮换。
在我看来,根据定义,由于 CPU 消耗过多而终止工作进程意味着待处理的请求将不被允许完成(因为它们耗尽了 CPU 配额)。
谈谈你的主要担忧:我没有看到任何让我相信新的工作进程不会自动启动的东西。 Stack Overflow 链接中的声明确实让我怀疑 IIS 使用的算法是否实际上可以将回收与用于测量 CPU 配额耗尽的计时器的分辨率联系起来。我知道确定这一点的最佳方法是编写一个浪费 CPU 的服务器端组件,将其部署到测试环境中,然后查看其回收行为如何运作。一个简单的组件,在一个紧密的循环中停留几秒钟,然后返回一个已知字符串,再加上一个运行测试工具的客户端,比如一个并行“wget”进程池,可能就足够了。用来自客户端的一堆并行请求敲打它,并报告有多少请求收到了正确的响应而不是错误消息等。(我不得不诉诸这样的事情,而不是直接去查看源代码,这让我感觉很愚蠢……)
答案2
考虑到其他回复中的评论,我进行了自己的测试,并将在这里重复。
在我的测试中,将应用程序池(v4.0 Integrated)限制为较小的 CPU 限制(0.01%)和较小的间隔(1 分钟),杀死W3WP操作已启用,超过此限制将终止 w3wp停止应用程序池。
达到间隔限制后,应用程序池将自动重启。
将操作更改为没有行动不会改变 w3wp 进程。
在这两种情况下,都会记录系统事件 5025。