Dask：非常低 CPU 使用率和多线程？这是预期的吗？
Dask: very low CPU usage and multiple threads? is this expected?
我正在使用 dask 作为
基本上我做了一些计算（不向磁盘写入任何内容）调用 Pandas 和 Fuzzywuzzy（如果有帮助的话，显然可能不会释放 GIL）并且我 运行 类似于：
dmaster = dd.from_pandas(master, npartitions=4)
dmaster = dmaster.assign(my_value=dmaster.original.apply(lambda x: helper(x, slave), name='my_value'))
dmaster.compute(get=dask.multiprocessing.get)
但是，代码的一个变体已经 运行ning 了 10 个小时，而且还没有结束。我在 windows 任务管理器中注意到
RAM utilization 相当低，对应于我的数据大小CPU usage 每 2/3 秒左右从 0% 反弹到最多 5%- 我有大约
20 Python processes 大小为 100MB，并且一个 Python 进程可能包含大小为 30GB 的数据（我有一台 128 GB 的机器，带有8芯CPU)
问题是：该行为是否符合预期？我在这里设置一些 dask 选项显然是错误的吗？
当然，我知道具体情况取决于我在做什么，但也许上面的模式已经可以说明一些事情错得离谱吗？
非常感谢！！
Of course, I understand the specifics depends on what exactly I am doing, but maybe the patterns above can already tell that something is horribly wrong?
这很正确。识别性能问题很棘手，尤其是当并行计算发挥作用时。以下是我想到的一些事情。
- 多进程调度程序必须每次都在不同进程之间移动数据。 serialization/deserialization 周期可能非常昂贵。使用 distributed scheduler 会更好地处理这个问题。
- 您的函数
helper 可能会做一些奇怪的事情。
- 通常最好避免使用 apply，即使在 Pandas 中也是如此。
一般来说，解决这些问题的一个好方法是创建一个 minimal, complete, verifiable example 来分享，其他人可以轻松地复制和使用。通常在创建这样的示例时，您无论如何都会找到问题的解决方案。但是，如果这没有发生，至少您可以将责任推给库维护者。在创建这样的示例之前，大多数库维护人员都不会花时间，几乎总是有太多特定于手头问题的细节以保证免费服务。
我正在使用 dask 作为
基本上我做了一些计算（不向磁盘写入任何内容）调用 Pandas 和 Fuzzywuzzy（如果有帮助的话，显然可能不会释放 GIL）并且我 运行 类似于：
dmaster = dd.from_pandas(master, npartitions=4)
dmaster = dmaster.assign(my_value=dmaster.original.apply(lambda x: helper(x, slave), name='my_value'))
dmaster.compute(get=dask.multiprocessing.get)
但是，代码的一个变体已经 运行ning 了 10 个小时，而且还没有结束。我在 windows 任务管理器中注意到
RAM utilization相当低，对应于我的数据大小CPU usage每 2/3 秒左右从 0% 反弹到最多 5%- 我有大约
20 Python processes大小为 100MB，并且一个 Python 进程可能包含大小为 30GB 的数据（我有一台 128 GB 的机器，带有8芯CPU)
问题是：该行为是否符合预期？我在这里设置一些 dask 选项显然是错误的吗？
当然，我知道具体情况取决于我在做什么，但也许上面的模式已经可以说明一些事情错得离谱吗？
非常感谢！！
Of course, I understand the specifics depends on what exactly I am doing, but maybe the patterns above can already tell that something is horribly wrong?
这很正确。识别性能问题很棘手，尤其是当并行计算发挥作用时。以下是我想到的一些事情。
- 多进程调度程序必须每次都在不同进程之间移动数据。 serialization/deserialization 周期可能非常昂贵。使用 distributed scheduler 会更好地处理这个问题。
- 您的函数
helper可能会做一些奇怪的事情。 - 通常最好避免使用 apply，即使在 Pandas 中也是如此。
一般来说，解决这些问题的一个好方法是创建一个 minimal, complete, verifiable example 来分享，其他人可以轻松地复制和使用。通常在创建这样的示例时，您无论如何都会找到问题的解决方案。但是，如果这没有发生，至少您可以将责任推给库维护者。在创建这样的示例之前，大多数库维护人员都不会花时间，几乎总是有太多特定于手头问题的细节以保证免费服务。