Dask cluster.adapt（）在将工人的内存数据移动到其他人之前杀死工人

我正在将Dask与Slurm群集一起使用：

cluster = SLURMCluster(cores=64, processes=64, memory="128G", walltime="24:00:00")
#export DASK_DISTRIBUTED__SCHEDULER__ALLOWED_FAILURES=100
cluster.adapt(minimum_jobs=1, maximum_jobs=2, interval="20 s", target_duration="100 s", wait_count=20)

我的工作负载从约1000个节点减少到1个。每次还原约需2分钟。因此，在开始时可能有平行，但在结束时比较少平行。我只能访问群集中的两个节点。因此，我希望它在开始时使用两个集群节点，在结束时使用一个集群节点

# pseudo code
def reduce(task):
    futures = []
    for i in range(0, len(task), 2):
        futures.append(client.submit(reduceTwo(), task[i]. task[i+1]))
    while len(futures) != 1:
        futures_new = []
        for i in range(0, len(futures), 2):
            futures_new.append(client.submit(reduceTwo(), futures[i].result(), futures[i+1].result()))
        futures = futures_new
    return futures[0].result()

但是，我的问题是，当cluster.adapt（）预期从2个集群节点减少到1个集群节点时，它将首先减少到0并启动一个新节点

问题1：减少到0是否正常？ 如果能够正确保存被杀死节点内存中的输出数据（可能在集群的登录节点scheduler node中），这实际上不会是一个问题。然而，我看了日志，似乎在工人能够正常停止工作/退休之前，他们过早地被杀了。有些工人退休，有些人不退休

问题2：“退休前杀戮”是否可能发生？有没有办法让工人有更长的退休时间？。您可以在上面的第一段代码中看到，我尝试增加尽可能多的计时参数，但它不起作用。我不完全明白

---

我知道我可以优化我的代码。和delfutures一样，我们完成了计算，这样一个工作者的内存阶段任务将为0，并且它的死亡不会导致太多的计算需要重做。或者，lib可以使用相同的缩减。但是，无论如何，这两个Dask问题可以解决吗？

回答我自己的问题，以防其他人看到同样的问题

关键是：不要让所有节点将其临时文件保存到同一共享磁盘中的同一目录中

如果不指定

local\u目录

，所有节点都很容易将worker本地文件保存到

~/dask worker space

目录中，该目录在所有节点之间共享。然后，所有节点都要在这个目录中读/写。然后，当一个节点想要杀死其工作节点时，它可能会意外地杀死其他节点中的工作节点，从而导致（Q1）节点数减少到0。而且，（第2季度）无法移动被杀工人的数据

我希望Dask能够支持所有节点写入同一Dask工作空间。这是一种很自然的行为，我的意思是，当我只想快速使用Dask来进行并行处理时，我的直觉不会告诉我：“设置本地目录，否则程序会崩溃”