基于Kaldi实现语音识别时,需要引入一款名为OpenFST的开源软件,本文中提到的内存问题,即和这款软件相关。
考虑到过程比较曲折,内容相对比较长,因此先说结论。
在做长时间的语音识别时,集成了Kaldi和OpenFST的进程将会占用远超出预期的内存,这个现象可能和OpenFST、glibc的实现相关,未必是内存泄漏。
进程占用超出大量内存的原因,简单说一下:
- OpenFST在工作过程中,申请了很多内存,同时产生了很多内存碎片。
- 语音识别进程默认使用的glibc无法合并相关的碎片,因而即便相关的内存已经被释放,但glibc仍然无法向操作系统释放内存。
- 因此,在使用
top
观察进程的虚拟内存时,发现进程占用的内存会时间增长而一直增长,进而会被判定为疑似内存泄漏。
当然了,经过分析后,现在可以确认前述现象为非问题,只需要调整机器规格即可解决问题,但如前所述,整个过程比较曲折,这里记录下来,以备后察。
测试同事反馈,在性能环境上,执行压测过程中,算法服务出现了重启的现象。这是一个大问题,于是在第一时间联系我进行定位。
观察测试同事的压测环境,发现确实如测试同事所说,压测开始后,算法服务占用的虚拟内存以肉眼可见的速度缓慢增长。通过操作系统的硬件资源监控平台,观察进程一段时间内虚拟内存的占用趋势,发现没有进入平稳状态的迹象。最终观察的结果是算法服务占用的虚拟内存一直在增长,最终随着进程异常退出而结束。
我们的算法服务由业务代码、算法推断代码和机器学习模型组成。
- 业务代码使用Java开发,编译、构建成jar文件,运行时由JVM加载并运行。
- 算法推断代码使用C++开发,基于JNA规范,Java代码暴露接口,编译、构建成动态库,运行时由JVM加载。
- 机器学习模型,其实是几个数据文件,运行时由算法推断代码读取并使用。
考虑到当前版本中,算法推断代码和数据模型并没有引入新的变动点,因此重启现象的定位工作从算法服务的业务代码入手。
检查业务流程
首先分析业务流程。
本版本引入了长语音文件转写的特性,因此业务代码有比较大的变动。前期在实现时,为了简化实现方案,在文件转写的过程中,内存里缓存了很多数据。通过分析这部分实现,没有发现对象生命周期超长的现象,但仍然做了改进,将内存中缓存的数据交给数据库来缓存。
这时在开发环境中复现操作,观察内存增长的曲线,发现增长趋势有所减缓,但算法服务占用的虚拟内存,仍然在涨,没有收敛的迹象,因此仍然需要继续分析。
检查JVM配置
算法服务使用的Java堆的参数中,堆的最大值,比较大。本质上讲,经过上一环节的优化后,算法服务的业务代码中不涉及大量Java对象的生成,因此运行时,Java堆可以使用较少的内存。
修改算法服务Java堆的参数后,在开发环境中复现操作,基本功能正常。此外,使用jstat -gcutil <pid> 1000 1000
观察,确认JVM的GC操作运行正常,未发现异常现象。
长时间观察内存增长的曲线,发现没有明显改进,算法服务占用的虚拟内存,仍然在涨,没有收敛的迹象,因此仍然需要继续分析。
分析Java堆内存
内存问题分析到现在, 光靠看代码已经不解决问题,是时候召唤专业工具上场了。
对于Java应用的内存,jmap和MAT是一对完美的组合。
执行如下命令,导出Java应用进程的堆。
jmap -dump:live,format=b,file=dump001.bin <pid>
为了方便对比分析,一般至少需要导出四次堆。
- Java应用进程启动完毕。导出的堆文件命名为
dump001.bin
。 - 压力测试持续一段时间之后。假如可以准确的控制执行的压力测试的用例数量,则可以使用用例数量来衡量。导出的堆文件命名为
dump002.bin
。 - 在上次导出操作后,压力测试的TPS保持稳定,继续持续一段时间或者执行完毕一部分用例之后,再提取一次堆。导出的堆文件命名为
dump003.bin
。 - 停止压力测试,等待一段时间,此时再提取一次堆。导出的堆文件命名为
dump004.bin
。
将上述导出的三个文件,dump001.bin
、dump002.bin
、dump003.bin
一起导入至MAT。MAT基于eclipse开发,在配置文件中指定了Java堆的最小值和最大值,可以视堆文件的大小,酌情修改MAT的JVM参数。
使用MAT的histogram功能,对这三个文件进行对比。
- 对比
dump001.bin
和dump002.bin
,可以确认业务启动后,堆中出现的Java对象的类型和数量。结合业务用例和代码,可以确认对象的类型和数量,是否符合预期。 - 对比
dump002.bin
、dump003.bin
,可以确认业务运行平稳后,堆中出现的Java对象的类型和数量,是否稳定。假如压力测试的TPS保持稳定,则从理论上讲,Java堆中出现、湮灭的对象的数量应当是稳定的,对象的数量不会有太大的变化。 - 对比
dump003.bin
和dump004.bin
,确认Java堆中业务相关的对象的类型和数量,是否有较大的下降。一般而言,运行过程中的Java对象,应当在压力测试结束后,在JVM的垃圾回收操作中被回收掉,不应存在大量的残留。 - 对比
dump001.bin
和dump004.bin
,由于压力测试已经结束,Java堆中对象的类型和数量,二者之间的差异应当比较小。
使用jmap命令,导出堆,使用MAT分析。
反复拨测业务,使用jstat命令观察GC情况。
修改代码的实现,降低内存占用。
问题仍然存在。
算法同事参与分析,使用valgrind分析,memcheck和massif,未发现内存泄漏点。
使用pmap观察,Java进程的内存空间,发现很多64MB的块。在网上找到很多文章。
缩小变量的值
关闭线程分配器,均无效
使用tcmalloc分配器,内存仍然会涨,并且偶发性的进程异常退出,因此本方案不能在生产环境使用。
最终,定期调用malloc_trim,定期向操作系统释放内存。
总结
无法更新GPU驱动的版本,流程操作比较复杂,时间和技术上均不允许。
参考资料
Kaldi
glibc
JVM
valgrind
- valgrind massif内存分析
- 通过Valgrind的Massif工具进行C++内存使用分析
- valgrind-memcheck功能的使用和分析
- 施昌权–淘宝卫霍
- 如何使用Valgrind memcheck工具进行C/C++的内存泄漏检测
- How to Detect Memory Leaks Using Valgrind memcheck Tool for C / C++
malloc
- TCMalloc原理
- 图解 TCMalloc
- 内存优化总结:ptmalloc、tcmalloc和jemalloc
- glibc内存管理ptmalloc底层实现
- ptmalloc总结
- 使用 malloc_trim()
- malloc_trim
- 几个有用的 malloc 环境变量
- Malloc Tunable Parameters
pmap
1.本站内容仅供参考,不作为任何法律依据。用户在使用本站内容时,应自行判断其真实性、准确性和完整性,并承担相应风险。
2.本站部分内容来源于互联网,仅用于交流学习研究知识,若侵犯了您的合法权益,请及时邮件或站内私信与本站联系,我们将尽快予以处理。
3.本文采用知识共享 署名4.0国际许可协议 [BY-NC-SA] 进行授权
4.根据《计算机软件保护条例》第十七条规定“为了学习和研究软件内含的设计思想和原理,通过安装、显示、传输或者存储软件等方式使用软件的,可以不经软件著作权人许可,不向其支付报酬。”您需知晓本站所有内容资源均来源于网络,仅供用户交流学习与研究使用,版权归属原版权方所有,版权争议与本站无关,用户本人下载后不能用作商业或非法用途,需在24个小时之内从您的电脑中彻底删除上述内容,否则后果均由用户承担责任;如果您访问和下载此文件,表示您同意只将此文件用于参考、学习而非其他用途,否则一切后果请您自行承担,如果您喜欢该程序,请支持正版软件,购买注册,得到更好的正版服务。
5.本站是非经营性个人站点,所有软件信息均来自网络,所有资源仅供学习参考研究目的,并不贩卖软件,不存在任何商业目的及用途
暂无评论内容