Ubuntu20下TensorFlow调用C++函数引发虚拟内存增长问题排查

在Ubuntu 20系统运行TensorFlow时，通过TF执行自定义C++函数完成计算图的编译与销毁操作，进程虚拟内存会持续增长至40GB以上，最终因内存不足被系统终止。

通过LD_PRELOAD钩子跟踪malloc/free和mmap/munmap操作，并与/proc/self/status中的VmSize（进程虚拟内存占用）对比，发现以下规律：

• 编译计算图时，malloc分配的内存增长幅度与进程虚拟内存增长幅度几乎一致
• 销毁计算图时，malloc分配的内存减少，但进程虚拟内存并未下降

尽管malloc层面的内存占用整体保持稳定，进程虚拟内存仍快速攀升。示例数据如下：

before compile: 41MB[mmap]/3320MB[malloc]/12428MB[process]
after  compile: 46MB[mmap]/7434MB[malloc]/16529MB[process]
before destroy: 46MB[mmap]/7436MB[malloc]/16593MB[process]
after  destroy: 46MB[mmap]/3250MB[malloc]/16593MB[process]

注：graphDestroy函数设计上允许少量资源残留，属于预期情况。尝试调整mallopt(M_MMAP_THRESHOLD)未解决问题，寻求其他排查思路。

排查过程及有效解决方法 #

• 相关函数已通过单元测试中的sanitizers验证，排除函数本身内存泄漏问题
• valgrind在主训练循环启动前就导致程序崩溃，无法用于内存分析
• 尝试收集glibc内存统计信息：mallinfo输出信息无效，Ubuntu 20不支持mallinfo2，malloc_info输出内容过多难以分析
• 改用jemalloc及其malloc_stats_print函数获取统计信息，结果显示内存统计正常，且程序行为改变：虚拟内存仍会增长至75GB，但驻留内存稳定在约20GB，程序可正常运行无内存不足问题
• 尝试不依赖jemalloc，定期调用malloc_trim(0)，程序表现与使用jemalloc时一致：虚拟内存增长但驻留内存稳定，可正常运行

结论：malloc_trim有时可解决这类看似内存泄漏的虚拟内存增长问题。参考LinkedIn技术文章：《2021年用jemalloc驯服Venice中的内存碎片》

内容的提问来源于stack exchange，提问作者Alexander