majic31

Results 15 comments of majic31

感觉c++的websocket版本(wss)比较稳定,但是http并没有编译打包到镜像中,是不是用wss会更好些? 我们实践中是用wss版,然后自己做一个http层(fastapi)跟wss互联互通架上去,也挺稳的。 如果真要扣细节,上面楼也说了,需要自己gdb一下,估计是哪个数组没保护到位,非法访问引起core dump了

> > 感觉c++的websocket版本(wss)比较稳定,但是http并没有编译打包到镜像中,是不是用wss会更好些? 我们实践中是用wss版,然后自己做一个http层(fastapi)跟wss互联互通架上去,也挺稳的。 > > 如果真要扣细节,上面楼也说了,需要自己gdb一下,估计是哪个数组没保护到位,非法访问引起core dump了 > > 我实际需求 需要http,找了很多教程 不知道怎么改成http去调用 用fastapi实现一层http服务就好了,这个直接问一下大模型(豆包,通义),再结合一些资料,应该比较快可以做出来的。

每个会话结束了,会发送is_final=True,应该就不会触发这个问题了吧~

> > 每个会话结束了,会发送is_final=True,应该就不会触发这个问题了吧~ > > 改一下源码也可以,int 溢出了,他有个总长度的int,一直发数据,长度在累加,超过大概18个小时,int就溢出了。改成long 可以无限一直发下去 如果是长音频,的确有你说的情况,感谢! 但是也的确发现内存有在微涨,我这边是8核8路并发,内存经过12小时后,现在大概在5.4G(6小时左右的时候是在4.9GB),这部分内存一直都不释放的(即使停止压测也不释放)

> > 每个会话结束了,会发送is_final=True,应该就不会触发这个问题了吧~ > > 改一下源码也可以,int 溢出了,他有个总长度的int,一直发数据,长度在累加,超过大概18个小时,int就溢出了。改成long 可以无限一直发下去 不改int时,感觉会一直上涨,但将int改为long后,目前能看到内存回落了,比较神奇~ 很奇怪的就是data_buf_all_size难道不是当前session有效吗?(比较奇怪~)

> > > > 每个会话结束了,会发送is_final=True,应该就不会触发这个问题了吧~ > > > > > > > > > 改一下源码也可以,int 溢出了,他有个总长度的int,一直发数据,长度在累加,超过大概18个小时,int就溢出了。改成long 可以无限一直发下去 > > > > > > 不改int时,感觉会一直上涨,但将int改为long后,目前能看到内存回落了,比较神奇~ 很奇怪的就是data_buf_all_size难道不是当前session有效吗?(比较奇怪~) > > 这个内存问题很大一部分是因为你音频发送的速度过快,那个存储任务的vector队列会一直扩大,当你任务消耗完了,vector也不会往自动变小,好像是asio 那个框架问题。长度改成long应该是解决不了内存不断增加的问题。你试试循环不间断发音频,中间不要sleep,内存会一直扩。 我现在就是不间断发送wav二进制chunk,每个chunk之间sleep...

> > > > > > 每个会话结束了,会发送is_final=True,应该就不会触发这个问题了吧~ > > > > > > > > > > > > > > > 改一下源码也可以,int 溢出了,他有个总长度的int,一直发数据,长度在累加,超过大概18个小时,int就溢出了。改成long 可以无限一直发下去 > > > > >...

我用最新的master安装测试没问题(昨天直接用官网的pip install funasr_onnx也ok) 您这边的FunASR Version (e.g., 1.0.0) 升级一下版本测试下是不是就好了?

> 我补充了详细的环境信息。我目前装的FunASR 1.2.0似乎已经是最新的,报错问题仍然存在 你测试的是funasr onnx,所以需要更新funasr_onnx版本。我这边最新的funasr_onnx版本是0.4.1 最新的也可以用源码安装,参考这个试一下:https://github.com/modelscope/FunASR/blob/main/runtime/python/onnxruntime/README.md (or install from source code 那里)

> > > 反馈下当前的观察结果,线上一段时间之后内存占用率趋于稳定,但是刚开始的内存是不断上涨的,后续继续观察线上情况。 > > > ![Image](https://github.com/user-attachments/assets/5707b807-e6d0-4e75-87b4-023582b613f7) > > > > > > 请问后续内存是一直稳定在一个水位么,我也遇到这个问题了 > > 是的没有上升的那么明显了给了一个较大的内存,由于输入的音频流比较多应该是跟linux的buffer缓存未释放有关系 但是我释放了buffer/cache还是没啥用~