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应用进程的堆。

shell 复制代码

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驱动的版本，流程操作比较复杂，时间和技术上均不允许。

ASR项目实战-交付过程中遇到的疑似内存泄漏问题

检查业务流程

检查JVM配置

分析Java堆内存

参考资料

Kaldi

glibc

JVM

valgrind

malloc

pmap