超线程和 htop/system-monitor

超线程和 htop/system-monitor

我在启用了超线程的四核 Xenon E5520 上运行大量模拟。我的软件会自动检测 8 个(虚拟)核心并启动 8 个模拟以并行运行。但是 htop 和系统监视器仅显示 8 个核心中的每一个都已加载到约 50%。

这是预期的行为吗?从某种意义上说,这是有道理的,因为每个物理核心的总负载将是 400% 或 100%,但我不应该得到更多吗?我的意思是这就是 HT 的目的,对吧?使用 SMT 使用原本未使用的执行单元来运行另一个线程。所以吞吐量应该更高,对吧?

我应该提到,负载非常稳定,每个核心始终为 50%。模拟由 Java 在单个 JVM 中运行,GC 不是问题,我远远低于 JVM 堆限制。模拟不受内存限制,有足够的空间,没有交换。模拟将大量数据写入磁盘,但有大型缓冲区(每个线程 128MB 写入缓冲区),并且 gkrellm 显示的磁盘活动频繁爆发约 90MB/s,但负载不稳定,我不相信这可能是瓶颈。

有人可以解释一下这个问题吗?

答案1

然而 htop 和 system-monitor 只显示 8 个核心中的每一个的负载约为 50%。

好的,这仅仅意味着您没有同时运行足够多的模拟。有很多因素可能导致模拟没有 100% 使用核心。要么您修复这些问题,要么您只是添加更多模拟。

但我难道不应该得到更多吗?

您应该能够在每个核心上获得 100%。

现在,如果你读了 Khaledds 的半知半解...事实如下:

  • 超线程意味着两个核心并不拥有所有功能,这是事实,因此例如两个核心不能同时执行某些操作。
  • 但不幸的是,这对操作系统来说是不可见的。CPU“负载”因素基于“每个操作系统调度程序中核心忙碌的时间百分比”。因此,如果 CPU 核心每秒有 400 毫秒的活动任务,则其忙碌率为 40%。

超线程资源匮乏(即虚拟核心必须等待资源)将简单地意味着虚拟核心需要更长的时间来执行操作 - 但这对于操作系统调度程序来说是不可见的。如果核心花费 100 毫秒在内部等待,则任务将花费 500 毫秒而不是 400 毫秒。尝试找出何时遇到资源匮乏是相当复杂的,而且这不是操作系统可以做的事情(即,您需要运行特殊代码并比较运行时间以查看哪个花费的时间比应有的时间长 = 超线程“糟糕”。如果 CPU 会调整出细粒度的内部使用情况统计数据,您几乎可以告别任何性能 - 这是太多的数据。

结果是第二个核心根本不会增加 100% 的性能 - 所以如果某件事在一个核心上花费 100 毫秒,那么使用超线程和 2 个核心可能需要 75 毫秒,而不是 50 毫秒。但是,这在很大程度上取决于代码。

对于您的情况,我会从单线程开始,看看是否可以将一个核心的利用率提高到 100%。如果不能,那么模拟只是在等待某些东西 - 如果有的话,这是一个 stackoverflow 问题(必须更改程序)。如果情况确实如此(IO、从磁盘写入/读取),那么每个核心运行多个模拟可能只是必要的。

相关内容