问题描述
编辑:在发现所描述的行为并非源自 SLURM 而是源自 R 包 {drake} 后,问题标题和标签进行了调整,该包用作执行 SLURM 阵列作业的代理。
我遇到了以下情况:
这会导致以下情况:
对于任务 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)
[...]
有没有办法在没有更多任务分配给他们之后关闭这些空闲的工人并释放资源?目前他们会等到所有worker都完成后才释放资源。
解决方法
感谢@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)
),