最佳 CPU 利用率阈值
我已经构建了部署在 Windows 2003 服务器上的软件。该软件作为服务持续运行，它是 Windows 上唯一对我来说重要的应用程序。一部分时间，它从互联网检索数据，一部分时间它对这些数据进行一些计算。它是多线程的——我使用大约 4-20 个线程的线程池。
我不会让您厌倦所有这些细节，但只要说当我在池中启用更多线程时，就会发生更多并发工作，并且 CPU 使用率会上升。 （对其他资源（如带宽）的需求也是如此，尽管这对我来说并不重要——我有很多）
我的问题是：我是否应该尝试最大限度地利用 CPU 以获得最大的收益？直觉上，我认为以 100% CPU 运行是没有意义的；即使 95% 的 CPU 看起来也很高，几乎就像我没有给操作系统太多空间来完成它需要做的事情。我不知道确定最佳平衡的正确方法。我猜我可以不断地测量，并可能发现最佳吞吐量是在 CPU 平均利用率为 90% 或 91% 等时实现的。但是……
我只是想知道是否有一个好的经验法则？ ？我不想假设我的测试会考虑工作负载的各种变化。我宁愿玩得安全一点，但也不要太安全（否则我就没有充分利用我的硬件）。
你有什么建议吗？对于 Windows 上的多线程、混合负载（一些 I/O、一些 CPU）应用程序来说，明智的、注重性能的利用规则是什么？
I have built software that I deploy on Windows 2003 server. The software runs as a service continuously and it's the only application on the Windows box of importance to me. Part of the time, it's retrieving data from the Internet, and part of the time it's doing some computations on that data. It's multi-threaded -- I use thread pools of roughly 4-20 threads.
I won't bore you with all those details, but suffice it to say that as I enable more threads in the pool, more concurrent work occurs, and CPU use rises. (as does demand for other resources, like bandwidth, although that's of no concern to me -- I have plenty)
My question is this: should I simply try to max out the CPU to get the best bang for my buck? Intuitively, I don't think it makes sense to run at 100% CPU; even 95% CPU seems high, almost like I'm not giving the OS much space to do what it needs to do. I don't know the right way to identify best balance. I guessing I could measure and measure and probably find that the best throughput is achived at a CPU avg utilization of 90% or 91%, etc. but...
I'm just wondering if there's a good rule of thumb about this??? I don't want to assume that my testing will take into account all kinds of variations of workloads. I'd rather play it a bit safe, but not too safe (or else I'm underusing my hardware).
What do you recommend? What is a smart, performance minded rule of utilization for a multi-threaded, mixed load (some I/O, some CPU) application on Windows?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
是的，我建议 100% 是颠簸，所以不想看到进程一直这样运行。我始终以 80% 为目标，以在利用率和峰值/临时流程空间之间取得平衡。
我过去使用的一种方法是缓慢增加池大小并测量影响（对 CPU 和其他约束（例如 IO）），你永远不知道，你可能会发现 IO 突然成为瓶颈。
Yep, I'd suggest 100% is thrashing so wouldn't want to see processes running like that all the time. I've always aimed for 80% to get a balance between utilization and room for spikes / ad-hoc processes.
An approach i've used in the past is to crank up the pool size slowly and measure the impact (both on CPU and on other constraints such as IO), you never know, you might find that suddenly IO becomes the bottleneck.
在这种 I/O 密集型工作负载中，CPU 利用率并不重要，您关心的是吞吐量，因此请尝试使用 hill攀爬方法，基本上尝试以编程方式注入/删除工作线程并跟踪完成进度...
如果添加一个线程并且有帮助，请添加另一个线程。如果你尝试使用一根线并且感到疼痛，请将其移除。
最终这种情况会稳定下来。
如果这是基于 .NET 的应用程序，则会将爬山添加到 .NET 4 线程池中。
更新：
爬山是一种基于控制理论的最大化吞吐量的方法，如果您愿意，您可以将其称为试错法，但这是一种合理的方法。一般来说，这里没有一个好的“经验法则”可供遵循，因为开销和延迟差异很大，实际上不可能一概而论。重点应该放在吞吐量和吞吐量上。任务/线程完成情况，而不是 CPU 利用率。例如，通过粗粒度或细粒度同步很容易地固定内核，但实际上并不会改变吞吐量。
另外，关于 .NET 4，如果您可以将问题重新构造为 Parallel.For 或 Parallel.ForEach，那么线程池将调整线程数以最大化吞吐量，因此您不必担心这一点。
-瑞克
CPU utilization shouldn't matter in this i/o intensive workload, you care about throughput, so try using a hill climbing approach and basically try programmatically injecting / removing worker threads and track completion progress...
If you add a thread and it helps, add another one. If you try a thread and it hurts remove it.
Eventually this will stabilize.
If this is a .NET based app, hill climbing was added to the .NET 4 threadpool.
UPDATE:
hill climbing is a control theory based approach to maximizing throughput, you can call it trial and error if you want, but it is a sound approach. In general, there isn't a good 'rule of thumb' to follow here because the overheads and latencies vary so much, it's not really possible to generalize. The focus should be on throughput & task / thread completion, not CPU utilization. For example, it's pretty easy to peg the cores pretty easily with coarse or fine-grained synchronization but not actually make a difference in throughput.
Also regarding .NET 4, if you can reframe your problem as a Parallel.For or Parallel.ForEach then the threadpool will adjust number of threads to maximize throughput so you don't have to worry about this.
-Rick
假设除了操作系统在机器上运行之外没有其他重要的事情：
并且您的负载是恒定的，您应该以 100% CPU 利用率为目标，其他一切都是对 CPU 的浪费。请记住，操作系统处理线程，因此它确实能够运行，运行良好的程序很难使操作系统挨饿。
但是，如果您的负载是可变的并且您期望应该考虑峰值，我认为 80% CPU 是一个很好的使用阈值，除非您确切地知道该负载将如何变化以及需要多少 CPU，在这种情况下您可以瞄准确切的数字。
Assuming nothing else of importance but the OS runs on the machine:
And your load is constant, you should aim at 100% CPU utilization, everything else is a waste of CPU. Remember the OS handles the threads so it is indeed able to run, it's hard to starve the OS with a well behaved program.
But if your load is variable and you expect peaks you should take in consideration, I'd say 80% CPU is a good threshold to use, unless you know exactly how will that load vary and how much CPU it will demand, in which case you can aim for the exact number.
如果您只是给线程设置较低的优先级，操作系统将完成其余的工作，并根据需要执行工作循环。 Server 2003（以及大多数服务器操作系统）非常擅长，无需自己尝试和管理。
If you simply give your threads a low priority, the OS will do the rest, and take cycles as it needs to do work. Server 2003 (and most Server OSes) are very good at this, no need to try and manage it yourself.
我还使用 80% 作为目标 CPU 利用率的一般经验法则。正如其他一些人提到的，这为偶发的活动峰值留下了一些空间，并将有助于避免 CPU 的抖动。
以下是 Weblogic 团队关于此问题的一些（较旧但仍然相关的）建议：http://docs.oracle.com/cd/E13222_01/wls/docs92/perform/basics.html#wp1132942
如果您觉得负载非常均匀且可预测，您可以推动该目标稍微高一点，但除非您的用户群特别能容忍周期性的缓慢响应，并且您的项目预算非常紧张，否则我建议您向系统添加更多资源（添加 CPU、使用具有更多内核的 CPU 等）尝试从现有平台中挤出另外 10% 的 CPU 利用率是一个冒险的举动。
I have also used 80% as a general rule-of-thumb for target CPU utilization. As some others have mentioned, this leaves some headroom for sporadic spikes in activity and will help avoid thrashing on the CPU.
Here is a little (older but still relevant) advice from the Weblogic crew on this issue: http://docs.oracle.com/cd/E13222_01/wls/docs92/perform/basics.html#wp1132942
If you feel your load is very even and predictable you could push that target a little higher, but unless your user base is exceptionally tolerant of periodic slow responses and your project budget is incredibly tight, I'd recommend adding more resources to your system (adding a CPU, using a CPU with more cores, etc.) over making a risky move to try to squeeze out another 10% CPU utilization out of your existing platform.