ASR项目实战-交付过程中遇到的疑似内存泄漏问题
基于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
本文来自博客园,作者:jackieathome,转载请注明原文链接:https://www.cnblogs.com/jackieathome/p/17935678.html