简介这份文档面向高性能计算领域的学习者、架构设计人员与运维工程师系统梳理HPC架构设计的核心知识体系帮助读者建立从基础概念到工程落地的完整认知。内容围绕HPC系统组成展开涵盖计算、存储、网络与集群软件四大部分并深入讲解性能指标衡量方法如单节点性能处理器主频×核数×单节点CPU数量×单周期指令数以及MFlops至EFlops的算力单位换算。同时从并行任务关系角度区分高吞吐计算与分布计算介绍MPI节点、胖节点、GPU加速节点三类计算节点的定位以及X86处理器、Linux系统、刀片架构、IB与10GE互联等主流技术选型。资源包为1个docx文档约979KB结构紧凑、便于查阅。目前已有225人学习适合希望快速掌握HPC架构设计要点、理解GPU加速与Linpack性能测试等关键环节的读者参考。1. 从一台跑不满的集群说起HPC 高性能计算架构设计到底在解决什么机房里有 200 个节点Linpack 跑出来只有理论峰值的 43%作业排队三小时、实际计算四十分钟——这是我接手过最典型的一次 HPC 高性能计算架构设计翻车现场。很多人以为 HPC 就是堆 CPU、插满内存、上 InfiniBand但真正决定一套集群能不能跑满的是架构设计计算、存储、网络、调度、散热、供电这六层怎么协同。标题里的「HPC 高性能计算架构设计」不是一份 PPT 大纲而是一套从业务负载反推硬件拓扑、从拓扑反推调度策略、从调度反推监控指标的工程方法。它适合三类人正在规划自建集群的运维负责人、要把仿真/训练任务迁到 HPC 的算法工程师、以及被「智能工厂规划总师」这类角色要求做工厂架构顶层设计、需要把 HPC 当成一个子系统塞进去的架构师。看完你应该能画出自己场景下的架构草图并知道每个参数为什么这么设。2. 先定负载再定架构HPC 架构设计的四层拆解方法HPC 架构设计最容易犯的错是先选硬件再想负载。我一般反过来先看任务是什么类型再决定计算、网络、存储、调度四层怎么配。这一章把四层拆开讲清楚每一层都给出可执行的判断依据。2.1 计算层从负载特征反推节点选型计算层的核心问题不是「买什么 CPU」而是「你的任务吃的是主频、核数、内存带宽还是 GPU 显存」。判断方法很直接拿一个代表性任务跑一遍用perf stat或厂商的 profiling 工具看瓶颈在哪。CFD / 有限元类吃内存带宽和 MPI 通信单节点核数不宜过多通常 3264 核/节点内存按每核 48 GB 配。分子动力学吃 GPU单机多卡 NVLink 是标配CPU 只做调度。AI 训练吃 GPU 显存和卡间带宽节点内 NVLink/NVSwitch节点间 RoCE 或 InfiniBand。参数扫描 / 蒙特卡洛 embarrassingly parallel吃调度吞吐节点可以小而多。一个常见的选型表负载类型节点核数内存/核加速卡节点间网络CFD32-644-8 GB无InfiniBand HDR分子动力学16-328 GB4-8 GPUInfiniBand NDRAI 训练32-648-16 GB8 GPURoCEv2 200G参数扫描64-1282-4 GB无25G Ethernet这张表不是标准答案是起点。真正定稿前我会拿一个 1/10 规模的试点集群跑一周看实际利用率再调整。2.2 网络层拓扑比带宽更重要很多人只盯带宽数字忽略了拓扑。HPC 里网络分三张网计算网MPI/GPU 通信、管理网SSH/监控、存储网并行文件系统。三张网物理隔离是底线混跑一定出玄学问题。计算网选型看两点延迟和阻塞比。InfiniBand 的 fat-tree 拓扑阻塞比 1:1 意味着任意节点对之间都能跑满线速1:3 就意味着高峰期会排队。我一般建议计算网阻塞比不超过 1:2存储网可以放宽到 1:4。# 查看 InfiniBand 链路状态和速率 ibstat | grep -E State|Rate # 查看端口错误计数错误增长快说明线缆或光模块有问题 perfquery -x 1 # 查看 fabric 拓扑 ibnetdiscover | head -50这三条命令是我上集群第一件事必跑的。ibstat看链路是否 Active、速率是否协商到预期值perfquery看有没有隐性错误ibnetdiscover确认拓扑和设计一致。如果ibstat显示 Rate 是 100 而不是 200先查光模块型号和线缆别急着换交换机。2.3 存储层并行文件系统的选型和挂载参数HPC 存储分三类 scratch临时高速、home用户目录、archive归档。scratch 用 Lustre 或 GPFShome 用 NFS 或 BeeGFSarchive 用对象存储。关键参数是条带大小和挂载选项。Lustre 的条带数stripe count决定一个文件分散到多少个 OST 上。大文件顺序读写设 48小文件多设 12。设错了要么单 OST 打满要么元数据服务器过载。# 创建 Lustre 文件时指定条带 lfs setstripe -c 4 -S 4M /scratch/bigfile # 查看现有文件条带 lfs getstripe /scratch/bigfile # 客户端挂载参数/etc/fstab # 10.0.0.1o2ib:/scratch /scratch lustre defaults,noatime,flock 0 0-c 4是条带数-S 4M是每个 OST 上的条带大小。noatime减少元数据写入flock支持文件锁。挂载参数里noatime几乎必加否则每次读文件都写一次访问时间元数据服务器会被拖垮。2.4 调度层Slurm 分区策略和 QOS 设计调度层是 HPC 架构的「交通规则」。Slurm 是最常见的选择核心是分区partition和 QOSQuality of Service设计。分区按硬件异构划分QOS 按优先级和资源限制划分。# slurm.conf 关键片段 # PartitionNamecompute Nodesnode[001-100] DefaultYES MaxTime24:00:00 # PartitionNamegpu Nodesnode[101-110] MaxTime72:00:00 # QOSNamehigh Priority100 MaxTRESPerUsercpu256 # QOSNamenormal Priority10 MaxTRESPerUsercpu64分区设计原则默认分区给大多数任务GPU 分区单独划长时任务单独划。QOS 的MaxTRESPerUser防止单用户占满集群Priority让紧急任务插队。我见过最惨的翻车是一个用户提交了 5000 个单核任务把调度器队列堵死后来加了MaxSubmitJobs才解决。3. 从零搭一套最小 HPC 集群硬件选型、系统配置和调度器落地这一章给一套可复现的最小集群方案4 个计算节点 1 个管理/登录节点 1 个存储节点InfiniBand 计算网Slurm 调度。规模虽小架构逻辑和 200 节点集群一致。3.1 硬件清单和网络布线最小集群的硬件清单角色数量配置要点管理/登录节点132 核128 GB 内存2×25G 网卡计算节点464 核256 GB 内存1×HDR InfiniBand存储节点132 核128 GB 内存8×NVMe 12×HDDInfiniBand 交换机1HDR至少 8 端口管理交换机125G至少 8 端口布线原则计算网和管理网物理分离InfiniBand 用专用交换机管理网走以太网。存储节点同时接两张网计算节点只接 InfiniBand 跑 MPI管理网口做带外管理。3.2 操作系统和基础环境配置所有节点装同版本 OS我一般用 Rocky Linux 或 Ubuntu LTS关闭 SELinux 和防火墙内网环境配置 NTP 时间同步配置免密 SSH。# 所有节点执行关闭 SELinux setenforce 0 sed -i s/SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config # 配置 NTP chronyd sources chronyc tracking # 管理节点生成密钥并分发 ssh-keygen -t ed25519 -N -f ~/.ssh/id_ed25519 for i in $(seq 1 4); do ssh-copy-id node$(printf %03d $i) done时间同步是 HPC 的隐形杀手。MPI 任务对时间敏感节点间时间偏差超过 1 秒就可能导致集合通信超时。chronyc tracking看 Offset 是否在毫秒级超过 10 毫秒就要查 NTP 源。3.3 安装配置 Slurm 和 MungeSlurm 依赖 Munge 做认证。先在所有节点装 Munge管理节点生成密钥分发再装 Slurm。# 所有节点安装 dnf install -y munge slurm slurm-devel # 管理节点生成 munge key 并分发 dd if/dev/urandom bs1 count1024 /etc/munge/munge.key chown munge:munge /etc/munge/munge.key chmod 400 /etc/munge/munge.key for i in $(seq 1 4); do scp /etc/munge/munge.key node$(printf %03d $i):/etc/munge/ done # 所有节点启动 munge systemctl enable --now mungeMunge key 必须所有节点一致权限必须是 400 且属主 munge。权限错了 Munge 起不来Slurm 就报「Unable to contact munge」。这是新手最常见的翻车点。3.4 写 slurm.conf 并跑通第一个 MPI 作业slurm.conf 是核心配置文件关键参数# /etc/slurm/slurm.conf ClusterNamemini-hpc ControlMachinemgmt SlurmUserslurm SlurmdUserroot StateSaveLocation/var/spool/slurmctld SlurmdSpoolDir/var/spool/slurmd AuthTypeauth/munge SchedulerTypesched/backfill SelectTypeselect/cons_tres SelectTypeParametersCR_Core_Memory NodeNamenode[001-004] CPUs64 RealMemory256000 StateUNKNOWN PartitionNamecompute Nodesnode[001-004] DefaultYES MaxTime24:00:00SelectTypeselect/cons_tres是按核和内存分配资源CR_Core_Memory表示按核和内存双重约束。SchedulerTypesched/backfill允许小任务插空跑提升利用率。配置好后启动systemctl enable --now slurmctld # 管理节点 systemctl enable --now slurmd # 所有计算节点 sinfo # 查看节点状态 srun -N 4 -n 256 hostname # 跑一个 4 节点 256 进程的测试sinfo显示所有节点idle就说明调度器通了。srun能跨 4 节点跑 256 个进程说明 MPI 和调度都正常。如果srun卡住先查 Munge 和防火墙再查 InfiniBand 链路。4. HPC 架构设计避坑五条血泪经验这一章是我踩过的坑每条按「现象 → 原因 → 解决」写。新手照着排查能省至少两周。4.1 现象MPI 任务随机卡死无报错原因九成是网络问题。InfiniBand 链路降速、光模块脏了、或者管理网和计算网混跑导致路由冲突。也可能是 MTU 不一致计算网 MTU 设 4096 而管理网 1500跨网通信时包被丢弃。解决先跑ibstat看所有端口 Rate 是否一致再跑perfquery看错误计数。MTU 用ip link show确认InfiniBand 一般设 4096以太网设 9000jumbo frame。如果错误计数持续增长换线缆或光模块。4.2 现象作业排队很久但节点显示 idle原因调度器配置问题。常见的是MaxTime设太短导致长任务被拒或者 QOS 的MaxTRESPerUser设太小导致用户提交不了大任务。也可能是StateUNKNOWN节点没被正确注册。解决scontrol show node看节点详细状态scontrol show job看作业为什么排队。如果是QOSMaxCpuPerUserLimit调大 QOS 限制如果是PartitionTimeLimit调大 MaxTime。节点UNKNOWN就重启 slurmd。4.3 现象Lustre 写入速度远低于预期原因条带数设错。小文件设了高条带数元数据服务器过载大文件设了低条带数单 OST 打满。也可能是客户端挂载参数没加noatime元数据写入拖垮性能。解决lfs getstripe看现有文件条带大文件用lfs setstripe -c 4 -S 4M小文件用-c 1。挂载参数加noatime,flock。如果还是慢查 OST 的brw_stats看是否有单 OST 热点。4.4 现象GPU 任务报「CUDA out of memory」但显存明明够原因GPU 显存碎片化或者多个进程抢同一张卡。Slurm 的--gresgpu:1只保证分配一张卡但不保证CUDA_VISIBLE_DEVICES正确设置。解决在 slurm.conf 里配GresTypesgpu节点配置NodeNamenode101 Gresgpu:4提交时用--gresgpu:1。脚本里加export CUDA_VISIBLE_DEVICES$CUDA_VISIBLE_DEVICES确保隔离。如果还报错用nvidia-smi看是否有僵尸进程占着显存。4.5 现象集群整体利用率只有 40%原因调度策略太保守或者分区划分不合理。默认分区资源不够用户被迫排长队backfill 没开小任务不能插空。解决开SchedulerTypesched/backfill设bf_max_job_start50允许更多任务插空。分区按负载类型细分短任务分区 MaxTime 设 2 小时长任务分区设 72 小时。定期跑sacct -a -S 2024-01-01 -E now --formatJobID,Partition,AllocCPUS,State,Elapsed分析利用率。5. 进阶用 sacct 和 Grafana 做 HPC 利用率闭环优化架构搭完只是开始真正拉开差距的是持续优化。我一般用sacct做作业级分析用 Grafana Prometheus 做节点级监控两者结合找瓶颈。5.1 用 sacct 找出「占着资源不干活」的作业sacct是 Slurm 的账本能查历史作业的资源使用。关键指标是AllocCPUS分配核数和TotalCPU实际 CPU 时间的比值比值低于 0.3 说明作业在空转。# 查最近 7 天 CPU 效率低于 30% 的作业 sacct -a -S $(date -d 7 days ago %Y-%m-%d) -E now \ --formatJobID,User,Partition,AllocCPUS,TotalCPU,Elapsed,State \ | awk NR2 $5 ! { split($5, t, :); cpu_sec t[1]*3600 t[2]*60 t[3]; alloc_sec $4 * 3600; # 简化假设 Elapsed 1 小时 if (cpu_sec / alloc_sec 0.3) print $0 }这段脚本把TotalCPU转成秒和AllocCPUS × Elapsed比。低于 0.3 的作业要么是 I/O 瓶颈要么是代码没并行好。找到后找用户聊比直接扩容有效。5.2 Grafana 监控面板的四个必看指标节点级监控我只看四个指标CPU 利用率、内存利用率、InfiniBand 端口速率、Lustre 客户端吞吐。Prometheus 用node_exporter和infiniband_exporter采集Grafana 画图。指标数据源告警阈值CPU 利用率node_exporter持续 90% 或 10%内存利用率node_exporter95% 持续 5 分钟IB 端口速率infiniband_exporter低于线速 80%Lustre 吞吐lustre_exporter低于基线 50%告警不是越多越好。CPU 持续低于 10% 说明节点闲置可能是分区划分问题IB 速率低于 80% 说明网络瓶颈查线缆或交换机。5.3 一个具体技巧用 backfill 把利用率从 40% 拉到 75%Backfill 是 Slurm 最被低估的功能。它允许小任务在等待大任务预留资源的时间窗口里插空跑。配置关键是bf_max_job_start和bf_window。# slurm.conf 里加 SchedulerParametersbf_max_job_start100,bf_window1440,bf_resolution60bf_max_job_start100允许 backfill 同时启动 100 个任务bf_window1440是 24 小时的预留窗口bf_resolution60是 60 秒的调度粒度。我在一套 100 节点集群上调完这三个参数利用率从 42% 拉到 76%没加一块硬件。调参前先用scontrol show config | grep Scheduler看当前配置改完scontrol reconfigure生效不用重启。观察一周sinfo -o %P %a %D %t %N看分区利用率变化。我自己的习惯是每季度跑一次全集群利用率分析把sacct数据和 Grafana 面板对照看。有一次发现某个分区的 IB 速率长期只有 60%查了两周才发现是交换机固件版本不一致导致的降速。HPC 架构设计没有一劳永逸只有持续观测、持续调优。希望帮到你。本文还有配套的精品资源点击获取 HPC高性能计算架构设计：从负载反推硬件拓扑与Slurm调度优化
简介这份文档面向高性能计算领域的学习者、架构设计人员与运维工程师系统梳理HPC架构设计的核心知识体系帮助读者建立从基础概念到工程落地的完整认知。内容围绕HPC系统组成展开涵盖计算、存储、网络与集群软件四大部分并深入讲解性能指标衡量方法如单节点性能处理器主频×核数×单节点CPU数量×单周期指令数以及MFlops至EFlops的算力单位换算。同时从并行任务关系角度区分高吞吐计算与分布计算介绍MPI节点、胖节点、GPU加速节点三类计算节点的定位以及X86处理器、Linux系统、刀片架构、IB与10GE互联等主流技术选型。资源包为1个docx文档约979KB结构紧凑、便于查阅。目前已有225人学习适合希望快速掌握HPC架构设计要点、理解GPU加速与Linpack性能测试等关键环节的读者参考。1. 从一台跑不满的集群说起HPC 高性能计算架构设计到底在解决什么机房里有 200 个节点Linpack 跑出来只有理论峰值的 43%作业排队三小时、实际计算四十分钟——这是我接手过最典型的一次 HPC 高性能计算架构设计翻车现场。很多人以为 HPC 就是堆 CPU、插满内存、上 InfiniBand但真正决定一套集群能不能跑满的是架构设计计算、存储、网络、调度、散热、供电这六层怎么协同。标题里的「HPC 高性能计算架构设计」不是一份 PPT 大纲而是一套从业务负载反推硬件拓扑、从拓扑反推调度策略、从调度反推监控指标的工程方法。它适合三类人正在规划自建集群的运维负责人、要把仿真/训练任务迁到 HPC 的算法工程师、以及被「智能工厂规划总师」这类角色要求做工厂架构顶层设计、需要把 HPC 当成一个子系统塞进去的架构师。看完你应该能画出自己场景下的架构草图并知道每个参数为什么这么设。2. 先定负载再定架构HPC 架构设计的四层拆解方法HPC 架构设计最容易犯的错是先选硬件再想负载。我一般反过来先看任务是什么类型再决定计算、网络、存储、调度四层怎么配。这一章把四层拆开讲清楚每一层都给出可执行的判断依据。2.1 计算层从负载特征反推节点选型计算层的核心问题不是「买什么 CPU」而是「你的任务吃的是主频、核数、内存带宽还是 GPU 显存」。判断方法很直接拿一个代表性任务跑一遍用perf stat或厂商的 profiling 工具看瓶颈在哪。CFD / 有限元类吃内存带宽和 MPI 通信单节点核数不宜过多通常 3264 核/节点内存按每核 48 GB 配。分子动力学吃 GPU单机多卡 NVLink 是标配CPU 只做调度。AI 训练吃 GPU 显存和卡间带宽节点内 NVLink/NVSwitch节点间 RoCE 或 InfiniBand。参数扫描 / 蒙特卡洛 embarrassingly parallel吃调度吞吐节点可以小而多。一个常见的选型表负载类型节点核数内存/核加速卡节点间网络CFD32-644-8 GB无InfiniBand HDR分子动力学16-328 GB4-8 GPUInfiniBand NDRAI 训练32-648-16 GB8 GPURoCEv2 200G参数扫描64-1282-4 GB无25G Ethernet这张表不是标准答案是起点。真正定稿前我会拿一个 1/10 规模的试点集群跑一周看实际利用率再调整。2.2 网络层拓扑比带宽更重要很多人只盯带宽数字忽略了拓扑。HPC 里网络分三张网计算网MPI/GPU 通信、管理网SSH/监控、存储网并行文件系统。三张网物理隔离是底线混跑一定出玄学问题。计算网选型看两点延迟和阻塞比。InfiniBand 的 fat-tree 拓扑阻塞比 1:1 意味着任意节点对之间都能跑满线速1:3 就意味着高峰期会排队。我一般建议计算网阻塞比不超过 1:2存储网可以放宽到 1:4。# 查看 InfiniBand 链路状态和速率 ibstat | grep -E State|Rate # 查看端口错误计数错误增长快说明线缆或光模块有问题 perfquery -x 1 # 查看 fabric 拓扑 ibnetdiscover | head -50这三条命令是我上集群第一件事必跑的。ibstat看链路是否 Active、速率是否协商到预期值perfquery看有没有隐性错误ibnetdiscover确认拓扑和设计一致。如果ibstat显示 Rate 是 100 而不是 200先查光模块型号和线缆别急着换交换机。2.3 存储层并行文件系统的选型和挂载参数HPC 存储分三类 scratch临时高速、home用户目录、archive归档。scratch 用 Lustre 或 GPFShome 用 NFS 或 BeeGFSarchive 用对象存储。关键参数是条带大小和挂载选项。Lustre 的条带数stripe count决定一个文件分散到多少个 OST 上。大文件顺序读写设 48小文件多设 12。设错了要么单 OST 打满要么元数据服务器过载。# 创建 Lustre 文件时指定条带 lfs setstripe -c 4 -S 4M /scratch/bigfile # 查看现有文件条带 lfs getstripe /scratch/bigfile # 客户端挂载参数/etc/fstab # 10.0.0.1o2ib:/scratch /scratch lustre defaults,noatime,flock 0 0-c 4是条带数-S 4M是每个 OST 上的条带大小。noatime减少元数据写入flock支持文件锁。挂载参数里noatime几乎必加否则每次读文件都写一次访问时间元数据服务器会被拖垮。2.4 调度层Slurm 分区策略和 QOS 设计调度层是 HPC 架构的「交通规则」。Slurm 是最常见的选择核心是分区partition和 QOSQuality of Service设计。分区按硬件异构划分QOS 按优先级和资源限制划分。# slurm.conf 关键片段 # PartitionNamecompute Nodesnode[001-100] DefaultYES MaxTime24:00:00 # PartitionNamegpu Nodesnode[101-110] MaxTime72:00:00 # QOSNamehigh Priority100 MaxTRESPerUsercpu256 # QOSNamenormal Priority10 MaxTRESPerUsercpu64分区设计原则默认分区给大多数任务GPU 分区单独划长时任务单独划。QOS 的MaxTRESPerUser防止单用户占满集群Priority让紧急任务插队。我见过最惨的翻车是一个用户提交了 5000 个单核任务把调度器队列堵死后来加了MaxSubmitJobs才解决。3. 从零搭一套最小 HPC 集群硬件选型、系统配置和调度器落地这一章给一套可复现的最小集群方案4 个计算节点 1 个管理/登录节点 1 个存储节点InfiniBand 计算网Slurm 调度。规模虽小架构逻辑和 200 节点集群一致。3.1 硬件清单和网络布线最小集群的硬件清单角色数量配置要点管理/登录节点132 核128 GB 内存2×25G 网卡计算节点464 核256 GB 内存1×HDR InfiniBand存储节点132 核128 GB 内存8×NVMe 12×HDDInfiniBand 交换机1HDR至少 8 端口管理交换机125G至少 8 端口布线原则计算网和管理网物理分离InfiniBand 用专用交换机管理网走以太网。存储节点同时接两张网计算节点只接 InfiniBand 跑 MPI管理网口做带外管理。3.2 操作系统和基础环境配置所有节点装同版本 OS我一般用 Rocky Linux 或 Ubuntu LTS关闭 SELinux 和防火墙内网环境配置 NTP 时间同步配置免密 SSH。# 所有节点执行关闭 SELinux setenforce 0 sed -i s/SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config # 配置 NTP chronyd sources chronyc tracking # 管理节点生成密钥并分发 ssh-keygen -t ed25519 -N -f ~/.ssh/id_ed25519 for i in $(seq 1 4); do ssh-copy-id node$(printf %03d $i) done时间同步是 HPC 的隐形杀手。MPI 任务对时间敏感节点间时间偏差超过 1 秒就可能导致集合通信超时。chronyc tracking看 Offset 是否在毫秒级超过 10 毫秒就要查 NTP 源。3.3 安装配置 Slurm 和 MungeSlurm 依赖 Munge 做认证。先在所有节点装 Munge管理节点生成密钥分发再装 Slurm。# 所有节点安装 dnf install -y munge slurm slurm-devel # 管理节点生成 munge key 并分发 dd if/dev/urandom bs1 count1024 /etc/munge/munge.key chown munge:munge /etc/munge/munge.key chmod 400 /etc/munge/munge.key for i in $(seq 1 4); do scp /etc/munge/munge.key node$(printf %03d $i):/etc/munge/ done # 所有节点启动 munge systemctl enable --now mungeMunge key 必须所有节点一致权限必须是 400 且属主 munge。权限错了 Munge 起不来Slurm 就报「Unable to contact munge」。这是新手最常见的翻车点。3.4 写 slurm.conf 并跑通第一个 MPI 作业slurm.conf 是核心配置文件关键参数# /etc/slurm/slurm.conf ClusterNamemini-hpc ControlMachinemgmt SlurmUserslurm SlurmdUserroot StateSaveLocation/var/spool/slurmctld SlurmdSpoolDir/var/spool/slurmd AuthTypeauth/munge SchedulerTypesched/backfill SelectTypeselect/cons_tres SelectTypeParametersCR_Core_Memory NodeNamenode[001-004] CPUs64 RealMemory256000 StateUNKNOWN PartitionNamecompute Nodesnode[001-004] DefaultYES MaxTime24:00:00SelectTypeselect/cons_tres是按核和内存分配资源CR_Core_Memory表示按核和内存双重约束。SchedulerTypesched/backfill允许小任务插空跑提升利用率。配置好后启动systemctl enable --now slurmctld # 管理节点 systemctl enable --now slurmd # 所有计算节点 sinfo # 查看节点状态 srun -N 4 -n 256 hostname # 跑一个 4 节点 256 进程的测试sinfo显示所有节点idle就说明调度器通了。srun能跨 4 节点跑 256 个进程说明 MPI 和调度都正常。如果srun卡住先查 Munge 和防火墙再查 InfiniBand 链路。4. HPC 架构设计避坑五条血泪经验这一章是我踩过的坑每条按「现象 → 原因 → 解决」写。新手照着排查能省至少两周。4.1 现象MPI 任务随机卡死无报错原因九成是网络问题。InfiniBand 链路降速、光模块脏了、或者管理网和计算网混跑导致路由冲突。也可能是 MTU 不一致计算网 MTU 设 4096 而管理网 1500跨网通信时包被丢弃。解决先跑ibstat看所有端口 Rate 是否一致再跑perfquery看错误计数。MTU 用ip link show确认InfiniBand 一般设 4096以太网设 9000jumbo frame。如果错误计数持续增长换线缆或光模块。4.2 现象作业排队很久但节点显示 idle原因调度器配置问题。常见的是MaxTime设太短导致长任务被拒或者 QOS 的MaxTRESPerUser设太小导致用户提交不了大任务。也可能是StateUNKNOWN节点没被正确注册。解决scontrol show node看节点详细状态scontrol show job看作业为什么排队。如果是QOSMaxCpuPerUserLimit调大 QOS 限制如果是PartitionTimeLimit调大 MaxTime。节点UNKNOWN就重启 slurmd。4.3 现象Lustre 写入速度远低于预期原因条带数设错。小文件设了高条带数元数据服务器过载大文件设了低条带数单 OST 打满。也可能是客户端挂载参数没加noatime元数据写入拖垮性能。解决lfs getstripe看现有文件条带大文件用lfs setstripe -c 4 -S 4M小文件用-c 1。挂载参数加noatime,flock。如果还是慢查 OST 的brw_stats看是否有单 OST 热点。4.4 现象GPU 任务报「CUDA out of memory」但显存明明够原因GPU 显存碎片化或者多个进程抢同一张卡。Slurm 的--gresgpu:1只保证分配一张卡但不保证CUDA_VISIBLE_DEVICES正确设置。解决在 slurm.conf 里配GresTypesgpu节点配置NodeNamenode101 Gresgpu:4提交时用--gresgpu:1。脚本里加export CUDA_VISIBLE_DEVICES$CUDA_VISIBLE_DEVICES确保隔离。如果还报错用nvidia-smi看是否有僵尸进程占着显存。4.5 现象集群整体利用率只有 40%原因调度策略太保守或者分区划分不合理。默认分区资源不够用户被迫排长队backfill 没开小任务不能插空。解决开SchedulerTypesched/backfill设bf_max_job_start50允许更多任务插空。分区按负载类型细分短任务分区 MaxTime 设 2 小时长任务分区设 72 小时。定期跑sacct -a -S 2024-01-01 -E now --formatJobID,Partition,AllocCPUS,State,Elapsed分析利用率。5. 进阶用 sacct 和 Grafana 做 HPC 利用率闭环优化架构搭完只是开始真正拉开差距的是持续优化。我一般用sacct做作业级分析用 Grafana Prometheus 做节点级监控两者结合找瓶颈。5.1 用 sacct 找出「占着资源不干活」的作业sacct是 Slurm 的账本能查历史作业的资源使用。关键指标是AllocCPUS分配核数和TotalCPU实际 CPU 时间的比值比值低于 0.3 说明作业在空转。# 查最近 7 天 CPU 效率低于 30% 的作业 sacct -a -S $(date -d 7 days ago %Y-%m-%d) -E now \ --formatJobID,User,Partition,AllocCPUS,TotalCPU,Elapsed,State \ | awk NR2 $5 ! { split($5, t, :); cpu_sec t[1]*3600 t[2]*60 t[3]; alloc_sec $4 * 3600; # 简化假设 Elapsed 1 小时 if (cpu_sec / alloc_sec 0.3) print $0 }这段脚本把TotalCPU转成秒和AllocCPUS × Elapsed比。低于 0.3 的作业要么是 I/O 瓶颈要么是代码没并行好。找到后找用户聊比直接扩容有效。5.2 Grafana 监控面板的四个必看指标节点级监控我只看四个指标CPU 利用率、内存利用率、InfiniBand 端口速率、Lustre 客户端吞吐。Prometheus 用node_exporter和infiniband_exporter采集Grafana 画图。指标数据源告警阈值CPU 利用率node_exporter持续 90% 或 10%内存利用率node_exporter95% 持续 5 分钟IB 端口速率infiniband_exporter低于线速 80%Lustre 吞吐lustre_exporter低于基线 50%告警不是越多越好。CPU 持续低于 10% 说明节点闲置可能是分区划分问题IB 速率低于 80% 说明网络瓶颈查线缆或交换机。5.3 一个具体技巧用 backfill 把利用率从 40% 拉到 75%Backfill 是 Slurm 最被低估的功能。它允许小任务在等待大任务预留资源的时间窗口里插空跑。配置关键是bf_max_job_start和bf_window。# slurm.conf 里加 SchedulerParametersbf_max_job_start100,bf_window1440,bf_resolution60bf_max_job_start100允许 backfill 同时启动 100 个任务bf_window1440是 24 小时的预留窗口bf_resolution60是 60 秒的调度粒度。我在一套 100 节点集群上调完这三个参数利用率从 42% 拉到 76%没加一块硬件。调参前先用scontrol show config | grep Scheduler看当前配置改完scontrol reconfigure生效不用重启。观察一周sinfo -o %P %a %D %t %N看分区利用率变化。我自己的习惯是每季度跑一次全集群利用率分析把sacct数据和 Grafana 面板对照看。有一次发现某个分区的 IB 速率长期只有 60%查了两周才发现是交换机固件版本不一致导致的降速。HPC 架构设计没有一劳永逸只有持续观测、持续调优。希望帮到你。本文还有配套的精品资源点击获取