查看: 157|回复: 0

机器学习web服务化实战:一次吐血的服务化之路

[复制链接]

该用户从未签到

发表于 2019-11-4 16:57:36 | 显示全部楼层 |阅读模式
背景

在公司内部,我负责帮助研究院的小伙伴搭建机器学习web服务,研究院的小伙伴提供一个机器学习本地接口,我负责提供一个对外服务的HTTP接口。
说起人工智能和机器学习,python是最擅长的,其以开辟速度快,第三方库多而广受接待,以至于现在大多数机器学习算法都是用python编写。但是对于服务化来说,python有致命的问题:很难利用机器多核。由于一个python进程中全局只有一个解释器,故多线程是假的,多个线程只能使用一个核,要想充实利用多核就必须使用多进程。此外由于机器学习是CPU密集型,其对多核的需求更为强烈,故要想服务化必须多进程。但是机器学习服务有一个典型特征:服务初始化时,有一个非常大的数据模型要加载到内存,好比我现在要服务化的这个,模型加载到内存必要整整8G的内存,之后在模型上的分类、预测都是只读,没有写操作。所以在多进程基础上,也要考虑内存限制,如果每个进程都初始化本身的模型,那么内存使用量将随着进程数增加而成倍上涨,如何使得多个进程共享一个内存数据模型也是必要解决的问题,特别的如何在一个web服务上实现多进程共享大内存模型是一个棘手的问题。
首先,我们来看看如何举行web服务化呢?我使用python中广泛利用的web框架:Flask + gunicorn。Flask + gunicorn我这里面认为大伙都用过,所以我背面写的就省略些,主要精力放在遇到的问题和解决问题的过程。
实现方式1:每个进程分别初始化本身的模型

为此我编写了一个python文件来对一个分类模型举行服务化,文件首先辈行模型初始化,之后每次web请求,对请求中的数据data利用模型举行预测,返回其对应的标签。
  1. #label_service.py# 省略一些引入的包model = Model() #数据模型model.load()    #模型加载训练好的数据到内存中app = Flask(__name__)class Label(MethodView):      def post(self):        data = request.data        label = model.predict(data)        return labelapp.add_url_rule('/labelservice/', view_func=Label.as_view('label'), methods=['POST','GET'])
复制代码
利用gunicorn举行启动,gunicorn的好处在于其支持多进程,每个进程可以独立的服务一个外部请求,如许就可以利用多核。
  1. gunicorn  -w8 -b0.0.0.0:12711 label_service:app
复制代码
此中:
-w8 意思是启动8个服务进程。
满心欢喜的启动,但是随即我就发现内存直接爆掉。前面说过,我的模型加载到内存中必要8个G,但是由于我启动了8个工作进程,每个进程都初始化一次模型,这就要求我的机器至少有64G内存,这无法忍受。可是,如果我就开一个进程,那么我的多核机器的CPU就浪费了,怎么办?
那么有没有什么方法能够使得8个工作进程共用一份内存数据模型呢? 很遗憾,python中提供多进程之间共享内存都是对于固定的原生数据类型,而我这里面是一个用户自界说的类。此外,模型中依赖的大量的第三方机器学习包,这些包本身并不支持共享内存方式,而且我也不大概去修改它们的源码。怎么办?
gunicorn 进程模型

仔细看了gunicorn的官方文档,此中就有对其工作模型的形貌。

  • gunicorn主进程:负责fork子进程并监控子进程,根据外部信号来决定是否增加或者减少子进程的数目。
  • gunicorn子进程:负责吸收web请求而且完成请求盘算。
我突发奇想,我可以利用gunicorn父子进程在fork时共享父进程内存空间直接使用模型,只要没有对模型的写操作,就不会触发copy-on-write,内存就不会由于子进程数目增加而成本增长。原理图如下:

主进程首先初始化模型,之后fork的子进程直接就拥有父进程的地址空间。接下来的问题就是如何在gunicron的一个恰当的地方举行初始化,而且如何把模型通报给Flask。
实现方式2:利用gunicorn配置文件只在主进程中初始化模型

检察gunicorn官方文档,可以在配置文件配置主进程初始化所需的数据,gunicorn保证配置文件中的数据只在主进程中初始化一次。之后可以利用gunicorn中的HOOK函数pre_request,把model通报给flask处理接口。
  1. #gunicorn.confimport syssys.path.append(".") #必须把本地路径添加到path中,否则gunicorn找不到当前目录所包含的类model = Model()model.load()def pre_request(worker, req):  req.headers.append(('FLASK_MODEL', model)) #把模型通过request通报给flask。pre_request = pre_request
复制代码
  1. #label_service.py# 省略一些引入的包app = Flask(__name__)class Label(MethodView):      def post(self):        data = request.data        model = request.environ['HTTP_FLASK_MODEL'] #从这里取出模型,注意多了一个HTTP前缀。        label = model.predict(data)        return labelapp.add_url_rule('/labelservice/', view_func=Label.as_view('label'), methods=['POST','GET'])
复制代码
启动服务:
  1. gunicorn -c gunicorn.conf -w8 -b0.0.0.0:12711 label_service:app
复制代码
使用 -c 指定我们的配置文件。
启动服务发现达到了我的目标,模型只初始化一次,故总内存斲丧还是8G。
这里面提醒大家,当你用top看内存时,发现每个子进程内存巨细还是8G,没有关系,我们只要看本机总的剩余内存是减少8G还是减少了8*8=64G。

到此,满心欢喜,举行上线,但是悲剧马上接踵而来。服务运行一段时间,每个进程内存陡增1G,如下图是我指定gunicorn进程数为1的时间,实测发现,如果启动8个gunicorn工作进程,则内存在某一时刻增长8G,直接oom。

到此,我的心田是崩溃的。不过根据经验我推测,在某个时刻某些东西触发了copy-on-write机制,于是我让研究院小伙伴仔细审查了一下他们的模型代码,确认没有写操作,那么就只大概是gunicorn中有写操作。
接下来我用蹩脚的英文在gunicorn中提了一个issue:https://github.com/benoitc/gunicorn/issues/1892 ,大神立刻给我指出了一条明路,原来是python的垃圾收集器搞的鬼,详见:https://bugs.python.org/issue31558 , 由于python的垃圾收集会更改每个类的 PyGC_Head,从而它触发了copy-on-write机制,导致我的服务内存成倍增长。
那么有没有什么方法能够禁止垃圾收集器收集这些初始化好的必要大内存的模型呢?有,那就是使用gc.freeze(), 详见 https://docs.python.org/3.7/library/gc.html#gc.freeze 。但是这个接口在python3.7中才提供,为此我不得不把我的服务升级到python3.7。
实现方式3:python2.7升级到python3.7后使用gc.freeze()

升级python是一件非常痛苦的事情,由于我们的代码都是基于python2.7编写,很多语法在python3.7中不兼容,特别是字符串操作,简直恶心到死,只能一一改正,除此之外还有pickle的不兼容等等,具体修改过程不赘述。最终我们的服务代码如下。
  1. #gunicorn.confimport sysimport gcsys.path.append(".") #必须把本地路径添加到path中,否则gunicorn找不到当前目录所包含的类model = Model()model.load()gc.freeze() #调用gc.freeze()必须在fork子进程之前,在gunicorn的这个地方调用正好合适,freeze把截止到当前的所有对象放入长期化区域,不举行回收,从而model占用的内存不会被copy-on-write。def pre_request(worker, req):  req.headers.append(('FLASK_MODEL', model)) #把模型通过request通报给flask。pre_request = pre_request
复制代码
上线之后观察到,我们单个进程内存巨细从8个G降低到6.5个G,这个推测和python3.7本身的优化有关。其次,运行一段时间后,每个子进程内存迟钝上涨500M左右后达到稳定,这要比每个子进程忽然增加1G内存(而且不知道是否只突增一次)要好的多。
使用父子进程共享数据后必要举行预热

当使用gunicorn多进程实现子进程与父进程共享模型数据后,发现了一个问题:就是每个子进程模型的第一次请求盘算耗时特别长,之后的盘算就会非常快。这个现象在每个进程拥有本身的独立的数据模型时是不存在的,不知道是否和python的某些机制有关,有哪位小伙伴相识可以留言给我。对于这种环境,解决办法是在服务启动后预热,人为尽大概多发几个预热请求,如许每个子进程都能够举行第一次盘算,请求处理完毕后再上线,如许就避免线上调用方长时间hang住得不到相应。
结语

到此,我的服务化之路暂时告一段落。这个问题整整困扰我一周,虽然解决的不是很完美,但是对于我这个python新手来说,还是收获颇丰。也盼望我的这篇文章能够对小伙伴们产生一些帮助。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?用户注册

x

相关技术服务需求,请联系管理员和客服QQ:2753533861或QQ:619920289
您需要登录后才可以回帖 登录 | 用户注册

本版积分规则

帖子推荐:
客服咨询

QQ:2753533861

服务时间 9:00-22:00

快速回复 返回顶部 返回列表