mpirun --oversubscribe -np 256 在 64 物理核上执行模拟

模拟 256 个 MPI 进程争抢 64 个物理核心时，操作系统调度器、缓存、内存带宽发生了什么

空闲 1 进程 2–3 进程 4+ 进程（严重争抢） 上下文切换中

实时状态

已启动进程
0
每核平均进程
0.0
上下文切换 / 秒
0
有效并行度
—

整体计算进度

实际进度 0%
理想进度（64 进程正常跑）0%

理想进度 = 假设 64 进程无争抢时的线性完成度；实际进度 = 超订后真实推进速度。

mpirun 输出日志（模拟）

会发生什么

✅ 好消息：能跑起来

  • MPI 不会拒绝启动 256 个进程
  • OpenFOAM 能读到 256 个分解块，不会报错退出
  • 结果在数学上通常是对的（除非有竞态）
  • 适合“我只想验证案例能不能跑通”

❌ 坏消息：性能崩了

  • 上下文切换暴增：每个核上 4 个进程轮流上 CPU，切换开销吃掉大量时间
  • 缓存全部失效：进程被换出后 L1/L2/L3 数据被冲掉，回来时全是 cache miss
  • 内存带宽打满：256 个进程同时抢内存总线，带宽成为瓶颈
  • MPI 通信拥塞：256 个进程在同一台机器上走共享内存/网络，消息排队
  • 可能比 64 核正常跑还慢，极端情况慢 2–5 倍
  • 内存可能爆：256 个进程各占一份内存，物理内存不够时触发 swap 或 OOM Killer

正确做法：重新分解为 64 核

# 1. 编辑 system/decomposeParDict，把 numberOfSubdomains 从 256 改成 64
numberOfSubdomains 64;

method scotch;   # 或 hierarchical / simple

# 2. 重新分解
decomposePar -force

# 3. 正常并行运行（不再需要 --oversubscribe）
mpirun -np 64 yourSolver -parallel

推荐 重新分解后，每个进程独占一个物理核，缓存命中率高、无上下文切换、内存和 MPI 压力都正常， 这才是 64 核服务器应有的跑法。