我用午休dft 包在 CentOS 8（核心）系统上，该系统具有 16 核、32 线程 XEON 处理器，并使用 OpenMPI 版本 4.1.1 进行所有计算。
因为我有 32 个线程，所以我使用其中 28 个进行 SIESTA 计算（消耗大量内存~60%），并保持剩余 4 个线程空闲。
但是，如果我开始将剩余的 2 个或 3 个线程用于其他应用程序（其内存使用量可以忽略不计），同时将 SIESTA 计算保持在 28 个线程，我发现 SIESTA 计算的速度下降了约 50-60%。
我检查了 CPU 利用率，发现在场景 2 中使用系统时，有一个线程几乎处于空闲状态。
有没有办法诊断并解决这个问题？这是因为某些进程调度错误而发生的吗？可以使用某种进程绑定或作业调度包来改进这个问题吗？
答案1
CPU 利用率作为简单的百分比无法传达多核、多线程、多执行单元 CPU 和内存的复杂性。几乎可以肯定CPU 实际上停滞在内存或缓存上而那些确实拥有数据的进程将会争夺执行单元。
此 CPU 只有 16 个内核。如您所发现的，将其视为 32 个内核在某些时候会严重降低性能。即使使用 SMT 2。也许您可以将线程数增加到内核的 125%（20），但 175%（28）会超出这个范围。尤其是在运行其他程序的情况下。减少线程数。
确保计算出每秒每个线程完成的有用工作。进行实验，一次更改一个变量。如果您可以访问这些处理器，也许可以尝试具有不同缓存和核心数配置的处理器。
使用性能监控计数器测量您的停滞程度。在 VM 中不起作用，但在 Linux 上值得一试。来自我之前链接的 Gregg：
perf stat -a -- sleep 10
Xeon 的理论最高速度是每周期 4 或 5 条指令。您无法达到这个速度，但 < 1.0 IPC 会因内存而额外停滞。
一定要了解应用程序的代码和热点。哪些函数在 CPU 上花费的时间最多？哪些汇编代码受到的影响最大？您的 CPU 上的哪些执行单元在处理这些 uop 时工作最努力？
火焰图非常适合对 CPU 函数进行可视化。您提到了 EL 8，它具有封装好的火焰图工具。
yum install perf js-d3-flame-graph
# system wide, 99 Hz, for 60 seconds
perf script flamegraph -a -F 99 sleep 60
需要开发人员对程序有一定程度的理解才能充分解释结果。使用符号或源代码，性能报告可以注释在类似调试器的体验中。