Question

我正在使用两个内核的计算机并行python中的下一个代码（这只是完整代码的一部分）

import pp
from scheduling import *
from numpy import *

def sched_pp_process(B,T,D,BL,blocks,number_block,number_core):
   ppservers = ()
   job_server = pp.Server(number_core,ppservers)
   jobs = [(i, job_server.submit(local_sched,(B,T,D,blocks[i][0],blocks[i][1],i), (), ("MineLink","time","sys","gurobipy"))) for i in range(number_block)]
   for i, job in jobs:
       if job() == ():
           pass
       else:
           BL.append(job())

def block_est_list(B,T,BL,blocks,number_block,case):
    if case == 1:
        for i in range(number_block):
        blocks.append((random.randint(0,B+1),random.randint(1,T+1)))
    elif case == 2:
        for i in range(number_block):
        blocks.append((random.randint(0,B+1),random.randint(T/2+1,T+1)))

B = 4004
D = 2 
T = 4
number_block = 100

blocks = []
BL = []

block_est_list(B,T,BL,blocks,number_block,1)

sched_pp_process(B,T,D,BL,blocks,number_block,2)

local_sched函数太大而无法在此处指定，但它的作用是解决gurobipy的优化问题。当我指定2个核心（number_core = 2）时，我只能为每个核心运行12个进程核心，所以即使有100个进程，我也只能运行24个进程;之后，python停止工作，即使在Windows任务管理器中说python仍在运行。当发生这种情况时，我必须使用de windows任务管理器停止该过程才能再次使用de命令提示符。如果我指定3个核心，那么我就可以运行100个进程中的36个，依此类推。据我所知，这不应该发生。 有谁知道为什么会这样？

Answer 1

我不认为这是对每个核心进程的限制，但更可能的是由于每个核心的内存（或其他）而导致某种形式的限制。根据代码的设置方式，pp为每个作业或每个核心启动本地ppserver，并为每个作业启动python实例。 pp可以配置，因此它将开始运行交换（您的进程正在交换谁来使用处理器以及谁变得空闲），这很慢。内置的负载均衡器会尝试将作业卸载到不同的核心......但如果你只有2，那么它就会陷入困境。

pp将作业放入队列，将其拉出，并开始在ppserver节点上运行它们。如果你重载ppserver，它就会陷入困境。解决方案是使用更多内核，或配置ppservers，以限制每个内核上运行的作业数。看起来你的限制大约是12。

顺便说一句...... 您可能还想查看ppft（pp的一个分支），它具有更好的跨处理器传输代码对象的功能，在python 2或3上运行，并且pip可安装。还有pathos.pp，它在pipe之上提供了更高级map和pp接口...并尝试最小化产生的开销{{1 }}。如果您正在利用ppservers来运行作业进行优化，那么您可能会对pp感兴趣，mystic可以利用pathos并行运行优化作业。一些代码最近发布，而其他代码则发布了几年陈旧版本。他们都在削减新版本。但是，公共主干：https://github.com/uqfoundation总是很稳定。是的，我是上述代码的作者，所以这也是一个无耻的插件......但听起来它们可能对你有用。

并行Python：限制每个核心的进程数

1 个答案: