意外的调度程序行为

时间:2016-10-18 21:39:09

标签: distributed dask

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

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

enter image description here

黄色方框是' from_delayed'在实际案例中。

基础工作流程如下:

  1. 读入数据
  2. 将生成的dask数据帧与pandas数据帧合并。据我在dask文档中可以看出,这应该是一个快速而常见的案例"。
  3. 根据结果选择数据
  4. 在每个分区上应用功能
  5. 令我惊讶的是,所有数据都是在第一步中读入的,耗费了大约450GB的500GB内存。在此之后,lambda函数并行应用,但它没有使用所有工作者,显然,一次只有2-3个是活动的。也许调度程序因为内存几乎已满而犹豫要使用更多内核?当我在较小的问题(约400个分区)上运行代码时,数据仍然完全加载到内存中,但之后执行使用所有可用的内核。我已经尝试在非常大的情况下使用repartition,但它似乎没有产生影响。

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

    也许' merge' -step会导致瓶颈?给定图表中是否还有其他明显的瓶颈?

0 个答案:

没有答案