Python多处理池比顺序慢？

【问题标题】：Python MultiProcessing Pool Slower Than Sequential?Python多处理池比顺序慢？
【发布时间】：2016-10-14 21:48:28
【问题描述】：

所以我一直在玩 multiprocessing 模块，试图找出加快我使用 pandas DataFrames 所做的许多工作的方法。

我使用的示例是获取一系列 Excel 文件，每个文件代表一年的数据，将它们转换为数据框，然后对其中的一列求和。依次类推：

now = time.time()
dict = {}
table_2010 = pd.read_excel('2010.xlsx')
table_2011 = pd.read_excel('2011.xlsx')
table_2012 = pd.read_excel('2012.xlsx')
table_2013 = pd.read_excel('2013.xlsx')
table_2014 = pd.read_excel('2014.xlsx')
table_2015 = pd.read_excel('2015.xlsx')
dict[2011] = table_2011[[95]].sum()
dict[2010] = table_2010[[95]].sum()
dict[2012] = table_2012[[95]].sum()
dict[2013] = table_2013[[95]].sum()
dict[2014] = table_2014[[95]].sum()
dict[2015] = table_2015[[95]].sum()
print dict
print time.time() - now

这花了我 205 秒，Excel 文件很大，需要一段时间才能加载到数据框中，我认为以 并行 运行它会提高性能.我想出的是这样的：

def func(year):
    table = pd.read_excel(str(year) + '.xlsx')
    dict[year] = table[[95]].sum()

if __name__ == '__main__':
    now = time.time()
    dict = {}
    pool = ThreadPool(8)
    pool.map_async(func, [2010,2011,2012,2013,2014,2015])
    pool.close()
    pool.join()
    print dict
    print time.time() - now

当我运行它时，它最终花费了 250 秒。我的印象是，让单独的内核运行这些进程中的每一个会提高性能，这是不正确的吗？

还是我写的脚本有问题？

【问题讨论】：

  • 假设你所有的 excel 文件都在同一个物理设备（硬盘）上，然后从它们中分离加载数据不会提供任何性能提升，因为线程将竞争 IO 访问（和在某些情况下，它甚至可能比顺序访问慢）。总和的实际计算应该更快
  • 你的瓶颈很可能是你的硬盘。如果您有 8 个线程争夺读取访问权限，那么每次一个授予访问权限时，它都会浪费周期等待下一位读取它的数据。
  • 很有趣，所以在这种情况下，顺序读取它们然后并行执行任何计算会更有意义吗？
  • 可以，除非您可以从不同的物理设备加载。

标签： python performance pandas parallel-processing python-multiprocessing


【解决方案1】：

较慢？
取决于。
取决于，很多。

脚本有问题吗？
是的，一个蛮横的（仍然无需担心或恐慌 - 一个很好解决的问题）。 阅读愉快。

# =========================================================================[sec]
  an-<iterator>-based SERIAL processing of 9 CPU-bound tasks took 1290.538 [sec]
 aThreadPool(6)-based  TPOOL processing of 9 CPU-bound tasks took 1212.065 [sec]
       aPool(6)-based   POOL processing of 9 CPU-bound tasks took  271.765 [sec]
# =========================================================================[sec]

Python multiprocessing 有几个Pool-s

基于没有完整记录的 MCVE-above（缺少所有显式命名空间 import-s 以安全地消除预期用例的设置歧义），让我们从提及 ThreadPool.map_async() 的代码开始> 并处理许多 Excel 文件。

对于预期的快速处理，很难开始一种更糟糕的方法。

Pool 是否比 SEQ 慢？

故意借用原生并行的occam语言语法，这个问题往往会导致PAR的痛苦 | SEQ 设计高性能系统的困境（是的，HPC，当然 - 猜猜，谁愿意故意设计慢速系统，对吧？）。

这个问题涉及很多方面，在能够认真解决最初的困境之前提出更多问题。

我们有哪些资源？

PAR中要执行什么操作类型 | SEQ安排：

  • 纯粹是问题 { CPU-bound | IO 绑定 }?

  • 是需要分享的问题-{ state | data } 处理期间？

  • 是需要沟通的问题-{信号|消息 } 处理期间？

让我们从原型用例开始：

CPU 密集型处理更容易模拟（并且是一种“更环保”的方式来消耗宝贵的物理 HPC 资源），所以让我们开始使用原始函数：

def aFatCALCULUS( id ):                         # an INTENSIVE CPU-bound WORKLOAD
    import numpy as np
    import os
    pass;   aST = "aFatCALCULUS( {1:>3d} ) [PID:: {0:d}] RET'd {2:d}"
    return( aST.format( os.getpid(),
                        id,
                        id + len( str( [ np.math.factorial( 2**f ) for f in range( 20 ) ][-1] ) )
                        )
            )

现在，让我们以不同的安排执行几次。

请原谅我的非 PEP-8 格式（我们不通过此处的演示赞助任何核心重构，因此确实没有人会觉得这种选择在任何意义上都不合适）。

from multiprocessing.pool import ThreadPool                             # ThreadPool-mode
from multiprocessing      import Pool                                   #       Pool-mode
pass;                     import time
print( "{0:}----------------------------------------------------------- # SETUP:".format(                                   time.ctime() ) )
aListOfTaskIdNUMBERs = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, ]

print( "{0:}----------------------------------------------------------- # PROCESSING-ThreadPool mode of EXECUTION:".format( time.ctime() ) )
aTPool = ThreadPool( 6 )                                                # PROCESSING-ThreadPool.capacity == 6

print( "{0:}----------------------------------------------------------- # SERIAL mode of EXECUTION:".format( time.ctime() ) )
start  = time.clock_gettime( time.CLOCK_MONOTONIC_RAW );
pass;                                                  [ aFatCALCULUS( id ) for id in aListOfTaskIdNUMBERs ] # SERIAL <iterator>-driven mode of EXECUTION
pass;                                                                   duration = time.clock_gettime( time.CLOCK_MONOTONIC_RAW ) - start; print( "an-<iterator>-based SERIAL processing of {1:}-tasks took {0:} [sec]".format( duration, len( aListOfTaskIdNUMBERs ) ) )
pass;

print( "{0:}----------------------------------------------------------- # PROCESSING-Pool mode of EXECUTION:".format( time.ctime() ) )
aPool  = Pool( 6 )                                                      # PROCESSING-Pool.capacity == 6
start  = time.clock_gettime( time.CLOCK_MONOTONIC_RAW );
pass;                                                 aPool.map( aFatCALCULUS, aListOfTaskIdNUMBERs )        # PROCESSING-Pool-driven mode of EXECUTION
pass;                                                                   duration = time.clock_gettime( time.CLOCK_MONOTONIC_RAW ) - start; print( "aPool(6)-based processing of {1:}-tasks took {0:} [sec]".format( duration, len( aListOfTaskIdNUMBERs ) ) )
print( "{0:}----------------------------------------------------------- # END.".format( time.ctime() ) )

为什么？ 。 . .只需检查PID#s 

aPool(6).map()
["aFatCALCULUS(   1 ) [PID:: 898] RET'd 2771011",
 "aFatCALCULUS(   2 ) [PID:: 899] RET'd 2771012",
 "aFatCALCULUS(   3 ) [PID:: 900] RET'd 2771013",
 "aFatCALCULUS(   4 ) [PID:: 901] RET'd 2771014",
 "aFatCALCULUS(   5 ) [PID:: 902] RET'd 2771015",
 "aFatCALCULUS(   6 ) [PID:: 903] RET'd 2771016",
 "aFatCALCULUS(   7 ) [PID:: 898] RET'd 2771017",
 "aFatCALCULUS(   8 ) [PID:: 899] RET'd 2771018",
 "aFatCALCULUS(   9 ) [PID:: 903] RET'd 2771019"
 ]

aThreadPool(6)
["aFatCALCULUS(   1 ) [PID:: 16125] RET'd 2771011",
 "aFatCALCULUS(   2 ) [PID:: 16125] RET'd 2771012",
 "aFatCALCULUS(   3 ) [PID:: 16125] RET'd 2771013",
 "aFatCALCULUS(   4 ) [PID:: 16125] RET'd 2771014",
 "aFatCALCULUS(   5 ) [PID:: 16125] RET'd 2771015",
 "aFatCALCULUS(   6 ) [PID:: 16125] RET'd 2771016",
 "aFatCALCULUS(   7 ) [PID:: 16125] RET'd 2771017",
 "aFatCALCULUS(   8 ) [PID:: 16125] RET'd 2771018",
 "aFatCALCULUS(   9 ) [PID:: 16125] RET'd 2771019"
 ]

如何最好地编排 IO-bound 案例？

超级计算机将计算密集型问题转化为 I/O 密集型问题 (S. Cray)

遵从 Seymour CRAY 的智慧，以应有的谦逊，
但
不要让别人让你成为那个，
谁买单他们缺少 HPC 职责的成本
在您的 CPU 预算范围内。

恕我直言，如果这是我的 HPC 任务，
我会

  • 避免支付 pandas XLSX 导入/转换成本

  • 让 Excel-data-owner / processor 保证并执行他们的自动化列-SUM()-{ auto |手册 |脚本 }-update 在每个数据元素更改/更新及时到达，无论是批量还是按事件，在其数据存储端

  • 寻求最快的（分布式处理）架构，具有独立multiprocessing.Pool().map() 进程的能力，而不是读取（== 移动所有数据堆），而是使用智能的直接访问，仅对单元格（= = elements ) 你需要处理。

在这里，
每个人都可以看到和闻到
为什么 PAR 安排的 Pool() 比任何其他 SEQ 都快 处理：

'''     REAL SYSTEM:: multiprocessing.Pool(6).map()
_________________________________________________________________________________________________________________________________________________________
_________________________________________________________________________________________________________________________________________________________

top - 22:24:42 up 84 days, 23:05,  4 users,  load average: 4.80, 2.17, 0.86
Threads: 366 total,   5 running, 361 sleeping,   0 stopped,   0 zombie
%Cpu0  :  75.7/0.0    76[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||                        ]
%Cpu1  :   0.1/0.0     0[                                                                                                    ]
%Cpu2  :   0.0/0.0     0[                                                                                                    ]
%Cpu3  : 100.0/0.0   100[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||]
%Cpu4  :   0.1/0.0     0[                                                                                                    ]
%Cpu5  :   0.0/0.0     0[                                                                                                    ]
%Cpu6  :  76.2/0.0    76[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||                        ]
%Cpu7  : 100.0/0.0   100[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||]
%Cpu8  :   0.0/0.0     0[                                                                                                    ]
%Cpu9  :  75.5/0.0    76[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||                        ]
%Cpu10 :   0.5/0.4     1[                                                                                                    ]
%Cpu11 : 100.0/0.0   100[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||]
%Cpu12 :   0.0/0.0     0[                                                                                                    ]
%Cpu13 :   0.0/0.0     0[                                                                                                    ]
%Cpu14 :   0.0/0.0     0[                                                                                                    ]
%Cpu15 :   0.7/0.5     1[||                                                                                                  ]
%Cpu16 :   0.0/0.0     0[                                                                                                    ]
%Cpu17 :   0.0/0.0     0[                                                                                                    ]
%Cpu18 :   0.0/0.0     0[                                                                                                    ]
%Cpu19 :   0.0/0.0     0[                                                                                                    ]
KiB Mem : 24522940 total, 22070528 free,   778080 used,  1674332 buff/cache
KiB Swap:  8257532 total,  7419136 free,   838396 used. 22905264 avail Mem

 P S %CPU  PPID   PID nTH     TIME+ USER      PR  NI    RES   CODE    SHR    DATA %MEM    VIRT vMj vMn   SWAP      nsIPC COMMAND
 1 S  0.0  1614  1670   1  10:54.15 root      20   0    632    740    416    1396  0.0   52140   0   0   1172 -                   `- haproxy
 2 S  0.0  1614  1671   1  35:40.50 root      20   0    664    740    380    1528  0.0   52272   0   0   1172 -                   `- haproxy
19 S  0.0     1  1658   1   6:20.42 root      20   0  22960    468  14380   14240  0.1  466344   0   0    836 -           `- httpd
12 S  0.0     1 24217   1   4:31.41 root      20   0   3984      8    668    7320  0.0  155304   0   0   3864 -           `- munin-node
 0 R  0.0 12882  4964   1   0:31.53 m         20   0   2596     96   1524    1596  0.0  158096   0   0      0 4026531839                  `- top
 0 S  0.1 15213 22779  22   0:11.16 m         20   0  54052   2268   5816 1965528  0.2 2191768   0   0      0 4026531839                      `- python3
 1 S  0.1 15213 23613  22   0:10.83 m         20   0  54052   2268   5816 1965528  0.2 2191768   0   0      0 4026531839                      `- python3
 7 R 99.9 16125   898   1   2:29.72 m         20   0  52084   2268   1336 1969112  0.2 2195352   0  3k      0 4026531839                      `- python3
11 R 99.9 16125   899   1   2:29.72 m         20   0  52088   2268   1336 1969116  0.2 2195356   0  3k      0 4026531839                      `- python3
 6 S 76.3 16125   900   1   2:15.49 m         20   0  49724   2268   1236 1965520  0.2 2191760   0 777      0 4026531839                      `- python3
 0 S 75.7 16125   901   1   2:15.12 m         20   0  49732   2268   1236 1965524  0.2 2191764   0 775      0 4026531839                      `- python3
 9 S 75.6 16125   902   1   2:15.05 m         20   0  49732   2268   1236 1965524  0.2 2191764   0 775      0 4026531839                      `- python3
 3 R 99.9 16125   903   1   2:29.70 m         20   0  52100   2268   1336 1969120  0.2 2195360   0  3k      0 4026531839                      `- python3
 4 S  0.1 15213   904  22   0:00.36 m         20   0  54052   2268   5816 1965528  0.2 2191768   0   0      0 4026531839                      `- python3
15 S  1.2 19285 21279   2  21:27.31 a         20   0  75720   2268  12940  196868  0.3  642876   0   0      0 -                       `- python3
 8 S  0.0 19285 21281   2   0:14.88 a         20   0  75720   2268  12940  196868  0.3  642876   0   0      0 -                           `- python3
10 S  0.9 22118 22120   2  20:07.34 a         20   0  56604   2268   7176  464808  0.2  722164   0   0      0 -                       `- python3
 4 S  0.0 22118 22122   2   0:19.39 a         20   0  56604   2268   7176  464808  0.2  722164   0   0      0 -                           `- python3
 4 S  0.0     2    29   1  33:46.57 root      20   0      0      0      0       0  0.0       0   0   0      0 -           `- rcu_sched
_________________________________________________________________________________________________________________________________________________________

_________________________________________________________________________________________________________________________________________________________
top - 22:25:31 up 84 days, 23:06,  4 users,  load average: 3.78, 2.30, 0.97
Threads: 365 total,   4 running, 361 sleeping,   0 stopped,   0 zombie
%Cpu0  :   0.2/0.4     1[                                                                                                    ]
%Cpu1  :   0.0/0.0     0[                                                                                                    ]
%Cpu2  :   0.0/0.0     0[                                                                                                    ]
%Cpu3  : 100.0/0.0   100[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||]
%Cpu4  :   0.2/0.0     0[                                                                                                    ]
%Cpu5  :   0.0/0.0     0[                                                                                                    ]
%Cpu6  :   0.0/0.0     0[                                                                                                    ]
%Cpu7  : 100.0/0.0   100[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||]
%Cpu8  :   0.0/0.0     0[                                                                                                    ]
%Cpu9  :   0.0/0.0     0[                                                                                                    ]
%Cpu10 :   0.6/0.4     1[|                                                                                                   ]
%Cpu11 : 100.0/0.0   100[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||]
%Cpu12 :   0.0/0.0     0[                                                                                                    ]
%Cpu13 :   0.0/0.0     0[                                                                                                    ]
%Cpu14 :   0.0/0.0     0[                                                                                                    ]
%Cpu15 :   0.6/0.6     1[||                                                                                                  ]
%Cpu16 :   0.0/0.0     0[                                                                                                    ]
%Cpu17 :   0.0/0.0     0[                                                                                                    ]
%Cpu18 :   0.0/0.0     0[                                                                                                    ]
%Cpu19 :   0.0/0.0     0[                                                                                                    ]
KiB Mem : 24522940 total, 22076660 free,   772436 used,  1673844 buff/cache
KiB Swap:  8257532 total,  7419136 free,   838396 used. 22911364 avail Mem

 P S %CPU  PPID   PID nTH     TIME+ USER      PR  NI    RES   CODE    SHR    DATA %MEM    VIRT vMj vMn   SWAP      nsIPC COMMAND
 2 S  0.2  1614  1671   1  35:40.51 root      20   0    664    740    380    1528  0.0   52272   0   0   1172 -                   `- haproxy
 0 R  0.4 12882  4964   1   0:31.66 m         20   0   2596     96   1524    1596  0.0  158096   0   0      0 4026531839                  `- top
 7 R 99.9 16125   898   1   3:18.45 m         20   0  52608   2268   1336 1969112  0.2 2195352   0   9      0 4026531839                      `- python3
11 R 99.9 16125   899   1   3:18.46 m         20   0  52612   2268   1336 1969116  0.2 2195356   0   9      0 4026531839                      `- python3
 3 R 99.9 16125   903   1   3:18.43 m         20   0  52624   2268   1336 1969120  0.2 2195360   0  10      0 4026531839                      `- python3
15 S  1.2 19285 21279   2  21:27.92 a         20   0  75720   2268  12940  196868  0.3  642876   0   0      0 -                       `- python3
10 S  1.0 22118 22120   2  20:07.81 a         20   0  56604   2268   7176  464808  0.2  722164   0   0      0 -                       `- python3
_________________________________________________________________________________________________________________________________________________________
_________________________________________________________________________________________________________________________________________________________
'''

【讨论】：

  • 如果这里埋藏着答案，那么它就埋藏在离题的胡言乱语和无法解释的数字中，几乎不引人注意。这甚至不是一个真正的 HPC 场景，它是一个标准工作站，因此大多数 HPC 方面都是无关紧要的。总结是“一项在 I/O 上与同一设备竞争的任务（降低 I/O 吞吐量），并使用 CPython 中的线程进行随后的 CPU 绑定工作（在 GIL 效率低下损失更多而一无所获），这是一个糟糕的想法， " 但你把它埋在了相关性可疑的低上下文数据中。
  • 感谢您的反映。提出问题的人处于不同的境地——有需求，有寻求解决方案的意愿，对尝试平行化至少部分故事的期望未得到满足，她/他将理解回到工作解决方案。 GIL 不是该场景的问题，并发执行的可能性是。两者都进行了演示（如果有人尝试，请逐步进行）和测量，以进行比较。
猜你喜欢
  • 2014-11-12
  • 1970-01-01
  • 1970-01-01
  • 2021-02-22
  • 1970-01-01
  • 2013-09-24
  • 2016-11-08
  • 2015-01-12
  • 2021-07-24
相关资源
最近更新 更多
热门标签
Java Python linux javascript Mysql C# Docker 算法 前端 SpringBoot Redis Vue spring 设计模式 .net core .net kubernetes c++ 数据库 数据结构 大数据 js 机器学习 微服务 Android Go 程序员 面试 JVM ASP.net core 云原生 人工智能 后端 PHP git CSS golang k8s Nginx Django mybatis 深度学习 多线程 React 架构 devops 爬虫 云计算 Spring Boot LeetCode