作业排障¶

先收集证据¶

遇到问题时先保存以下输出：

scontrol show job JOB_ID
sacct -X -j JOB_ID --format=JobID,JobName,Partition,State,Elapsed,ExitCode,AllocTRES
squeue -j JOB_ID -o "%.18i %.12P %.10T %.20R"

同时保留提交脚本、标准输出、标准错误、镜像标识和问题发生时间。不要只发送“作业跑不了”的截图。

常见问题¶

作业一直 PENDING¶

查看 squeue 最后一列或 scontrol show job 的 Reason：

Reason/现象	处理方向
`Resources`	当前没有满足全部 CPU、内存、GPU、临时盘条件的资源；等待或合理缩小请求
`Priority`	有更高优先级作业；无需反复重新提交
`ReqNodeNotAvail`	节点维护、DRAIN 或请求范围不匹配；用 `sinfo` 检查
`InvalidAccount` / account 错误	使用未授权项目或 `public`；检查 `--account` 与关联
请求了不存在的 GRES	对照 GPU 资源修正分区和 `--gres`

取消再提交不会自动提高优先级，还可能丢失原排队位置。

提交时提示 public 不能计算¶

显式添加已授权项目：

sacctmgr -nP show assoc user="$USER" format=Account
sbatch --account=project-example job.sh

如果没有 project-* 关联，请联系项目管理员。不要尝试修改 SlurmDB 关联。

作业显示 COMPLETING¶

短暂 COMPLETING 通常是 Slurm Epilog 在收尾本地临时盘。等待片刻后检查：

scontrol show job JOB_ID
sacct -X -j JOB_ID --format=JobID,State,ExitCode,Elapsed

只有持续异常且状态不再推进时才报告管理员；不要立即重复提交大型作业。

OUT_OF_MEMORY 或进程被 kill¶

--mem 是 Slurm 内存申请，不是 GPU 显存。提高内存前先检查应用日志、批大小和数据加载进程数量：

sacct -X -j JOB_ID --format=JobID,State,ReqMem,MaxRSS,ExitCode

GPU 显存不足通常由 CUDA 报错，需要降低批大小、启用检查点或申请更大 MIG/完整 GPU。

临时盘写满¶

检查程序是否写入 $LOCAL_SCRATCH，以及 --tmp 是否足够。下一次提交时调整，例如：

sbatch --tmp=500G job.sh

单节点最大 8 TiB，但还必须满足现场剩余容量。不要把重要结果只留在临时盘。

容器拉取或启动失败¶

使用明确、可访问的 HTTPS 镜像来源；
确认镜像名称中的 Pyxis 格式，例如 docker.io#组织/镜像:版本；
先用小镜像和 true 排除应用问题；
检查项目目录权限和自定义挂载路径；
报告镜像完整标识，不要发送仓库密码或令牌。

登录后没有项目组权限¶

id
getent group project-example

组成员刚更新时，退出所有旧 SSH 会话后重新登录。仍不一致时把两条命令的输出交给管理员；不要对共享目录递归改权限。

提交支持请求¶

至少提供：

用户名、作业编号、发生时间和使用的分区；
完整提交脚本（先移除密码和令牌）；
scontrol show job 与 sacct 输出；
标准输出/错误的相关段落；
容器镜像完整版本；
问题是否可重复，以及最后一次成功的作业编号。