最佳CPU利用率阈值

Question

我开发了一款软件，它在Windows 2003服务器上运行。该软件连续作为服务运行，并且是我关注的Windows设备上唯一的应用程序。它有时从互联网检索数据，有时计算这些数据。它是多线程的 - 我使用大约4-20个线程的线程池。 如果我增加线程池中的线程数，那么并发工作就会增多，并且CPU使用率也会升高。我的问题是：我应该尝试让CPU达到最大值以获得最佳性价比吗？直觉告诉我，跑在100％的CPU上似乎不太合理；即使是95％的CPU也很高，几乎没有给操作系统留出足够的空间去完成它需要做的事情。我不知道确定最佳平衡的正确方法。我猜测我可以测量并测量，可能会发现在CPU平均利用率为90％或91％等时获得最佳吞吐量，但是... 我只是想知道是否有一个好的经验法则？我不希望假定我的测试将考虑到各种工作负载的变化。我宁愿保守一点，但又不能太保守（否则我会浪费我的硬件）。 你有什么建议？在Windows上运行的多线程、混合负载（一些I/O，一些CPU）应用程序的智能、高性能利用规则是什么？

- kvista

Answer 1

我建议不要让进程一直以100%的速度运行，这会导致系统崩溃。我通常将利用率控制在80%，以平衡利用率和突发进程。

过去我采用的方法是逐步增加池大小并测量其影响（包括CPU和其他限制，如IO），您永远不知道，也许突然之间IO成为瓶颈。

- Toby

Answer 2

在这个I/O密集型的工作负载中，CPU利用率并不重要，您需要关注吞吐量，因此尝试使用山岭爬升方法，基本上尝试以编程方式注入/删除工作线程并跟踪完成进度... 如果添加一个线程有帮助，请添加另一个线程。如果尝试一个线程会有害，请将其删除。 最终，这将稳定下来。 如果这是一个基于.NET的应用程序，则.NET 4线程池中添加了山岭爬升。 更新： 山岭爬升是一种控制理论的方法，旨在最大化吞吐量，如果您想，可以称之为试错，但这是一种可靠的方法。总的来说，这里没有一个好的“经验法则”可以遵循，因为开销和延迟变化如此之大，不可能概括。重点应放在吞吐量和任务/线程完成上，而不是CPU利用率。例如，使用粗粒度或细粒度同步很容易使核心饱和，但实际上对吞吐量没有影响。 此外，关于.NET 4，如果您可以将问题重新构建为Parallel.For或Parallel.ForEach，则线程池将调整线程数以最大化吞吐量，因此您不必担心这个问题。 - Rick

- Rick

---

我很赞赏你的爬山算法，但我特别想要一些经验法则，而不是试错方法，如果需要的话，我可以自己尝试。 - kvista

他说的是.NET 4线程池会自动为您进行试错，如果您感兴趣的话，这非常有趣。 - Vinko Vrsalovic

Answer 3

假设除了操作系统之外，机器上没有其他重要的内容：

如果你的负载是恒定的，你应该以100%的CPU利用率为目标，其他一切都是浪费CPU。请记住，操作系统处理线程，因此它确实能够运行，在行为良好的程序中很难使操作系统饿死。

但是，如果你的负载是变量的，并且你预计会有高峰期，那么你应该考虑使用80%的CPU作为一个好的阈值，除非你确切地知道负载将如何变化以及需要多少CPU，那么你可以瞄准精确的数字。

- Vinko Vrsalovic

Answer 4

如果您只是给您的线程一个较低的优先级，操作系统会自动处理并按需获取 CPU 时间。 Server 2003（以及大多数服务器操作系统）非常擅长此项工作，因此无需尝试自行管理。

- Nick Craver

---

如果您给线程正常优先级，操作系统很可能会执行相同的操作。您不想做的是给它们高优先级。 - Vinko Vrsalovic

Answer 5

我通常将CPU利用率的目标设为80%。正如其他人所提到的，这会留出一些余地以应对偶发性的活动高峰，并有助于避免CPU过载。

以下是Weblogic团队在这个问题上给出的一些（虽然有点老但仍然相关）建议：http://docs.oracle.com/cd/E13222_01/wls/docs92/perform/basics.html#wp1132942

如果你觉得负载非常均衡和可预测，你可以将目标设得更高一些，但除非你的用户群体对周期性的缓慢响应非常宽容，而且你的项目预算非常紧张，否则我建议增加系统资源（添加一个CPU，使用一个拥有更多核心的CPU等），而不是冒险尝试从现有平台中挤出另外10%的CPU利用率。

- rscarter