问一个 Python 并行的问题

2016-08-03 14:39:04 +08:00
 necomancer
我是用 parallelpython (PP) 进行并行的,任务目标是处理 30000 个文件,最后计算结果的平均值等。由于每个文件独立,所以就考虑用最简单的分割方法,即分割文件列表,机器是 2xE5 , 48 核心,我用 PP 创建 48 线程,平均每个线程处理 625 个文件,我测试过读取+计算一个文件大约需要 0.4s (读取+数据处理大约 0.2 秒,计算 0.2 秒),按照计算,如果实现并行应该是 250s 左右,文件大小约 4M ,所以一次性处理 48 × 4M = 192M 文件我认为 IO 也应该不会太拖慢速度,问题是实际我需要 2800s 左右才能完成计算,在计算过程中,我使用 top 查看过 cpu 使用情况,发现所创建的进程( pp 是 process-based )的 cpu 使用只在 10% 左右,而且同时状态是 R 的只有 4 、 5 个,其他是 D 状态,针对 CPU 使用率问题我 Google 了一番无果,按照常规理解,每个进程不应该是独立的么,所以每个进程的 CPU 使用率应该是 100% 才对,这点在 PP 官网上似乎也没有详细介绍,所以想在此请教一下各位高手,进程状态为什么会是 D ,只有几个 R ,以及为什么是很低的 cpu 使用率。
2651 次点击
所在节点    Python
12 条回复
aisk
2016-08-03 14:41:55 +08:00
每个进程读文件,导致 CPU 吃不满了吧。
northisland
2016-08-03 14:46:34 +08:00
一个文件大约需要 0.4s

全部 250s 左右


要是机械硬盘,肯定做不到。想硬盘的磁头,往返于不同磁道。


把东西度内存里
9hills
2016-08-03 14:47:32 +08:00
看 IO util
wmhx
2016-08-03 14:48:16 +08:00
很明显这样的小文件,cpu 处理并太耗资源,而频繁的 IO 才更拖后腿.
necomancer
2016-08-03 14:49:01 +08:00
@aisk 我昨天测试了一下,在作业比较空闲的时候计算 3000 个文件最快只用了 80 多秒……目前机器有别人跑作业还没测, 30000 个文件我觉得也就应该 800 秒才对啊……
herozhang
2016-08-03 14:52:42 +08:00
把读取文件的行为做成异步的或者流式的?试一下?
hitmanx
2016-08-03 16:54:49 +08:00
要确定是不是 io-bound 造成的有个简单方式可以试一下,你把每个线程现在干的活换成 cpu-bound 的,比如一个死循环计算什么东东,尽量不要保留与磁盘的 io ,然后再观察下 cpu 使用率?
cszhiyue
2016-08-03 17:45:14 +08:00
估计 io 是瓶颈
aisk
2016-08-03 17:51:21 +08:00
如果文件大小比机器内存小的话,可以试试把文件都丢到 /dev/shm 里跑跑看。
petelin
2016-08-03 19:47:07 +08:00
@herozhang 如果 io 是瓶颈的话你这样做是不是无效的? cpu 跑的很快,开的线程也 hold 住。基本没差的吧。
abxialiang
2016-08-04 06:28:18 +08:00
直接启动 48 个进程而不用 pp 测试一下就知道了
necomancer
2016-08-19 13:27:20 +08:00
@aisk
@northisland
@9hills
@wmhx
@herozhang
@hitmanx
@cszhiyue
@aisk
@petelin
@abxialiang

非常感谢各位的帮助!我重新测试了一次,发现果然是 IO 达到瓶颈的问题,同时尝试过异步 IO ,效果并没有什么提升,只能这么等着了~

特别 @aisk ,我那个数据有点问题,没注意测试的是一个更小文件的体系,那个体系 IO 跟得上,所以速度很快,与时间增长关系几乎是线性的。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/296823

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX