--oversubscribe -np 256 在 64 核服务器上会发生什么

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

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

进程数调度策略

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

实时状态

已启动进程

每核平均进程

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 核服务器应有的跑法。