cluster-computing - 为什么在 Slurm 中重复调用 squeue 不受欢迎？

Question

为什么不推荐运行squeue在循环中避免 Slurm 过载，但没有提到 bjobs 的此类限制来自 LSF 的工具或 qstat从 SGE ?
man page为 squeue状态:

PERFORMANCE

Executing squeue sends a remote procedure call to slurmctld. If enough calls from squeue or other Slurm client commands that send remote procedure calls to the slurmctld daemon come in at once, it can result in a degradation of performance of the slurmctld daemon, possibly resulting in a denial of service.

Do not run squeue or other Slurm client commands that send remote procedure calls to slurmctld from loops in shell scripts or other programs. Ensure that programs limit calls to squeue to the minimum necessary for the information you are trying to gather.

据我所知，这不赞成使用例如 watch squeue .这样的警告通常可以在特定于站点的文档中找到，例如 here :

Although squeue is a convenient command to query the status of jobs and queues, please be careful not to issue the command excessively, for example, invoking the query for the status of a job every five seconds or so using a script after a job is submitted.

相比之下，我找不到其他引擎上类似工具的此类警告，例如 qstat 或 bjobs .
我看到人们以重复的方式使用所有这些工具，没有区别，例如 here对于 squeue， here对于 bjob​​s。
上面来自 Slurm 文档的引用提到了 RPC，它是一种与其他引擎不同的方式吗？ Slurm 和其他网格引擎之间是否存在架构差异，这使得查询所有作业的状态成本更高？

Answer 1

其实运行的关注squeue过快通常更多地来自集群管理员而不是开发人员。在这种特殊情况下，查看 commit message在文档的特定部分中，我们了解到它实际上是由 SchedMD 的客户请求的，因此很可能是运行生产集群的实体。
该建议的重要性随着集群的规模和工作流动而增加。在平均每天运行 5-6 个作业的 10 节点集群上，您会发现来自十几个用户的许多 squeue 击中了 slurm Controller 。要求。但是在 4000 个节点、10000 个用户、1 万个作业/天上，您可能会以可见的方式干扰 Slurm 性能。
我见过至少一个网站覆盖了 qstat具有基于缓存信息的速率限制版本的命令。
从技术角度来看，RPC 是大多数替代方案使用的。