modelbox线程爆满宕机bug

发布时间:2023年12月18日

该bug的解决需要特别感谢张同学。有了大佬的帮助,这个bug才得以解决。

问题现象

modelbox可以进行模型推理,但压测一段时间后,modelbox会宕机,并发生段错误。

“libgomp: Thread creation failed: Resource temporarily unavailable”

执行ps -eLf | wc -l发现线程数爆满,达到了3万个,说明在请求期间线程不断被创建,但没有被回收。下图是用并发数为1的请求连续压测modelbox,令modelbox持续执行推理10秒后打印的线程数,已经达到了14230个线程。

说明连续的请求会令modelbox创造很多新线程,但它们被服务后并没有被回收。

探究

笔者用的是modelbox官方在公司内网提供的基础镜像。为了试出错误原因,做过如下尝试:

尝试更换了基础镜像。在develop和runtime镜像之间切换,并不能解决问题。而且笔者使用的镜像版本发布于23年11月,不至于太旧。

更换过pytorch版本,官方推荐的pytorch版本有1.8,1.11和2.1,笔者用的是pytorch 1.11,与基础镜像中的python3.7相匹配,但pytorch2.1需要python3.8,与基础镜像包含的版本不匹配。因此最终没有更换pytorch版本。

更换torch_npu版本。从torch_npu的release界面可知,该插件1.11.0的小版本有从post1到post6,比如下图的torch_npu-1.11.0.post6-cp37-cp37m-linux_aarch64.whl

官方本来推荐使用与1.11.0搭配的是post1,笔者尝试换成了post6。发现并不能解决问题,而且还会引发版本不兼容的bug。

[2023-12-12 11:30:45,809][ERROR][ flow.cc:537 ] build graph failed, Invalid argument, build graph failed, please check graph config. -> open flowunit ‘infer’, type ‘cpu’ failed. -> import infer@InferFlowUnit failed: ImportError: /usr/local/lib64/python3.7/site-packages/torch_npu/lib/libtorch_npu.so: undefined symbol: _ZNK5torch8autograd4Node4nameEv

更换了所有依赖版本都无效,顺便发现该问题与tensor.npu()的调用相关:

  • 如果调用tensor.npu()相关的代码,线程就会爆满。
  • 如果去掉模型推理和.npu()相关代码,该问题就会消失。

或许tensor.npu()的执行时间长,会触发modelbox某种机制,令线程数自动扩容?

解决办法

从modelbox git仓库的issue,add: max_executor_thread_num 可见,官方在23年9月为modelbox的配置文件加了个参数max_executor_thread_num,添加后,执行线程池的容量会有所限制,避免无限增长。

设置方式如下,需要修改graph的.toml文件,加一个参数max_executor_thread_num=1,就可以限制线程无限增长了。这个数值之后可以再调整为10或100,优化性能。

[graph]
max_executor_thread_num=1
graphconf = """
digraph model_inference {

修改后重启容器,能在框架启动时的日志中看到该参数被打印。
请添加图片描述

压测一段时间后,线程数被控制住了,该问题终于被解决。

文章来源:https://blog.csdn.net/duoyasong5907/article/details/134954817
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。