胖树架构HPC中进程数增加时出现运行减速问题咨询

你观测到的进程数达64时执行时间大幅跳升的现象，确实大概率和胖树架构的固有特性直接相关，也可能存在MPI通信模式、进程调度规则的叠加影响，具体分析如下：

胖树架构触发性能拐点的核心逻辑 #

• 胖树采用分层交换设计，标准部署分为叶交换层（直接接入计算节点）、脊交换层（跨叶层转发流量）两层结构。同叶交换层下的节点通信无需经过上层转发，路径最短、带宽无收敛，通信开销最低。
• 进程数从2扩容到8时，所有进程大概率都运行在同一个叶交换机接入的计算节点范围内，通信都在叶层完成，因此执行时间随进程数增加持续下降。
• 当进程数扩容到64时，作业需要占用多个叶交换机下的计算节点，跨叶节点的通信流量必须经过脊交换层转发，此时会引入两个固定额外开销：
  • 通信跳数增加导致的消息延迟上升
  • 脊层端口带宽存在收敛比（通常为2:1到5:1不等），导致跨节点通信带宽下降

可能放大跳升幅度的叠加因素 #

• 进程亲和性配置缺失：如果作业调度没有做节点/机架亲和性绑定，64个进程可能被分散分配到多个不相邻的叶交换机下，跨层通信的占比会进一步提升，开销被放大。
• 集体通信操作开销陡增：如果测试程序用到MPI_Allgather、MPI_Allreduce等集体通信接口，跨叶节点的集体通信算法复杂度远高于同叶节点，通信开销会出现量级级别的上升。
• 通信计算比倒挂：当进程数超过阈值后，单进程分配的计算量过小，通信开销占比超过计算开销占比，原本的并行收益被通信开销抵消，这一通用并行定律和胖树的架构特性叠加，会让执行时间跳升的表现更明显。

验证方案 #

你可以通过以下操作确认根因是否为胖树架构特性：

• 提交作业时强制所有进程运行在单台计算节点内，观测64进程下是否还会出现性能跳升，如果跳升消失即可确认是跨节点跨胖树层通信导致。
• 运行mpirun时添加--bind-to core参数固定进程绑核规则，排除进程调度漂移带来的额外开销。

内容的提问来源于stack exchange，提问作者Mav