意外的调度程序行为

Question

在一个简单的工作流程中，据我所知，令人尴尬的是并行（请纠正我），我通过dask.distributed（可能是多处理）调度程序观察到一个奇怪的执行顺序。

为了说明这个过程，我用5个而不是60000个分区设置了一个类似的问题，产生了以下的dask图：

黄色方框是＆＃39; from_delayed＆＃39;在实际案例中。

基础工作流程如下：

1. 读入数据
2. 将生成的dask数据帧与pandas数据帧合并。据我在dask文档中可以看出，这应该是一个快速而常见的案例＆＃34;。
3. 根据结果选择数据
4. 在每个分区上应用功能

令我惊讶的是，所有数据都是在第一步中读入的，耗费了大约450GB的500GB内存。在此之后，lambda函数并行应用，但它没有使用所有工作者，显然，一次只有2-3个是活动的。也许调度程序因为内存几乎已满而犹豫要使用更多内核？当我在较小的问题（约400个分区）上运行代码时，数据仍然完全加载到内存中，但之后执行使用所有可用的内核。我已经尝试在非常大的情况下使用repartition，但它似乎没有产生影响。

我使用分布式调度程序对此进行了调查，但多线程调度程序似乎相同。

也许＆＃39; merge＆＃39; -step会导致瓶颈？给定图表中是否还有其他明显的瓶颈？