0

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

我有以下情况：

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

这会导致以下情况：

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

现在随着时间的推移，越来越多的工人完成工作，在某些时候我有 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)

[...]

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

4

1 回答 1

0

感谢@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)
  ),
于 2021-04-04T20:22:35.650 回答