踩坑踩坑之Flask+ uWSGI + Tensorflow的Web服务部署

一、简介

作为算法开发人员，在算法模块完成后，拟部署Web服务以对外提供服务，从而将算法模型落地应用。本文针对首次基于Flask + uWSGI + Tensorflow + Nginx部署Web服务时可能会遇到的问题进行简要分析，并提供解决方案，以供大家参考。

二、环境介绍

OS：CentOS 7.0, 内存：16G，系统盘：40G，无挂载盘。

备注：本文作者因环境资源的限制，踩过环境的坑，故此对系统配置也给出。

三、报错异常与解决方案

1） cannot allocate memory for thread-local data: ABORT

在基于TensorFlow的服务启动过程中，在输出CPU频率后报出该错误，第一反应则为内存不够，查看了下内存，虽然只剩6G左右，但是考虑到还有交换分区的空间，应该不是问题，骤然查看硬盘空间，发现几乎快占用完了。

解决方案：若硬盘资源充分，可增加挂载盘；若资源紧张，可删减系统盘空间，以便给交换空间扩容，避免存在内存分配不足的风险。

2） what(): Resource temporarily unavailable

由于在服务配置uWSGI的参数中受buffer-size与limit-as的影响，导致分配的空间不够，导致服务不可用。

解决方案：合理调整一下buffer-size与limit-as的值，即提高上述参数的大小，以满足服务的需求。

备注：部署服务时中间链路较多，殊不知某个地方的参数配置则可能给自己挖了个坑。

3） terminate called after throwing an instance of ‘std: bad_alloc’

同上所示，受buffer-size与limit-as的影响，以致服务不可用。

解决方案：进一步调整一下buffer-size与limit-as的值，即提高上述参数的大小，以满足服务的需求。

4）基于Tensorflow加载图模型后，调用session.run()后，Web服务卡住

由于考虑到服务部署采用全局的模型在后续的服务中调用，故对该全局模型进行加载，在普通Flask服务中测试通过，但是部署在uWSGI + Nginx时一直阻塞。主要是原因是uWSGI采用多线程调用Flask服务，即对于上述全局的模型，若是初始化后，会被每一个线程复制一次，即每个线程会有一个自己独立的全局图模型，但在后续调用服务时，会导致session的阻塞。

解决方案：使上述所有的线程共享同一个全局的图模型，即不在多个线程中进行复制，可基于Flask调用钩子函数before_first_request加载全局的图模型，从而解决上述问题。

备注：受经验影响，加载全局的模型后理所当然认为多线程共享同一个，但是多线程复制后,实则有一些影响，在此不再详细阐述。由于该问题在网络上检索时出现较少，困扰了本文作者大约半天时间，希望能给大家提供参考。

5）服务调用中module未能正确识别，即uWSGI中Python解析器版本不一致

在采用pip install uwsgi后，潜意识中任务已经安装完毕uWSGI，但是在实际运行时，uWSGI识别的Python版本可能存在不一致，导致在开发环境上验证过的服务未能正确部署。

解决方案：首先基于uwsgi –python-version查看当前uWSGI识别的Python解析器，若出现与预期版本（主要为Python2与Python3）不一致时，可进行重装。若是多次重装无效，则直接采用uwsgi的源码进行安装。

四、总结

本文作者对首次采用uWSGI + Flask + Tensorflow部署web服务进行了实践，针对遇到的问题进行了简要分析，并提供了解决方案以供大家参考。至于出错部分的深入原理，例如session.run()卡住等问题，在后续将会逐步展开，敬请关注。

作者：志青云集刘勇 lyssym@sina.com
出处：https://www.cnblogs.com/lyssym/p/11643256.html
　如果，您认为阅读这篇博客让您有些收获，不妨点击一下右下角的【推荐】。
　如果，您希望更容易地发现我的新博客，不妨点击一下左下角的【关注我】。
　如果，您对我的博客所讲述的内容有兴趣，请继续关注我的后续博客，我是【志青云集】。
　欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接。