最佳CPU利用率阈值

Question

我构建了在Windows 2003服务器上部署的软件。该软件不断作为服务运行，它是Windows盒子上唯一对我很重要的应用程序。部分时间，它从互联网上检索数据，部分时间是对数据进行一些计算。它是多线程的 - 我使用大约4-20个线程的线程池。

我不会厌倦所有这些细节，但足以说明，当我在池中启用更多线程时，会发生更多并发工作，并且CPU使用率会上升。 （对于其他资源的需求，比如带宽，虽然这对我来说并不重要 - 我有很多）

我的问题是：我是否应该尝试最大限度地利用CPU以获得最佳效果？直觉上，我认为以100％CPU运行并不合理;即使95％的CPU看起来很高，几乎就像我没有给操作系统提供足够的空间去做它需要做的事情。我不知道找出最佳平衡的正确方法。我猜测我可以测量和测量，并且可能发现最佳吞吐量是在CPU平均利用率为90％或91％等情况下实现的，但...... ...

我只是想知道这是否有一个很好的经验法则？我不想假设我的测试会考虑各种工作负载变化。我宁愿玩它有点安全，但不太安全（或者我没有使用我的硬件）。

你推荐什么？ Windows上的多线程，混合负载（某些I / O，某些CPU）应用程序的智能，具有性能意识的使用规则是什么？

Answer 1

CPU利用率在此i / o密集型工作负载中无关紧要，您关心吞吐量，因此请尝试使用hill climbing approach并基本上尝试以编程方式注入/删除工作线程并跟踪完成进度......

如果你添加一个线程并且它有帮助，那就添加另一个。如果你尝试一个线程，它会伤害它。

最终这将稳定下来。

如果这是一个基于.NET的应用程序，则会在.NET 4线程池中添加爬山功能。

更新：

爬坡是一种基于控制理论的最大化吞吐量的方法，如果你愿意，可以称之为试验和错误，但这是一种合理的方法。一般来说，这里没有一个好的“经验法则”，因为开销和延迟变化太大，实际上不可能概括。重点应放在吞吐量和数量上。任务/线程完成，而不是CPU利用率。例如，通过粗略或细粒度的同步很容易将核心挂起，但实际上并没有对吞吐量产生影响。

同样关于.NET 4，如果你可以将你的问题重新定义为Parallel.For或Parallel.ForEach，那么线程池将调整线程数以最大化吞吐量，因此你不必担心这一点。

-Rick

Answer 2

是的，我建议100％是颠簸，所以不希望看到进程像这样一直运行。我总是瞄准80％，以便在利用率和峰值/临时流程空间之间取得平衡。

我过去使用的一种方法是慢慢调高池大小并测量影响（包括CPU和其他约束，如IO），你永远不会知道，你可能会发现突然IO成为瓶颈

Answer 3

假设没有其他重要的事情，但操作系统在机器上运行：

你的负载是恒定的，你应该瞄准100％的CPU利用率，其他一切都是浪费CPU。请记住操作系统处理线程，因此它确实能够运行，很难使操作系统与一个表现良好的程序一样匮乏。

但是如果您的负载是可变的并且您应该考虑峰值，我会说80％CPU是一个很好的使用阈值，除非您确切知道该负载将如何变化以及它将需要多少CPU，在这种情况下，您可以瞄准确切的数字。

Answer 4

如果你只是给你的线程一个低优先级，操作系统将完成其余的工作，并根据需要采取循环工作。 Server 2003（以及大多数服务器操作系统）非常擅长，无需亲自尝试管理它。

Answer 5

我还使用80％作为目标CPU利用率的一般经验法则。正如其他人所提到的那样，这为活动中的零星尖峰留下了一些空间，并有助于避免在CPU上发生颠簸。

以下是Weblogic工作人员就此问题提出的一些（较旧但仍然相关）建议：http://docs.oracle.com/cd/E13222_01/wls/docs92/perform/basics.html#wp1132942

如果您认为自己的负载非常均匀且可预测，那么您可以将目标推高一点，但除非您的用户群特别容忍定期缓慢响应并且您的项目预算非常紧张，否则我建议您添加更多系统资源（添加CPU，使用具有更多内核的CPU等）而不是冒险尝试从现有平台中挤出10％的CPU利用率。