joblib的Parallel并发计算使用总结及优化

Joblib定义:

joblib是python中提供一系列轻量级管道操作的 工具; 特别在如下3种工具:

• 函数的透明磁盘缓存和延迟重新计算(记忆模式);
• 容易且简单的平行计算;
• 比 pickle更快的 序列化和反序列化 的功能;

 

joblib经过优化,在大数据量时可以更快且强大,并对numpy数组进行特别优化;

 

此文主要 使用 其中的Parallel功能进行并行计算;

 

安装方式:

pip install joblib

 

示例代码如下(可以 从flask抽取出 在脚本中运行Parallel):

# -*- coding: utf-8 -*-
"""
(C) rgc
All rights reserved
create time '2021/01/15 19:45'

Usage:
joblib:在服务启动后 第一次运行时 比后续运行 多耗时0.5s;是因为第一次需要 分配进程的原因
"""
import time

from flask import Flask
from joblib import Parallel, delayed

application = Flask(__name__)


def myfunc(x):
    # [x for x in range(100000000)]
    time.sleep(1)
    return f'finish:{x}'


@application.route('/', methods=['GET'])
def getresult():
    print('开始')
    start = time.time()
    # 创建parallel_obj对象
    parallel_obj = Parallel(n_jobs=-1, verbose=100, backend='loky', timeout=10)
    # 开始调用被并行计算的函数,并给出结果; 实现方式为 调用内置的 __call__方法
    out = parallel_obj(delayed(myfunc)(i) for i in range(2))
    print(f'耗时:{time.time() - start}')
    return str(out)


if __name__ == "__main__":
    application.debug = True
    application.run()

运行结果如下:

 

Parallel类的参数含义及调优如下:

• n_jobs:进程数
  • -1:表示所有cpu核数都会使用,示例配置8核,假设每核可以运行2个进程,则共16个进程并发;
  • 1:表示不并发,用在debug时; 注意 在用pycharm debug时,此值必须为1,否则报错,且要手动杀掉进程; macos系统flask项目中杀进程命令如下:   lsof -i:端口 | grep Python |cut -b 9-13 | xargs kill -9
  • 其他正整数 表示 并发个数;
• backend:选择的后台并发类型(建议使用loky)
  • loky: 默认值,第一次程序运行时会创建 n_jobs个loky进程(每次并发时都是这些loky进程进行消费),要多耗费一些时间(1-2s左右),后续不会耗费; 每个loky进程的生命周期在 最后一个请求进来后没有消费的300s后自动被杀死;
  • multiprocessing:多进程,基于进程池(multiprocessing.Pool);在多并发时 如3个请求进来 会产生 3*n_jobs个进程;所有每个请求进来时 都会耗费时间在进程创建和销毁上,这个时间基本为0.2-0.3 s左右; 虽然基于进程池,但是 每个进程的生命周期还是在请求开始到请求;结束之间;
  • threading: 多线程; 不用多说; 因为GIL锁的原因,只能在 IO密集的任务中适用;
• timeout:设置并发时处理每个任务的超时时间 在 n_jobs !=1时 生效
• verbose:输出运行时的信息日志
  • 详细级别：如果不为零，则显示进度消息。高于50时，输出将发送到stdout。消息的频率随着详细程度而增加。如果大于10，则报告所有迭代。经过测试并发30个发现 在100时 耗费1.886s; 在 1时 耗费1.833s;在0时耗费1.804s; 所以在非必要情况下建议 使用 verbose=0

 

最优参数 代码示例如下:

parallel_obj = Parallel(n_jobs=-1, verbose=0, backend='loky', timeout=10)

 

使用时的问题:

问题1:  接口在处理时 会出现 耗时不稳定的情况(10%概率)

原因:  在使用 backend='loky'时,其自动生成loky的worker进程,消费任务;但其机制 在最后一次消费后 如果300s内没有消费为了节省系统资源,会自动杀掉worker进程;然后再 下个请求进来时重建loky进程; 但是这样造成了一个问题, 就是每个loky进程不可能都同时消费任务,造成 不同worker被杀掉的时间不同,在下个请求中 又耗时重建loky进程, 这就造成了 有时 接口耗时 不稳定的情况(10%概率);

解决方案:  为了减少这种概率, 于是修改了Joblib的源码(joblib/_parallel_backends.py文件的 487行),将loky进程的 过期时间改为了 系统运行的近似最大限度(2100000s,210万秒,约24天);   或者可以 删除其过期自动杀掉loky进程的功能,但需要对源码深入分析;

 

问题2: 在使用loky进行多进程并发时,无法 实现  先执行完的任务先返回给 用户端 的功能,让我的接口效应时间大打折扣;

解决方法: 分析源码后,对源码( joblib/parallel.py的918行)进行修改,达到此需求;

 

总结:

• 解决上面2个问题 修改后的 Joblib 源码地址如下: https://github.com/Rgcsh/joblib/tree/develop
• 此Parallel在计算密集型 任务中适用,充分利用 CPU每个核的计算资源;且使用loky进程(相当于 生产者-消费者模式)的生命周期较长;比 自己手写的 多进程 更能节省时间和节省资源开销;
• 此Parallel适合在 单服务器上的 并行计算; 如果是 多服务器的 分布式计算 可以考虑 Parallel Python,但是其在任务分发,网络开销等耗时要比Joblib多 近1s左右;
• 在服务启动后 第一次运行时 比后续运行 多耗时0.5-1s;是因为第一次需要 生成多个Joky进程; 所以第一次运行的耗时不能算在 平均耗时中的;