拓冰网站定制 
简介这份文档面向高性能计算领域的架构师、运维工程师及科研计算人员系统梳理HPC集群从基础概念到落地设计的完整知识框架帮助读者理解如何构建满足科研与工程需求的高速计算环境。资源包内含1个docx文档约979KB内容涵盖HPC系统组成、性能指标计算、分类方法及主流技术选型等核心模块。文档从计算、存储、网络、集群软件四部分切入讲解单节点性能公式、高吞吐与分布计算的差异并展开X86处理器、Linux系统、刀片架构及IB/10GE互联等主流方案同时区分MPI节点、胖节点与GPU加速节点的适用场景。此外还涉及Linpack基准测试、DIMM内存类型对比及HPC在气象、材料、生命科学、金融等领域的应用与市场趋势。目前已有225人学习适合需要快速建立HPC架构认知或为方案设计提供参考的技术人员。1. 从一台机器到一千个节点HPC 高性能计算架构设计到底在解决什么很多人第一次接触 HPC 高性能计算架构设计是从一台双路服务器开始的。跑个小规模算例CPU 利用率拉满觉得性能不过如此。等到算例放大十倍、并行进程数从 8 涨到 800问题就全冒出来了节点间通信成了瓶颈存储 IO 跟不上作业排队几小时跑几分钟运维靠手工 ssh 一台台查。这时候你才意识到HPC 架构设计不是把一堆高配机器堆在一起而是要让计算、网络、存储、调度、运维这五层协同工作任何一层拖后腿整机性能就塌方。这篇文章面向的是正在规划或改造 HPC 集群的工程师不管你是要建一个几十节点的部门级集群还是要优化现有几百节点的超算平台下面这套从架构分层到参数落地的思路都能直接拿去用。我不会只讲概念每个关键决策点都会给出可操作的配置片段和排查方法让你看完能动手动手能跑通。2. 计算节点选型与并行度设计别让最慢的那个核拖死整机2.1 为什么核数越多不一定越快HPC 集群里最常见的翻车场景是买了 128 核的节点跑 CFD 算例却比 64 核还慢。原因通常不在 CPU 本身而在内存带宽和并行通信开销。每个 MPI 进程都要读写内存核数翻倍后内存带宽被摊薄同时进程间通信量呈指数增长。当计算时间占比低于通信时间加核就是负优化。我一般会先做一件事用 STREAM 基准测出单节点的实际内存带宽再结合应用的特征计算密集还是访存密集确定每节点核数上限。经验值是CFD 类应用每核至少需要 2GB/s 的有效带宽如果 STREAM 实测三通道内存只有 60GB/s那 32 核就是甜点区再往上收益急剧下降。2.2 用 Slurm 做并行度调优的最小验证选好硬件后第一件事是验证并行效率。下面这个脚本用 Slurm 提交一组不同进程数的作业自动采集运行时间帮你找到该算例的最佳并行度。#!/bin/bash # parallel_scan.sh - 扫描不同进程数下的运行时间 # 用法: sbatch parallel_scan.sh #SBATCH --job-nameparallel_scan #SBATCH --nodes4 #SBATCH --ntasks-per-node32 #SBATCH --time01:00:00 #SBATCH --outputscan_%j.log for np in 8 16 32 64 128; do echo Testing NP$np start$(date %s.%N) srun -n $np ./my_app --input case.dat /dev/null 21 end$(date %s.%N) elapsed$(echo $end - $start | bc) echo NP$np elapsed$elapsed done这段脚本的关键在于srun -n动态指定进程数而不是在 SBATCH 头里写死。--nodes4和--ntasks-per-node32只是资源上限实际进程数由循环控制。跑完后把 NP 和 elapsed 画成曲线拐点就是最佳并行度。如果 128 进程比 64 进程还慢说明通信开销已经吃掉计算收益该考虑混合 MPIOpenMP 模型了。提示测试时务必关闭其他负载并且每个 NP 至少跑三次取中位数否则缓存和网络抖动会让结果不可信。3. 网络互联架构InfiniBand 和 RoCE 怎么选、怎么调3.1 延迟敏感型应用必须上 InfiniBand 吗网络是 HPC 架构设计里最容易被低估的一环。很多人觉得万兆以太网够用结果 MPI_Allreduce 一跑就卡住。InfiniBand 的微秒级延迟和 RDMA 特性在超过 64 节点的集群里几乎是刚需。但如果你只有 16 个节点跑的是 embarrassingly parallel 任务RoCEv2 配合 PFC 流控也能凑合成本能省一半。选型时看三个指标节点间 MPI 点对点延迟、Allreduce 带宽、以及是否支持 SHARP可扩展分层聚合和归约协议。SHARP 能把集合通信卸载到交换机上对深度学习训练和气象模式这类频繁 Allreduce 的场景提升巨大。我一般会要求供应商提供实测的 osu_latency 和 osu_allreduce 数据而不是只看理论带宽。3.2 InfiniBand 子网管理器与 PFC 配置要点InfiniBand 网络需要 Subnet Manager 来管理路由和连接。常见做法是在管理节点上跑 opensm并配置为高可用模式。下面是一个最小化的 opensm 配置片段# /etc/opensm/opensm.conf 关键参数 # 启用高可用主备 SM 自动切换 sm_priority 15 # 路由算法选择fat-tree 拓扑用 minhop 或 updn routing_algorithm minhop # 日志级别调试时调成 0x03 log_level 0x01 # 扫描周期默认 10 秒大集群可适当调大 sweep_interval 30sm_priority决定主备关系数值大的为主。routing_algorithm在 fat-tree 下用 minhop 能获得最低延迟但链路利用率不如 updn 均衡。sweep_interval控制拓扑扫描频率节点多的时候频繁扫描会带来额外开销30 秒是个折中值。对于 RoCEv2 方案PFC 和 ECN 是必调项。PFC 要在交换机和网卡两端都配优先级要和 DSCP 映射一致否则丢包重传会让 RDMA 性能断崖式下跌。我踩过的坑是交换机配了 PFC 但服务器网卡没配结果跑起来延迟比 TCP 还高。注意InfiniBand 和 RoCE 的调优参数在 Mellanox/NVIDIA 网卡上用mlnx_tune可以一键优化但生产环境建议逐项确认不要盲目信任自动调优。4. 存储与文件系统并行 IO 不是加硬盘就能解决的4.1 Lustre 还是 GPFS看你的 IO 模式HPC 存储选型取决于应用的 IO 模式。如果大量小文件随机读写Lustre 的元数据性能可能成为瓶颈需要配独立的 MDS 和 MDT。如果是大文件顺序读写比如气象、地震数据Lustre 的 OST 聚合带宽优势明显。GPFS现在叫 IBM Storage Scale在元数据管理和多站点同步上更成熟但授权费用高。我一般会先跑一遍 IO 基准用 IOR 测出不同块大小下的读写带宽再决定 OST 数量和 RAID 级别。经验是每 100 个计算节点至少配 4 个 OST每个 OST 用 82 RAID6这样单 OST 故障不会影响整体可用性。4.2 用 IOR 摸清存储真实带宽下面这个 IOR 命令能帮你快速测出并行文件系统的实际吞吐# 使用 16 个进程每个进程写 4GB块大小 1MB mpirun -np 16 ior -a POSIX \ -b 1m \ # 单次传输块大小 -t 4g \ # 每个进程写入总量 -F \ # 每个进程独立文件 -w \ # 写测试 -r \ # 读测试 -o /lustre/ior_test-b是单次 IO 块大小小文件场景调小到 4k大文件场景调到 4m 以上。-F让每个进程写独立文件避免元数据锁竞争。跑完后看 Max Write 和 Max Read如果远低于存储标称带宽检查 OST 是否成为热点或者客户端挂载参数是否合理。Lustre 客户端挂载时max_read_ahead_mb和max_pages_per_rpc对读性能影响很大通常调到 64MB 和 1024 能显著改善。提示IOR 测试会写满存储务必指定测试目录并提前清理别把生产数据盘写爆了。5. 调度与运维Slurm 配置里那些让你半夜被叫醒的坑5.1 节点状态异常与作业排队排查Slurm 集群最常见的故障是节点被标记为 drain 或 down导致作业排队但没人发现。下面这个命令组合能快速定位问题节点# 查看所有节点状态过滤非 idle 节点 sinfo -N -o %N %T %E | grep -v idle # 查看具体节点的详细原因 scontrol show node node[001-010] # 恢复节点先 resume 再 undrain scontrol update NodeNamenode001 StateRESUME scontrol update NodeNamenode001 StateUNDRAIN%E会显示节点不可用的原因常见的有Not respondingslurmd 挂了、Low socket内存或 CPU 故障、Kill task failed作业清理失败。我一般会写个定时脚本每 5 分钟扫一次发现 drain 节点自动发告警避免等到用户投诉才知道。5.2 用 cgroup 限制资源防止单用户打爆集群没有资源限制的 HPC 集群迟早会被某个跑飞的任务拖垮。Slurm 配合 cgroup 能精确控制每个作业的 CPU、内存和 GPU 用量。下面是一个 cgroup 配置片段# /etc/slurm/cgroup.conf CgroupAutomountyes ConstrainCoresyes ConstrainRAMSpaceyes ConstrainSwapSpaceyes AllowedRAMSpace95 AllowedSwapSpace0 MaxRAMPercent95ConstrainCoresyes确保作业只能用分配给它的核防止越界抢占。AllowedRAMSpace95表示作业内存超过分配量的 95% 就触发 OOM kill而不是等到把节点内存吃光。AllowedSwapSpace0禁用 swap因为 HPC 应用一旦用 swap 性能就崩了不如直接杀掉让用户改代码。注意cgroup v2 和 v1 的配置项名称不同Slurm 版本不同支持程度也不一样升级前务必在测试环境验证。6. 避坑与常见问题那些让我半夜爬起来处理的故障6.1 MPI 作业启动即挂报错btl_openib_handle_internal_errors现象作业提交后秒退日志里全是 InfiniBand 相关错误。原因通常是 OFED 驱动版本和 MPI 库不匹配或者 IB 网卡处于 down 状态。解决先用ibstat确认端口 State 是 Active再用ofed_info -s查驱动版本对照 MPI 厂商的兼容性矩阵升级或降级。我一般会在镜像里固定 OFED 和 MPI 版本不让用户自己编译。6.2 存储挂载点卡死导致所有节点负载飙升现象df -h卡住ls /lustre无响应计算节点 load average 冲到几百。原因通常是 MDS 或 OST 故障客户端在无限重试。解决在客户端挂载参数里加hard改为soft并设置timeo或者配failover模式。更关键的是监控 MDS 的 inode 使用率超过 80% 就要扩容否则元数据操作会越来越慢直到卡死。6.3 Slurm 作业排队但节点显示 idle现象squeue显示作业 PD 状态但sinfo显示节点 idle。原因可能是分区配置错误、QOS 限制、或者节点特征不匹配。解决用scontrol show job jobid看Reason字段常见的有QOSMaxCpuPerUserLimit、ReqNodeNotAvail。如果是特征不匹配检查NodeName的Features和作业的--constraint是否一致。6.4 GPU 作业跑着跑着报 ECC 错误现象训练任务中途崩溃日志里有Xid错误或ECC error。原因可能是 GPU 显存故障或散热问题。解决先用nvidia-smi -q看 ECC 错误计数如果 Uncorrectable 不为零直接报修换卡。临时方案是用nvidia-smi -r重置 GPU但治标不治本。我一般会在节点上跑dcgmi diag做定期健康检查提前发现隐患。6.5 用户抱怨文件权限混乱互相覆盖数据现象同一个项目组多人共用目录A 写的文件 B 改不了或者误删了 C 的数据。原因通常是 umask 设置不一致或者没有启用 ACL。解决在共享目录上设 setgid 位强制继承组权限并用setfacl给项目组统一授权。Slurm 提交时加--acctg-freq记录资源使用方便事后审计。7. 进阶技巧用 Slurm 的 topology 插件优化作业布局前面讲的都是单点配置真正拉开 HPC 架构设计水平的是作业在物理拓扑上的布局。Slurm 的topology/tree和topology/block插件能根据交换机层级把作业尽量调度到同一台 leaf 交换机下减少跨 spine 通信。配置方法是在slurm.conf里加TopologyPlugintopology/tree # 然后在 topology.conf 里定义交换机层级 SwitchNames1 Nodesnode[001-032] SwitchNames2 Nodesnode[033-064] SwitchNameroot Switchess1,s2这样 Slurm 会优先把作业分配到同一台 leaf 下的节点MPI 通信延迟能降 30% 以上。验证方法是跑一个 Allreduce 基准对比启用前后osu_allreduce的延迟变化。我一般会在集群交付前做这个对比测试作为验收指标之一。另一个技巧是给不同队列配不同的PriorityTier和PreemptType。比如紧急队列可以抢占普通队列的资源但被抢占的作业会自动 requeue不会丢。配置PreemptTypepreempt/qos和PreemptExemptTime00:05:00给用户 5 分钟保存现场。这些配置没有银弹每个集群的拓扑和负载特征都不一样。我的习惯是任何调优参数上线前先在测试分区跑一周用sacct收集作业运行数据对比调优前后的平均等待时间和运行时间。数据不会骗人别凭感觉调。希望帮到你。本文还有配套的精品资源点击获取 HPC高性能计算架构设计：从计算节点选型到Slurm调度与InfiniBand网络调优
简介这份文档面向高性能计算领域的架构师、运维工程师及科研计算人员系统梳理HPC集群从基础概念到落地设计的完整知识框架帮助读者理解如何构建满足科研与工程需求的高速计算环境。资源包内含1个docx文档约979KB内容涵盖HPC系统组成、性能指标计算、分类方法及主流技术选型等核心模块。文档从计算、存储、网络、集群软件四部分切入讲解单节点性能公式、高吞吐与分布计算的差异并展开X86处理器、Linux系统、刀片架构及IB/10GE互联等主流方案同时区分MPI节点、胖节点与GPU加速节点的适用场景。此外还涉及Linpack基准测试、DIMM内存类型对比及HPC在气象、材料、生命科学、金融等领域的应用与市场趋势。目前已有225人学习适合需要快速建立HPC架构认知或为方案设计提供参考的技术人员。1. 从一台机器到一千个节点HPC 高性能计算架构设计到底在解决什么很多人第一次接触 HPC 高性能计算架构设计是从一台双路服务器开始的。跑个小规模算例CPU 利用率拉满觉得性能不过如此。等到算例放大十倍、并行进程数从 8 涨到 800问题就全冒出来了节点间通信成了瓶颈存储 IO 跟不上作业排队几小时跑几分钟运维靠手工 ssh 一台台查。这时候你才意识到HPC 架构设计不是把一堆高配机器堆在一起而是要让计算、网络、存储、调度、运维这五层协同工作任何一层拖后腿整机性能就塌方。这篇文章面向的是正在规划或改造 HPC 集群的工程师不管你是要建一个几十节点的部门级集群还是要优化现有几百节点的超算平台下面这套从架构分层到参数落地的思路都能直接拿去用。我不会只讲概念每个关键决策点都会给出可操作的配置片段和排查方法让你看完能动手动手能跑通。2. 计算节点选型与并行度设计别让最慢的那个核拖死整机2.1 为什么核数越多不一定越快HPC 集群里最常见的翻车场景是买了 128 核的节点跑 CFD 算例却比 64 核还慢。原因通常不在 CPU 本身而在内存带宽和并行通信开销。每个 MPI 进程都要读写内存核数翻倍后内存带宽被摊薄同时进程间通信量呈指数增长。当计算时间占比低于通信时间加核就是负优化。我一般会先做一件事用 STREAM 基准测出单节点的实际内存带宽再结合应用的特征计算密集还是访存密集确定每节点核数上限。经验值是CFD 类应用每核至少需要 2GB/s 的有效带宽如果 STREAM 实测三通道内存只有 60GB/s那 32 核就是甜点区再往上收益急剧下降。2.2 用 Slurm 做并行度调优的最小验证选好硬件后第一件事是验证并行效率。下面这个脚本用 Slurm 提交一组不同进程数的作业自动采集运行时间帮你找到该算例的最佳并行度。#!/bin/bash # parallel_scan.sh - 扫描不同进程数下的运行时间 # 用法: sbatch parallel_scan.sh #SBATCH --job-nameparallel_scan #SBATCH --nodes4 #SBATCH --ntasks-per-node32 #SBATCH --time01:00:00 #SBATCH --outputscan_%j.log for np in 8 16 32 64 128; do echo Testing NP$np start$(date %s.%N) srun -n $np ./my_app --input case.dat /dev/null 21 end$(date %s.%N) elapsed$(echo $end - $start | bc) echo NP$np elapsed$elapsed done这段脚本的关键在于srun -n动态指定进程数而不是在 SBATCH 头里写死。--nodes4和--ntasks-per-node32只是资源上限实际进程数由循环控制。跑完后把 NP 和 elapsed 画成曲线拐点就是最佳并行度。如果 128 进程比 64 进程还慢说明通信开销已经吃掉计算收益该考虑混合 MPIOpenMP 模型了。提示测试时务必关闭其他负载并且每个 NP 至少跑三次取中位数否则缓存和网络抖动会让结果不可信。3. 网络互联架构InfiniBand 和 RoCE 怎么选、怎么调3.1 延迟敏感型应用必须上 InfiniBand 吗网络是 HPC 架构设计里最容易被低估的一环。很多人觉得万兆以太网够用结果 MPI_Allreduce 一跑就卡住。InfiniBand 的微秒级延迟和 RDMA 特性在超过 64 节点的集群里几乎是刚需。但如果你只有 16 个节点跑的是 embarrassingly parallel 任务RoCEv2 配合 PFC 流控也能凑合成本能省一半。选型时看三个指标节点间 MPI 点对点延迟、Allreduce 带宽、以及是否支持 SHARP可扩展分层聚合和归约协议。SHARP 能把集合通信卸载到交换机上对深度学习训练和气象模式这类频繁 Allreduce 的场景提升巨大。我一般会要求供应商提供实测的 osu_latency 和 osu_allreduce 数据而不是只看理论带宽。3.2 InfiniBand 子网管理器与 PFC 配置要点InfiniBand 网络需要 Subnet Manager 来管理路由和连接。常见做法是在管理节点上跑 opensm并配置为高可用模式。下面是一个最小化的 opensm 配置片段# /etc/opensm/opensm.conf 关键参数 # 启用高可用主备 SM 自动切换 sm_priority 15 # 路由算法选择fat-tree 拓扑用 minhop 或 updn routing_algorithm minhop # 日志级别调试时调成 0x03 log_level 0x01 # 扫描周期默认 10 秒大集群可适当调大 sweep_interval 30sm_priority决定主备关系数值大的为主。routing_algorithm在 fat-tree 下用 minhop 能获得最低延迟但链路利用率不如 updn 均衡。sweep_interval控制拓扑扫描频率节点多的时候频繁扫描会带来额外开销30 秒是个折中值。对于 RoCEv2 方案PFC 和 ECN 是必调项。PFC 要在交换机和网卡两端都配优先级要和 DSCP 映射一致否则丢包重传会让 RDMA 性能断崖式下跌。我踩过的坑是交换机配了 PFC 但服务器网卡没配结果跑起来延迟比 TCP 还高。注意InfiniBand 和 RoCE 的调优参数在 Mellanox/NVIDIA 网卡上用mlnx_tune可以一键优化但生产环境建议逐项确认不要盲目信任自动调优。4. 存储与文件系统并行 IO 不是加硬盘就能解决的4.1 Lustre 还是 GPFS看你的 IO 模式HPC 存储选型取决于应用的 IO 模式。如果大量小文件随机读写Lustre 的元数据性能可能成为瓶颈需要配独立的 MDS 和 MDT。如果是大文件顺序读写比如气象、地震数据Lustre 的 OST 聚合带宽优势明显。GPFS现在叫 IBM Storage Scale在元数据管理和多站点同步上更成熟但授权费用高。我一般会先跑一遍 IO 基准用 IOR 测出不同块大小下的读写带宽再决定 OST 数量和 RAID 级别。经验是每 100 个计算节点至少配 4 个 OST每个 OST 用 82 RAID6这样单 OST 故障不会影响整体可用性。4.2 用 IOR 摸清存储真实带宽下面这个 IOR 命令能帮你快速测出并行文件系统的实际吞吐# 使用 16 个进程每个进程写 4GB块大小 1MB mpirun -np 16 ior -a POSIX \ -b 1m \ # 单次传输块大小 -t 4g \ # 每个进程写入总量 -F \ # 每个进程独立文件 -w \ # 写测试 -r \ # 读测试 -o /lustre/ior_test-b是单次 IO 块大小小文件场景调小到 4k大文件场景调到 4m 以上。-F让每个进程写独立文件避免元数据锁竞争。跑完后看 Max Write 和 Max Read如果远低于存储标称带宽检查 OST 是否成为热点或者客户端挂载参数是否合理。Lustre 客户端挂载时max_read_ahead_mb和max_pages_per_rpc对读性能影响很大通常调到 64MB 和 1024 能显著改善。提示IOR 测试会写满存储务必指定测试目录并提前清理别把生产数据盘写爆了。5. 调度与运维Slurm 配置里那些让你半夜被叫醒的坑5.1 节点状态异常与作业排队排查Slurm 集群最常见的故障是节点被标记为 drain 或 down导致作业排队但没人发现。下面这个命令组合能快速定位问题节点# 查看所有节点状态过滤非 idle 节点 sinfo -N -o %N %T %E | grep -v idle # 查看具体节点的详细原因 scontrol show node node[001-010] # 恢复节点先 resume 再 undrain scontrol update NodeNamenode001 StateRESUME scontrol update NodeNamenode001 StateUNDRAIN%E会显示节点不可用的原因常见的有Not respondingslurmd 挂了、Low socket内存或 CPU 故障、Kill task failed作业清理失败。我一般会写个定时脚本每 5 分钟扫一次发现 drain 节点自动发告警避免等到用户投诉才知道。5.2 用 cgroup 限制资源防止单用户打爆集群没有资源限制的 HPC 集群迟早会被某个跑飞的任务拖垮。Slurm 配合 cgroup 能精确控制每个作业的 CPU、内存和 GPU 用量。下面是一个 cgroup 配置片段# /etc/slurm/cgroup.conf CgroupAutomountyes ConstrainCoresyes ConstrainRAMSpaceyes ConstrainSwapSpaceyes AllowedRAMSpace95 AllowedSwapSpace0 MaxRAMPercent95ConstrainCoresyes确保作业只能用分配给它的核防止越界抢占。AllowedRAMSpace95表示作业内存超过分配量的 95% 就触发 OOM kill而不是等到把节点内存吃光。AllowedSwapSpace0禁用 swap因为 HPC 应用一旦用 swap 性能就崩了不如直接杀掉让用户改代码。注意cgroup v2 和 v1 的配置项名称不同Slurm 版本不同支持程度也不一样升级前务必在测试环境验证。6. 避坑与常见问题那些让我半夜爬起来处理的故障6.1 MPI 作业启动即挂报错btl_openib_handle_internal_errors现象作业提交后秒退日志里全是 InfiniBand 相关错误。原因通常是 OFED 驱动版本和 MPI 库不匹配或者 IB 网卡处于 down 状态。解决先用ibstat确认端口 State 是 Active再用ofed_info -s查驱动版本对照 MPI 厂商的兼容性矩阵升级或降级。我一般会在镜像里固定 OFED 和 MPI 版本不让用户自己编译。6.2 存储挂载点卡死导致所有节点负载飙升现象df -h卡住ls /lustre无响应计算节点 load average 冲到几百。原因通常是 MDS 或 OST 故障客户端在无限重试。解决在客户端挂载参数里加hard改为soft并设置timeo或者配failover模式。更关键的是监控 MDS 的 inode 使用率超过 80% 就要扩容否则元数据操作会越来越慢直到卡死。6.3 Slurm 作业排队但节点显示 idle现象squeue显示作业 PD 状态但sinfo显示节点 idle。原因可能是分区配置错误、QOS 限制、或者节点特征不匹配。解决用scontrol show job jobid看Reason字段常见的有QOSMaxCpuPerUserLimit、ReqNodeNotAvail。如果是特征不匹配检查NodeName的Features和作业的--constraint是否一致。6.4 GPU 作业跑着跑着报 ECC 错误现象训练任务中途崩溃日志里有Xid错误或ECC error。原因可能是 GPU 显存故障或散热问题。解决先用nvidia-smi -q看 ECC 错误计数如果 Uncorrectable 不为零直接报修换卡。临时方案是用nvidia-smi -r重置 GPU但治标不治本。我一般会在节点上跑dcgmi diag做定期健康检查提前发现隐患。6.5 用户抱怨文件权限混乱互相覆盖数据现象同一个项目组多人共用目录A 写的文件 B 改不了或者误删了 C 的数据。原因通常是 umask 设置不一致或者没有启用 ACL。解决在共享目录上设 setgid 位强制继承组权限并用setfacl给项目组统一授权。Slurm 提交时加--acctg-freq记录资源使用方便事后审计。7. 进阶技巧用 Slurm 的 topology 插件优化作业布局前面讲的都是单点配置真正拉开 HPC 架构设计水平的是作业在物理拓扑上的布局。Slurm 的topology/tree和topology/block插件能根据交换机层级把作业尽量调度到同一台 leaf 交换机下减少跨 spine 通信。配置方法是在slurm.conf里加TopologyPlugintopology/tree # 然后在 topology.conf 里定义交换机层级 SwitchNames1 Nodesnode[001-032] SwitchNames2 Nodesnode[033-064] SwitchNameroot Switchess1,s2这样 Slurm 会优先把作业分配到同一台 leaf 下的节点MPI 通信延迟能降 30% 以上。验证方法是跑一个 Allreduce 基准对比启用前后osu_allreduce的延迟变化。我一般会在集群交付前做这个对比测试作为验收指标之一。另一个技巧是给不同队列配不同的PriorityTier和PreemptType。比如紧急队列可以抢占普通队列的资源但被抢占的作业会自动 requeue不会丢。配置PreemptTypepreempt/qos和PreemptExemptTime00:05:00给用户 5 分钟保存现场。这些配置没有银弹每个集群的拓扑和负载特征都不一样。我的习惯是任何调优参数上线前先在测试分区跑一周用sacct收集作业运行数据对比调优前后的平均等待时间和运行时间。数据不会骗人别凭感觉调。希望帮到你。本文还有配套的精品资源点击获取