【发布时间】:2020-06-22 11:24:32
【问题描述】:
为什么不建议在循环中运行 squeue 以避免 Slurm 过载,但 LSF 的 bjobs 工具或 SGE 的 qstat 没有提到此类限制?
squeue 的 man page 声明:
性能
执行 squeue 会向 slurmctld 发送远程过程调用。如果来自 squeue 或其他向 slurmctld 守护进程发送远程过程调用的 Slurm 客户端命令的调用足够多,则可能会导致 slurmctld 守护进程的性能下降,从而可能导致拒绝服务。
不要运行 squeue 或其他 Slurm 客户端命令,这些命令会从 shell 脚本或其他程序中的循环向 slurmctld 发送远程过程调用。确保程序将对 squeue 的调用限制在您尝试收集的信息所需的最低限度。
据我了解,不赞成使用例如watch squeue。这种警告通常出现在特定于站点的文档中,例如here:
虽然 squeue 是查询作业和队列状态的便捷命令,但请注意不要发出过多命令,例如每隔五秒左右使用脚本调用一次查询作业的状态作业已提交。
相比之下,我在其他引擎上找不到类似工具的此类警告,例如qstat 或 bjobs。
我看到人们以重复的方式毫无区别地使用所有这些工具,例如here 用于 squeue,here 用于 bjobs。
上面来自 Slurm 文档的引用提到了 RPC,它是一种不同于其他引擎的方式吗? Slurm 和其他网格引擎之间是否存在架构差异,导致查询所有作业的状态成本更高?
【问题讨论】:
-
每个服务都有其可扩展性限制。 LSF 有一个专门的查询守护进程,这很有帮助。但即便如此,也有限制。例如,如果集群中有数百万个作业,并且许多作业通过调用
bjobs -uall -a | grep blah之类的方法检查它们的依赖关系,那么就会出现服务降级。 -
尽管文档这样说,
squeue本身有一个-i或--iterate选项,它将每 N 秒重新运行一次,直到每秒。自上次查询以来,它似乎可以请求更新,这可能会有所帮助,但据我所知,它仍然每次都发送一个新的 RPC 请求。我使用它时没有警告。
标签: cluster-computing slurm sungridengine lsf