1. Slurm初探从零认识集群作业系统第一次接触HPC集群的研究人员往往会被一堆陌生的术语搞得晕头转向。Slurm作为目前最流行的开源集群管理系统其实就像一位尽职的任务管家负责把我们的计算任务合理分配到集群的各个计算节点上。想象一下你有一个需要跑三天的实验程序总不能一直守在电脑前盯着吧这时候Slurm的价值就体现出来了——它能让你的程序在后台稳定运行还能随时告诉你运行状态。先来理解几个关键概念分区(Partition)相当于不同的任务队列比如有的分区配置了GPU卡适合深度学习有的则是普通CPU适合常规计算。就像医院分门诊科室一样感冒不会挂骨科号。作业(Job)你提交的一个计算任务单位可以是单个程序也可以是一组关联程序。作业步(Job Step)一个作业内可以包含多个步骤比如先预处理数据再训练模型这两个步骤可以放在同一个作业里。QOS服务质量限制相当于你的资源信用卡额度防止单个用户占用全部资源。我第一次使用时犯的典型错误就是没搞清楚分区把需要GPU的程序提交到了CPU分区结果白白排队两小时才发现问题。所以建议新手在提交前先用sinfo命令看看有哪些可用分区sinfo -o %10P %5D %14F %6t %N # 格式化输出分区信息这个命令会显示每个分区的节点数量、空闲状态等信息其中%6t列显示的就是分区状态idle节点完全空闲alloc节点被完全占用mix节点部分占用drain节点故障中2. 作业提交的三种姿势2.1 交互模式srun快速测试当你需要快速验证一个小程序时交互式提交是最便捷的选择。就像在终端直接运行命令一样只不过是在计算节点上执行srun -p gpu_partition -N 1 --gresgpu:1 python test.py这里-p指定GPU分区--gresgpu:1申请1块GPU卡。我经常用这种方式测试数据加载是否正常特别适合以下场景快速检查程序依赖库是否齐全小规模数据试运行调试环境变量问题但要注意两个坑如果网络中断运行中的程序也会终止默认输出会混在终端信息里建议加上-o output.log重定向2.2 批处理模式sbatch实战详解真正的生产任务还是要用批处理模式。先创建一个脚本文件job.sh#!/bin/bash #SBATCH --job-namemnist_train # 作业名称 #SBATCH --partitiongpu # 指定分区 #SBATCH --nodes2 # 节点数 #SBATCH --ntasks-per-node4 # 每节点核心数 #SBATCH --gresgpu:2 # 每节点GPU数 #SBATCH --time1-00:00:00 # 运行1天 #SBATCH --output%x_%j.log # 输出日志 echo Starting at $(date) # 打印开始时间 module load cuda/11.1 # 加载CUDA环境 # 使用srun启动MPI任务 srun python train.py --batch_size128提交时遇到的一个常见错误是忘记给脚本执行权限chmod x job.sh # 这一步很重要 sbatch job.sh批处理模式的几个优势运行不受终端关闭影响可以精确控制资源需求自动记录标准输出和错误支持设置邮件通知--mail-typeFAIL2.3 分配模式salloc灵活运用salloc模式比较特殊它先占住资源再交互使用。我通常在教学演示时这样用# 申请2个节点每个节点8核 salloc -N 2 -n 16 -p debug # 申请成功后会在新shell中运行 srun hostname # 在所有分配节点上执行 # 使用完毕后 exit # 释放资源这种模式适合需要多次交互实验的场景比如调试分布式程序教学演示需要手动控制任务启动时机的场景3. 作业监控与诊断技巧3.1 基础查询命令组合拳squeue是最常用的监控命令但默认输出信息有限。我习惯用这个组合watch -n 5 squeue -u $USER -o %.10i %.20j %.10T %.10M %.10l %.6D %.4C %.10m %R这个命令会每5秒刷新一次显示作业ID、名称、状态、运行时间时间限制、节点数、CPU数内存需求、运行节点当作业卡在PD(排队)状态时可以检查scontrol show job JOBID | grep -E Reason|Account常见排队原因包括资源不足(Resources)优先级不够(Priority)达到QOS限制(QOSMaxCpuPerUser)3.2 scontrol高级用法有一次我发现提交的作业内存设置太小程序总是崩溃。用scontrol直接修改运行中作业的参数scontrol update jobid12345 MinMemoryCPU8000 # 改为8GB内存scontrol还能做很多管理操作# 挂起作业 scontrol suspend 12345 # 恢复作业 scontrol resume 12345 # 修改时间限制 scontrol update jobid12345 TimeLimit2-12:00:003.3 资源使用分析了解作业实际资源消耗对优化很重要sacct -j 12345 --formatJobID,JobName,MaxRSS,Elapsed,State这个命令会显示作业的最大内存消耗(MaxRSS)和实际运行时间。我经常用这个数据来调整下次提交的参数比如发现实际内存只用了一半下次就可以减少申请量缩短排队时间。4. 实战问题排查指南4.1 常见错误代码解析Invalid account or account/partition combination检查sacctmgr show assoc看自己是否有该分区权限Requested node configuration not available用sinfo -N -o %N %c %m %G查看节点配置Job/step already completing通常发生在频繁操作时等待几秒再试4.2 性能优化建议通过分析数百个作业后我总结出这些经验内存申请实际使用量的1.2倍最佳过大会降低调度优先级CPU核心数不是越多越好超过程序并行能力反而会降低效率时间限制设置比预估多20%避免被强制终止作业阵列大批量小任务用--array参数更高效4.3 日志分析技巧Slurm生成的日志包含丰富信息。这个命令可以快速定位错误grep -B 5 -A 5 -i error slurm-12345.out重点关注这些关键词oom-kill内存不足DUE TO TIME LIMIT超时终止Permission denied权限问题ModuleNotFound环境配置错误记得定期清理旧日志文件我见过有人因为日志堆积导致磁盘爆满的情况。可以设置这样的定时任务# 删除30天前的日志 find ~ -name slurm-*.out -mtime 30 -delete
