每个进程分别初始化自己的模型

为此我编写了一个python文件来对一个分类模型进行服务化文件首先进行模型初始化之后每次web请求对请求中的数据data利用模型进行预测返回其对应的标签。#label_service.py省略一些引入的包model Model() #数据模型model.load() #模型加载训练好的数据到内存中app Flask(name)class Label(MethodView):def post(self):data request.datalabel model.predict(data)return labelapp.add_url_rule(‘/labelservice/’, view_funcLabel.as_view(‘label’), methods[‘POST’,‘GET’])利用gunicorn进行启动gunicorn的好处在于其支持多进程每个进程可以独立的服务一个外部请求这样就可以利用多核。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处理接口。#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#label_service.py省略一些引入的包app Flask(name)class Label(MethodView):def post(self):data request.datamodel request.environ[‘HTTP_FLASK_MODEL’] #从这里取出模型注意多了一个HTTP前缀。label model.predict(data)return labelapp.add_url_rule(‘/labelservice/’, view_funcLabel.as_view(‘label’), methods[‘POST’,‘GET’])启动服务gunicorn -c gunicorn.conf -w8 -b0.0.0.0:12711 label_service:app使用 -c 指定我们的配置文件。启动服务发现达到了我的目的模型只初始化一次故总内存消耗还是8G。这里面提醒大家当你用top看内存时发现每个子进程内存大小还是8G没有关系我们只要看本机总的剩余内存是减少8G还是减少了8*864G。到此满心欢喜进行上线但是悲剧马上接踵而来。服务运行一段时间每个进程内存陡增1G如下图是我指定gunicorn进程数为1的时候实测发现如果启动8个gunicorn工作进程则内存在某一时刻增长8G直接oom。到此我的内心是崩溃的。不过根据经验我推测在某个时刻某些东西触发了copy-on-write机制于是我让研究院小伙伴仔细审查了一下他们的模型代码确认没有写操作那么就只可能是gunicorn中有写操作。接下来我用蹩脚的英文在gunicorn中提了一个issuehttps://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。实现方式3python2.7升级到python3.7后使用gc.freeze()升级python是一件非常痛苦的事情因为我们的代码都是基于python2.7编写许多语法在python3.7中不兼容特别是字符串操作简直恶心到死只能一一改正除此之外还有pickle的不兼容等等具体修改过程不赘述。最终我们的服务代码如下。#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住得不到响应