python - Python 中的多处理池 - 仅使用单个 CPU

Question

原始问题

我正在尝试在 Python 中使用多处理池。这是我的代码:

def f(x):
    return x
    
def foo():
    p = multiprocessing.Pool()
    mapper = p.imap_unordered
    
    for x in xrange(1, 11):
        res = list(mapper(f,bar(x)))

当 xrange 很小如 xrange(1, 6) 时，此代码使用所有 CPU(我有 8 个 CPU)。但是，当我将范围增加到 xrange(1, 10) 时。我观察到只有 1 个 CPU 以 100% 的速度运行，而其余的只是闲置。可能是什么原因？是否因为当我增加范围时，操作系统会因过热而关闭 CPU？

我该如何解决这个问题？

最小的、完整的、可验证的例子

为了重现我的问题，我创建了这个示例:它是从字符串问题生成的简单 ngram。

#!/usr/bin/python

import time
import itertools
import threading
import multiprocessing
import random
    
    
def f(x):
    return x

def ngrams(input_tmp, n):
    input = input_tmp.split()

    if n > len(input):
        n = len(input)
        
    output = []
    for i in range(len(input)-n+1):
        output.append(input[i:i+n])
    return output 
    
def foo():
    
    p = multiprocessing.Pool()
    mapper = p.imap_unordered
    
    num = 100000000 #100
    rand_list = random.sample(xrange(100000000), num)
    
    rand_str = ' '.join(str(i) for i in rand_list)

    for n in xrange(1, 100):
        res = list(mapper(f, ngrams(rand_str, n)))

        
if __name__ == '__main__':
    start = time.time()
    foo()
    print 'Total time taken: '+str(time.time() - start)

当 num 较小时(例如，num = 10000)，我发现所有 8 个 CPU 都被使用。但是，当 num 非常大时(例如，num = 100000000)。仅使用 2 个 CPU，其余空闲。这是我的问题。

注意:当num 太大时可能会导致系统/VM 崩溃。

Answer 1

首先，ngrams 本身会花费很多时间。虽然这种情况正在发生，但它显然只是一个核心。但即使完成了(这很容易测试，只需将 ngrams 调用移到 mapper 之外，并在前后抛出一个 print它)，您仍然只使用一个核心。我得到 1 个核心 100%，其他核心都在 2% 左右。

如果您在 Python 3.4 中尝试同样的事情，情况会有所不同——我仍然得到 1 个核心的 100%，但其他核心是 15-25%。

那么，这是怎么回事？那么，在 multiprocessing 中，传递参数和返回值总是有一些开销。在您的情况下，这种开销完全淹没了实际工作，即 return x。

开销的工作原理如下:主进程必须对值进行 pickle，然后将它们放入队列，然后等待另一个队列中的值并取消 pickle。每个子进程在第一个队列上等待，unpickles 值，做你的无所事事的工作，pickle 值，并将它们放在另一个队列中。必须同步对队列的访问(通过大多数非 Windows 平台上的 POSIX 信号量，我认为是 Windows 上的 NT 内核互斥量)。

据我所知，您的进程 99% 以上的时间都在等待队列或读取或写入队列。

这不是太出乎意料，因为您有大量数据要处理，而且除了 pickling 和 unpickling 数据之外根本没有计算。

如果您在 CPython 2.7 中查看 SimpleQueue 的源代码，pickling 和 unpickling 发生在持有锁的情况下。因此，几乎任何后台进程所做的所有工作都是在持有锁的情况下发生的，这意味着它们最终都在单个内核上序列化。

但是在CPython 3.4 ，pickling 和 unpickling 发生在锁的外面。显然，这足以使用 15-25% 的内核。 (我相信这个变化发生在 3.2 中，但我懒得去追踪它。)

尽管如此，即使在 3.4 上，您花在等待访问队列上的时间也比做任何事情都多得多，甚至是 multiprocessing 开销。这就是核心最多只能达到 25% 的原因。

当然，你花在开销上的时间比实际工作多几个数量级，这使得这不是一个很好的测试，除非你试图测试你可以从特定的中获得的最大吞吐量>multiprocessing 在您的机器或其他设备上实现。

一些观察:

• 在您的实际代码中，如果您能找到一种方法来批量处理更大的任务(明确地说——仅仅依靠 chunksize=1000 或类似的在这里没有帮助)，那可能会解决大部分问题你的问题。
• 如果您的巨型数组(或其他)从未真正改变过，您可以将它传递到池初始化程序中，而不是传递到每个任务中，这几乎可以消除问题。
• 如果它确实发生了变化，但只是从主流程方面发生了变化，则可能值得共享而不是传递数据。
• 如果您需要从子进程中改变它，请查看是否有一种方法可以对数据进行分区，以便每个任务都可以拥有一个切片而不会发生争用。
• 即使您需要具有显式锁定的完全竞争的共享内存，它可能仍然比传递这么大的东西要好。
• 可能值得向后移植 3.2+ 版本的 multiprocessing 或 PyPI 的第三方 multiprocessing 库之一(或升级到 Python 3.x ), 只是为了将酸洗移出锁。