Slurm 故障排除指南

本指南旨在帮助系统管理员或操作员排除 Slurm 故障并恢复服务。 常见问题 文档也可能会有所帮助。

Slurm 没有响应

  1. 执行 "scontrol ping" 以确定主控制器和备份控制器是否响应。
  2. 如果它对你有响应，这可能是某个用户或节点在集群中存在的网络或配置问题。
  3. 如果没有响应，直接登录到机器并重试，以排除网络和配置问题。
  4. 如果仍然没有响应，执行 "ps -el | grep slurmctld" 检查是否有活动的 slurmctld 守护进程。
  5. 如果 slurmctld 没有运行，请重启它（通常以 root 用户身份使用命令 "/etc/init.d/slurm start"）。 你应该检查日志文件（SlurmctldLog 在 slurm.conf 文件中）以了解它失败的原因。
  6. 如果 slurmctld 正在运行但没有响应（这种情况非常少见），则杀死并重启它（通常以 root 用户身份使用命令 "/etc/init.d/slurm stop" 然后 "/etc/init.d/slurm start"）。
  7. 如果它再次挂起，请增加调试消息的详细程度（在 slurm.conf 文件中增加 SlurmctldDebug）并重启。 再次检查日志文件以了解它失败的原因。
  8. 如果它继续失败而没有失败模式的指示，请在不保留状态的情况下重启（通常以 root 用户身份使用命令 "/etc/init.d/slurm stop" 然后 "/etc/init.d/slurm startclean"）。 注意：所有正在运行的作业和其他状态信息将丢失。

作业没有被调度

这取决于 Slurm 使用的调度器。 执行命令 "scontrol show config | grep SchedulerType" 来确定这一点。 对于任何调度器，你可以使用命令 "scontrol show job" 检查作业的优先级。

  • 如果调度器类型是 builtin，则作业将在给定分区的提交顺序中执行。 即使有可用资源可以立即启动作业，它也会推迟，直到没有之前提交的作业在等待。
  • 如果调度器类型是 backfill，则作业通常将在给定分区的提交顺序中执行，唯一的例外是：后提交的作业将在不延迟之前提交作业的预期执行时间的情况下提前启动。 为了使回填调度有效，用户的作业应指定合理的时间限制。 如果作业未指定时间限制，则所有作业将获得相同的时间限制（与分区相关），并且回填调度作业的能力将受到限制。 回填调度器不会更改所需或排除节点的作业规范，因此指定节点的作业将大大降低回填调度的有效性。 有关更多详细信息，请参见回填文档。

作业和节点卡在 COMPLETING 状态

这通常是由于与作业相关的不可终止进程造成的。 Slurm 将继续尝试使用 SIGKILL 终止进程，但某些作业可能因执行 I/O 而卡住且不可终止。 这通常是由于文件系统问题，可以通过几种方式解决。

  1. 修复文件系统和/或重启节点。 -或-
  2. 将节点设置为 DOWN 状态，然后将其恢复到服务状态 ("scontrol update NodeName=<node> State=down Reason=hung_proc" 和 "scontrol update NodeName=<node> State=resume")。 这允许其他作业使用该节点，但将不可终止的进程保留在原地。 如果该进程最终完成 I/O，挂起的 SIGKILL 应立即终止它。 -或-
  3. 使用UnkillableStepProgram 和 UnkillableStepTimeout 配置参数自动响应无法杀死的进程，通过发送电子邮件或重启节点。有关更多信息，请参见slurm.conf文档。

如果看起来你的作业不是因为文件系统问题而卡住，可能需要一些调试来找到原因。如果你能重现该行为，可以将 SlurmdDebug 级别设置为 'debug' 并重启 slurmd 在你将用来重现问题的节点上。然后 slurmd.log 文件应该会有更多信息来帮助排除问题。 查看 slurmctld.log 也可能提供线索。如果节点停止响应，你可能需要调查原因，因为它们可能会阻止作业清理并导致作业保持在 COMPLETING 状态。当寻找连接问题时，相关的日志条目应类似于以下内容： 

error: Nodes node[00,03,25] not responding
Node node00 now responding

节点被设置为 DOWN 状态

  1. 使用命令 "scontrol show node <name>" 检查节点为何处于 DOWN 状态。 这将显示节点被设置为 DOWN 的原因和发生的时间。 如果与 slurm.conf 文件中指定的参数相比，磁盘空间、内存空间等不足，则修复节点或更改 slurm.conf。
  2. 如果原因是 "未响应"，则使用命令 "ping <address>" 检查控制机器与 DOWN 节点之间的通信，确保指定在 slurm.conf 中配置的 NodeAddr 值。 如果 ping 失败，则修复网络或 slurm.conf 中的地址。
  3. 接下来，登录到 Slurm 认为处于 DOWN 状态的节点，并使用命令 "ps -el | grep slurmd" 检查 slurmd 守护进程是否正在运行。 如果 slurmd 没有运行，请重启它（通常以 root 用户身份使用命令 "/etc/init.d/slurm start"）。 你应该检查日志文件（SlurmdLog 在 slurm.conf 文件中）以了解它失败的原因。 你可以通过在感兴趣的节点上执行命令 "scontrol show slurmd" 获取正在运行的 slurmd 守护进程的状态。 检查 "Last slurmctld msg time" 的值以确定 slurmctld 是否能够与 slurmd 通信。
  4. 如果 slurmd 正在运行但没有响应（这种情况非常少见），则杀死并重启它（通常以 root 用户身份使用命令 "/etc/init.d/slurm stop" 然后 "/etc/init.d/slurm start"）。
  5. 如果仍然没有响应，请重试以排除网络和配置问题。
  6. 如果仍然没有响应，请增加调试消息的详细程度（在 slurm.conf 文件中增加 SlurmdDebug）并重启。 再次检查日志文件以了解它失败的原因。
  7. 如果仍然没有响应且没有失败模式的指示，请在不保留状态的情况下重启（通常以 root 用户身份使用命令 "/etc/init.d/slurm stop" 然后 "/etc/init.d/slurm startclean"）。 注意：该节点上所有作业和其他状态信息将丢失。

网络和配置问题

  1. 检查控制器和/或 slurmd 日志文件（SlurmctldLog 和 SlurmdLog 在 slurm.conf 文件中）以了解它失败的原因。
  2. 检查出现问题的节点上的 slurm.conf 和凭证文件是否一致。
  3. 如果这是用户特定的问题，请检查该用户是否在控制计算机和计算节点上配置。 用户不需要能够登录，但其用户 ID 必须存在。
  4. 检查所有节点上是否存在兼容版本的 Slurm（执行 "sinfo -V" 或 "rpm -qa | grep slurm"）。 Slurm 版本号包含三个用句点分隔的数字，表示主要 Slurm 版本和维护版本级别。 前两个部分组合在一起表示主要版本，并与该主要版本的年份和月份匹配。版本中的第三个数字指定特定的维护级别： 年.月.维护版本（例如 17.11.5 是主要 Slurm 版本 17.11，维护版本 5）。 因此版本 17.11.x 最初在 2017 年 11 月发布。 Slurm 守护进程将支持来自两个先前主要版本的 RPC 和状态文件（例如版本 17.11.x 的 SlurmDBD 将支持版本为 17.11.x、17.02.x 或 16.05.x 的 slurmctld 守护进程和命令）。

最后修改于 2020 年 5 月 28 日