Dask 工作人员卡在 SLURM 队列中，直到 master 到达墙上时间才开始答案

【问题标题】：Dask workers get stuck in SLURM queue and won't start until the master hits the walltimeDask 工作人员卡在 SLURM 队列中，直到 master 到达墙上时间才开始
【发布时间】：2023-06-10 11:52:01
【问题描述】：

最近，我一直在尝试在使用 SLURM 调度程序的 HPC 集群上使用 Dask 进行一些机器学习工作。重要的是，在这个集群上，SLURM 被配置为每个作业的硬墙时间限制为 24 小时。

最初，我使用一个工作人员运行我的代码，但我的工作内存不足。我试图增加工人的数量（因此，请求的节点的数量），但工人卡在 SLURM 队列中（原因被标记为“优先级”）。与此同时，master 会跑，最终撞墙，让工人在他们终于开始时死去。

考虑到问题可能是我请求了太多 SLURM 作业，我尝试将工作人员压缩为单个多节点作业 using a workaround I found on github。然而，这些多节点作业遇到了同样的问题。

然后我尝试与集群的 IT 支持团队取得联系。不幸的是，他们对 Dask 不太熟悉，只能提供一般性的指导。他们的主要建议是要么暂停 master 作业，直到 worker 准备好，要么每 24 小时启动新的 master，直到 worker 可以离开队列。为了帮助实现这一点，他们引用了 SLURM 选项 --begin 和 --dependency。令我懊恼的是，我无法使用任一建议找到解决方案。

因此，我想问一下，在 Dask/SLURM 环境中，是否有一种方法可以强制 master 在 worker 准备好之前不启动，或者启动一个能够“继承”worker 的 master以前由另一个主人创建。

非常感谢您提供的任何帮助。

【问题讨论】：

标签： dask slurm dask-jobqueue

【解决方案1】：

以下内容我可能错了，但根据我使用 SLURM 的经验，Dask 本身将无法与 SLURM 调度程序进行通信。 dask_jobqueue 有助于创建工人，因此一种选择可能是在资源不足的节点上启动调度程序（可能会请求更长的时间）。

在 SLURM 上有一个相对较新的功能 heterogeneous jobs（请参阅 https://slurm.schedmd.com/heterogeneous_jobs.html），据我了解，这将保证您的工作人员、调度程序和客户端同时启动，也许这是您的 IT可以提供帮助，因为这是特定于 SLURM（而不是 dask）。不幸的是，这仅适用于非交互式工作负载。

【讨论】：

【解决方案2】：

我的问题的答案看起来很简单。我们的 SLURM 配置使用backfill scheduler。因为我的 Dask 工作人员正在使用最大可能的 --time（24 小时），这意味着回填调度程序无法有效工作。一旦我将 --time 降低到我认为工人完成脚本运行所必需的数量，他们就离开了“队列地狱”！

【讨论】：