5

我已经构建了部署在 Windows 2003 服务器上的软件。该软件作为一项服务持续运行，它是 Windows 机器上对我来说唯一重要的应用程序。部分时间，它从 Internet 检索数据，部分时间它对这些数据进行一些计算。它是多线程的——我使用大约 4-20 个线程的线程池。

我不会对所有这些细节感到厌烦，但我只想说，当我在池中启用更多线程时，会发生更多并发工作，并且 CPU 使用率会上升。（就像对带宽等其他资源的需求一样，虽然这对我来说无关紧要——我有很多）

我的问题是：我是否应该简单地尝试最大化 CPU 以获得最大的收益？直觉上，我认为以 100% CPU 运行是没有意义的。甚至 95% 的 CPU 似乎都很高，几乎就像我没有给操作系统太多空间来做它需要做的事情。我不知道确定最佳平衡的正确方法。我想我可以测量和测量，并且可能会发现最佳吞吐量是在 CPU 平均利用率为 90% 或 91% 等时实现的，但是......

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

你有什么建议吗？对于 Windows 上的多线程、混合负载（一些 I/O、一些 CPU）应用程序，什么是智能的、注重性能的利用规则？

4

5 回答 5

6

是的，我建议 100% 正在颠簸，所以不想看到进程一直这样运行。我一直以 80% 的目标为目标，以在利用率和尖峰/临时流程空间之间取得平衡。

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

于 2010-02-24T18:46:02.310 回答
4

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

如果您添加一个线程并且它有帮助，请添加另一个线程。如果您尝试使用线程并且很痛，请将其移除。

最终这将稳定下来。

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

更新：

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

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

-瑞克

于 2010-02-20T17:21:30.077 回答
3

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

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

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

于 2010-02-20T11:54:18.700 回答
1

如果你只是简单地给你的线程一个低优先级，操作系统会做剩下的事情，并在它需要工作的时候循环。Server 2003（和大多数服务器操作系统）在这方面非常擅长，无需自己尝试和管理。

于 2010-02-20T11:53:11.410 回答
0

我还使用 80% 作为目标 CPU 利用率的一般经验法则。正如其他一些人所提到的，这为活动的零星峰值留出了一些空间，并将有助于避免 CPU 上的颠簸。

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

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

于 2015-09-23T16:11:34.517 回答