python多处理模块: strange behaviour and processor load when using Pool

Question

我正在使用 Python 的多处理库来加速一些代码(与 scipy 拟合的最小二乘法)。

它在 3 台不同的机器上运行良好，但在第 4 台机器上显示出奇怪的行为。

代码:

import numpy as np
from scipy.optimize import least_squares
import time
import parmap
from multiprocessing import Pool

p0 = [1., 1., 0.5]

def f(p, xx):
    return p[0]*np.exp(-xx ** 2 / p[1] ** 2) + p[2]

def errorfunc(p, xx, yy):
    return f(p, xx) - yy

def do_fit(yy, xx):
    return least_squares(errorfunc, p0[:], args=(xx, yy))

if __name__ == '__main__':
    # create data
    x = np.linspace(-10, 10, 1000)
    y = []
    np.random.seed(42)
    for i in range(1000):
        y.append(f([np.random.rand(1) * 10, np.random.rand(1), 0.], x) + np.random.rand(len(x)))

    # fit without multiprocessing
    t1 = time.time()
    for y_data in y:
        p1 = least_squares(errorfunc, p0[:], args=(x, y_data))
    t2 = time.time()
    print t2 - t1

    # fit with multiprocessing lib
    times = []
    for p in range(1,13):
        my_pool = Pool(p)
        t3 = time.time()
        results = parmap.map(do_fit, y, x, pool=my_pool)
        t4 = time.time()
        times.append(t4-t3)
        my_pool.close()
    print times

对于它运行的 3 台机器，它大致以预期的方式加速。例如。在我的 i7 笔记本电脑上，它给出了:

[4.92650294303894, 2.5883090496063232, 1.7945551872253418, 1.629533052444458, 
1.4896039962768555, 1.3550388813018799, 1.1796400547027588, 1.1852478981018066, 
1.1404039859771729, 1.2239141464233398, 1.1676840782165527, 1.1416618824005127]

我正在运行 Ubuntu 14.10、Python 2.7.6、numpy 1.11.0 和 scipy 0.17.0。我在另一台 Ubuntu 机器、戴尔 PowerEdge R210 和 MacBook Pro Retina(此处使用 Python 2.7.11，以及相同的 numpy 和 scipy 版本)上测试了它，结果相似。

导致问题的计算机是运行 Ubuntu 15.10、Python 2.7.11 以及与上述相同的 numpy 和 scipy 版本的 PowerEdge R710(两个六核)。但是，我没有观察到任何加速。无论我使用什么池大小，时间都在 6 秒左右。事实上，池大小为 2 时效果稍好，进程越多效果越差。

htop 显示以某种方式生成的进程比我预期的要多。

例如在我的笔记本电脑上，htop 显示每个进程一个条目(与池大小匹配)，最终每个进程显示 100% 的 CPU 负载。

在 PowerEdge R710 上，我看到池大小为 1 的大约 8 个 python 进程和池大小为 2 的大约 20 个进程等等。每个进程都显示 100% 的 CPU 负载。

我检查了 R710 的 BIOS 设置，没有发现任何异常。我应该寻找什么？

编辑:为了回应评论，我使用了另一个简单的脚本。令人惊讶的是，这个似乎对所有机器都“有效”:

from multiprocessing import Pool
import time
import math
import numpy as np

def f_np(x):
    return x**np.sin(x)+np.fabs(np.cos(x))**np.arctan(x)

def f(x):
    return x**math.sin(x)+math.fabs(math.cos(x))**math.atan(x)

if __name__ == '__main__':
    print "#pool", ", numpy", ", pure python"
    for p in range(1,9):
        pool = Pool(processes=p)
        np.random.seed(42)
        a = np.random.rand(1000,1000)
        t1 = time.time()
        for i in range(5):
            pool.map(f_np, a)
        t2 = time.time()
        for i in range(5):
            pool.map(f, range(1000000))
        print p, t2-t1, time.time()-t2
        pool.close()

给出:

#pool , numpy , pure python
1 1.34186911583 5.87641906738
2 0.697530984879 3.16030216217
3 0.470160961151 2.20742988586
4 0.35701417923 1.73128080368
5 0.308979988098 1.47339701653
6 0.286448001862 1.37223601341
7 0.274246931076 1.27663207054
8 0.245123147964 1.24748778343

在引起问题的机器上。没有产生比我预期更多的线程(或进程？)。

看起来 numpy 不是问题，但是当我使用 scipy.optimize.least_squares 时，问题就出现了。

在进程上使用 htop 显示了很多 sched_yield() 调用，如果我不使用 scipy.optimize，我看不到这些调用。 least_squares，即使使用 least_squares，我在笔记本电脑上也看不到。

Answer 1

根据 here , OpenBLAS 与 joblib 一起使用时会出现问题。

使用 MKL 时会出现类似的问题(请参阅 here)。这里给出的解决方案也对我有用:添加

import os
os.environ['MKL_NUM_THREADS'] = '1'

在我的 python 脚本的开头解决了这个问题。