营销型网站制作服务商国际网络销售平台有哪些

序

该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 {

修改后重启容器，能在框架启动时的日志中看到该参数被打印。

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