我在具有 16 核、32 线程 XEON 处理器和 OpenMPI 版本 4.1.1 的 CentOS 8（核心）系统上使用SIESTA dft 包进行所有计算。
因为我有 32 个线程，所以我使用其中的 28 个来进行 SIESTA 计算（这会消耗大量内存 ~60%）并保持剩余的 4 个空闲。
但是，如果我开始将 2 或 3 个剩余线程用于其他应用程序（内存使用量可以忽略不计），同时将 SIESTA 计算保持在 28 个线程，我发现 SIESTA 计算的速度降低了大约 50-60 %。
我检查了 CPU 利用率，发现在场景 2 中使用系统时，一个线程几乎保持空闲状态。
有没有办法诊断和解决这个问题？这是因为某些进程调度错误而发生的吗？可以使用某种流程绑定或作业调度包来改善这一点吗？
CPU 利用率作为一个简单的百分比无法传达多核、多线程、多执行单元 CPU 和内存的复杂性。几乎可以肯定CPU 实际上在内存或缓存上停滞不前。拥有数据的进程将争夺执行单元。
这个 CPU 只有 16 个核心。正如您所发现的，将其视为 32 会在某些时候严重降低性能。即使使用 SMT 2。也许您可以将线程数增加到 125% 的内核 (20)，但 175% (28) 正在推动它。尤其是在其他事情运行的情况下。退回线程。
确保计算每线程每秒完成的有用工作。实验，一次改变一个变量。如果您可以访问这些配置，也许可以尝试具有不同缓存和核心计数配置的处理器。
使用性能监控计数器衡量您的停滞程度。无法在 VM 中工作，但值得在 Linux 上尝试。来自我之前链接的 Gregg：
Xeons 的理论最高速度是每个周期 4 或 5 条指令。你不会明白，但 < 1.0 IPC 在内存上会额外停滞。
一定要了解应用程序的代码和热点。哪些功能在 CPU 上花费的时间最多？哪些汇编代码受到的打击最大？尤其是 CPU 上的哪些执行单元最努力地处理这些微指令？
火焰图非常适合可视化 CPU 功能。您提到了 EL 8，它具有打包的火焰图工具。
对程序的开发人员级别的理解对于完全解释结果是必要的。使用符号或源代码，性能报告可以在类似调试器的体验中进行注释。