内部 Job Logs：出现故障时的关注点

Source: Dev.to

退出码

每个作业都会以退出码结束，这是最直接的状态信号。

• 0 – 成功
• 非零 – 失败

在 Slurm 中你常会看到类似的输出：

ExitCode=1:0

第一个数字是作业的退出状态；第二个是信号。非零信号通常表示异常终止（例如 kill 或崩溃）。

日志的获取位置

Slurm 会把标准输出和错误流写入类似以下的文件：

slurm-<jobid>.out

你也可以在作业脚本中自定义路径：

#SBATCH --output=job.out
#SBATCH --error=job.err

这些文件是主要的事实依据。

• stdout – 正常的程序输出
• stderr – 警告、错误和崩溃信息

提示： 调试时请始终先阅读 stderr。

高效阅读日志

常见错误是只关注日志的最后一行。根本原因往往出现在更早的位置。

示例

File not found: input.dat
Segmentation fault (core dumped)

段错误是结果；文件缺失才是真正的问题。

与内存相关的失败

内存问题会以多种形式表现，取决于系统如何强制限制：

• Out Of Memory
• Killed
• oom‑kill event

在 Slurm 中你可能会看到：

slurmstepd: error: Detected 1 oom‑kill event(s)

如果出现这种情况，说明作业超出了分配的内存。请增大 --mem 参数或优化内存使用。

代码和环境问题

常见的指向代码或环境问题的提示信息：

• Segmentation faults
• Python tracebacks
• Missing libraries (libXYZ.so: cannot open shared object file)
• Command not found (module: not found)

这些通常意味着：

• 缺少模块
• 环境配置错误
• 软件版本不匹配

操作： 仔细检查你的 module load 命令和环境变量。

节点、I/O 与调度器问题

暗示硬件或文件系统故障的错误：

• Block device required
• I/O error
• Node unreachable

如果同一节点上多个作业都失败，这强烈表明该节点存在问题。

并行作业的陷阱

并行作业的日志往往很嘈杂。留意以下模式：

• 特定 rank 的失败
• 通信错误
• 超时

示例

MPI_ABORT was invoked
NCCL error: connection timed out

这些通常指向网络问题、配置错误或库不匹配。

效率低下与资源限制

有时作业并未崩溃，却触及了限制或出现低效：

• 作业正好在墙钟时间限制时停止
• 启动缓慢或长时间空闲
• 各 rank 之间资源使用不均

Slurm 的统计工具如 sacct 和 seff 可以配合日志，帮助发现这些问题。

一致的调试工作流

1. 检查退出码
2. 从头到尾阅读 stderr
3. 定位第一个真实错误（而非后续症状）
4. 结合资源使用和作业设置进行关联（sacct、seff）
5. 验证环境和依赖（模块、库路径）

遵循这一系统化方法可以帮助你随时间积累模式，使调试更快、更可靠。

结论

日志并非噪声，它们是关于出错原因和过程的结构化线索。投入时间去理解日志，可减少猜测，节省宝贵的 HPC 资源。