python多处理池并不总是使用所有工作者

概述问题：当将1000个任务发送到apply_async时,它们在所有48个CPU上并行运行,但有时运行的CPU越来越少,直到只剩下一个CPU运行,并且只有当最后一个CPU完成其任务时,所有CPU才会继续运行每个人都有一个新任务.它不应该等待像这样的任何“任务批处理”..我的(简化)代码：from multiprocessing import Pool pool

问题：
当将1000个任务发送到apply_async时,它们在所有48个cpu上并行运行,但有时运行的cpu越来越少,直到只剩下一个cpu运行,并且只有当最后一个cpu完成其任务时,所有cpu才会继续运行每个人都有一个新任务.它不应该等待像这样的任何“任务批处理”..

我的(简化)代码：

from multiprocessing import Poolpool = Pool(47)tasks = [pool.apply_async(Json2features,(j,)) for j in Jsons]feats = [t.get() for t in tasks]

Jsons = […]是已加载到内存并解析为对象的大约1000个JsON的列表.
Json2features(Json)在Json上执行一些cpu繁重的工作,并返回一个数字数组.
此功能可能需要1秒到15分钟才能运行,因此我使用启发式方法对Jsons进行排序.希望最长的任务首先在列表中,因此首先开始.

Json2features函数还会在任务完成时以及花费的时间内打印.它全部运行在一个拥有48个核心的ubuntu服务器上,就像我上面所说的那样,使用全部47个核心,它开始很棒.然后,当任务完成时,运行的核心越来越少,这听起来完全没问题,不是因为在最后一个核心完成之后(当我看到它打印到stdout时),所有cpu都开始在新任务上再次运行,这意味着这不是真正的清单结束.它可能会再次执行相同的 *** 作,然后再次执行列表的实际结束.

有时它可以在5分钟内只使用一个核心,当任务最终完成时,它会在新任务上再次开始使用所有核心. (所以它不会停留在某些IPC开销上)

没有重复的Jsons,也没有任何依赖关系(它们都是静态的,新鲜的磁盘数据,没有引用等等),也没有Json2features调用之间的任何依赖关系(没有全局状态或任何东西),除了它们使用相同的终端他们的印刷品.

我怀疑问题是工作人员在调用get结果之前不会被释放,所以我尝试了以下代码：

from multiprocessing import Poolpool = Pool(47)tasks = [pool.apply_async(print,(i,)) for i in range(1000)]# feats = [t.get() for t in tasks]

并且它会打印所有1000个数字,即使没有调用get.

我现在已经没想到问题可能是什么了.
这真的是Pool的正常行为吗？

非常感谢！

最佳答案multiprocessing.Pool依赖于单个os.pipe将任务交付给worker.

通常在Unix上,默认管道大小范围为4到64 Kb.如果您提供的JsON大小很大,您可能会在任何给定的时间点堵塞管道.

这意味着,当其中一名工人忙于从管道中读取大型JsON时,所有其他工作人员都会饿死.

通过IPC共享大数据通常是一种不好的做法,因为它会导致性能不佳.这在multiprocessing programming guidelines中甚至得到了强调.

AvoID shared state

As far as possible one should try to avoID shifting large amounts of data between processes.

不要在主进程中读取JsON文件,只需向工作人员发送文件名,然后让他们打开并阅读内容.您肯定会注意到性能的提高,因为您也在并发域中移动JsON加载阶段.

请注意,结果也是如此.单个os.pipe也用于将结果返回到主进程.如果一个或多个工作人员阻塞了结果管道,那么您将获得等待主管道排除它的所有进程.应将大结果写入文件.然后,您可以利用主进程上的多线程快速回读文件中的结果.

总结

以上是内存溢出为你收集整理的python多处理池并不总是使用所有工作者全部内容，希望文章能够帮你解决python多处理池并不总是使用所有工作者所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。