我正在管理 HTC 集群中的计算节点。该节点是一台 56 核/112 线程双 Xeon 机器，典型工作负载由许多单线程蒙特卡罗模拟作业实例组成。基准测试表明，吞吐量可以很好地随作业数量增加而扩展，最多可达 56 个，但由于 turbo boost 频率无法持续处理大量活动作业，因此存在一些非线性。所有这些对我来说都很有意义，我认为这是预期的行为。
我不太明白的是，随着作业数量的增加，扩展几乎完全丧失了。作业数量增加到 64 个甚至更高，达到 112 个时，吞吐量保持不变：并行运行更多作业的好处完全被单个作业的较长持续时间所抵消。我知道对于超线程来说，扩展远非线性，但零扩展让我有点吃惊。
基于我对超线程工作原理的有限了解，我猜测它可能对运行同一进程的两个线程有效，但对运行两个单独的进程无效。我需要对此进行一些确认，以排除故障的假设并最终禁用超线程。
答案1
简化的超线程利用了这样一个事实：在许多进程线程中，内核通常会等待其他任务完成，此时存在空闲时间。通过在两个线程之间切换，处理器内核在一个线程中等待时不会处于空闲状态，而是可以在另一个线程中执行一些有用的操作。参见https://www.intel.com/content/www/us/en/gaming/resources/hyper-threading.html
在特定工作负载下，这种等待时间可能非常少，因此单个线程已经完全加载单个核心。与另一个线程共享该核心不会带来任何整体好处。
答案2
糟糕的类比：超线程，或者一般的 SMT，就像分时度假物业。一年 52 周都安排好时间没问题，每个人都可以独享这处房产。再多找几个人加入计划，甚至可能仍然有效，利用设施因取消而闲置的时间。但更多的重复预订不会神奇地将一栋房子变成两栋。
CPU 核心有多种类型的执行单元，包括整数、浮点和其他类型。但数量有限。（在 CPU 设计中，有框图可以查看这些单元，例如卡斯凯德湖）超标量架构正在尝试榨干多个每时钟指令数已经。因此，虽然另一个硬件线程可能会借用一个未使用的整数单元一个周期，但它必须共享。而且内存总是太慢，很可能 DRAM 和总线带宽才是真正的限制因素。
测试逐渐增加的作业数量是查看 SMT 收益递减的绝佳方式。尤其是对于计算繁重的 HTC 工作负载，这种工作负载可能相当稳定且可预测。您的 CPU 使用率大致为 115%，这大致符合我的预期。没有必要再提高。