Slurm + drake：空闲作业数组工作者的空闲资源用于动态分支答案

【问题标题】：Slurm + drake: free resources of idle job array workers for dynamic branchingSlurm + drake：空闲作业数组工作者的空闲资源用于动态分支
【发布时间】：2021-04-04 15:45:24
【问题描述】：

编辑：在发现所描述的行为不是源自 SLURM 而是源自用作代理执行 SLURM 数组作业的 R 包 {drake} 后，调整了问题标题和标签。

我遇到以下情况：

n=70 的 Slurm 作业数组，每个作业具有 X CPU 和 Y 内存
要运行 120 个任务
每个任务都需要相同的 CPU + 内存，但完成时间不同

这会导致以下情况：

对于任务 71-120（完成 1-70 之后），我有 50 个活跃的工人和 20 个空闲的工人。空闲的worker不再做任何工作，只是等待活跃的worker完成。

现在，随着时间的推移，越来越多的工人完成工作，有时我有 5 个活跃的工人和 65 个闲置的工人。假设最后 5 个任务需要相当长的时间才能完成。在这段时间里，空闲的worker阻塞了集群上的资源，并不断的将以下内容打印到各自的日志文件中

2021-04-03 19:41:41.866282 | > WORKER_WAIT (0.000s wait)
2021-04-03 19:41:41.868709 | waiting 1.70s
2021-04-03 19:41:43.571948 | > WORKER_WAIT (0.000s wait)

[...]

有没有办法在没有更多任务分配后关闭这些空闲的工作人员并释放资源？目前他们等到所有工作人员都完成后才释放资源。

【问题讨论】：

你不是把两件事混为一谈吗（slurm 数组作业和clustermq 工人）？我会运行以下命令进行测试：（1）sbatch --array=1-2 (sleep script with $SLURM_ARRAY_TASK_ID)（2）clustermq::Q(Sys.sleep, time=c(1,60), n_jobs=2)。在这两种情况下，第二个工作/工人是否保留在您的系统上？
可能！这很好用，即第一个工作人员关闭并释放资源，而不是等到第二个工作人员完成。这是否意味着问题既不是 SLURM 也不是 clustermq，而是因为通过 {drake} 提交，工作人员正在等待？
这听起来像是drake 确定是否还有更多工作要做的方式存在错误。无论如何，看起来不是因为口水。

标签： r slurm drake-r-package

【解决方案1】：

感谢@Michael Schubert 的评论，我发现在使用 R 包 {drake} 及其动态分支功能时会发生这种行为（静态目标可以正常关闭）。

在这里，“目标”可以有动态的“子目标”，可以通过 SLURM 将其计算为单独的数组作业。在计算完所有子目标后，这些子目标将被组合起来。在此聚合步骤发生之前，所有工作人员都保持在“等待”状态，在此状态下他们输出上面显示的WORKER_WAIT 状态。

猜测：由于 {drake} 中动态目标的设计，这可能无法避免，因为要聚合所有子目标，这些子目标首先需要存在。因此，必须将各个子目标保持/保存在临时状态，直到所有子目标都可用。

以下 {drake} R 代码可以与 SLURM 集群结合使用来重现所解释的行为：

  list_time = c(30,60),
  test_dynamic = target(
    Sys.sleep(time = list_time),
    dynamic = map(list_time)
  ),

【讨论】：

正如您所怀疑的，动态分支清理步骤是优先级队列的一部分，它可以防止关闭多余的工作人员。这是targets 准备修复的设计问题，但drake 没有。跟踪github.com/ropensci/targets/issues/398。