Linux Debugging （九）一次生产环境下的“内存泄露”

最新推荐文章于 2024-08-21 10:09:14 发布

anzhsoft

最新推荐文章于 2024-08-21 10:09:14 发布

阅读量1.1w

点赞数 3

分类专栏： Linux 架构探索调试实践 Linux 调试技巧

本文链接：https://blog.csdn.net/anzhsoft/article/details/41213163

版权

本文记录了一次在Linux生产环境中遇到的内存泄露问题，过程涉及对一个RPC server的分析，源码阅读，使用Valgrind和gperftools进行内存检查。虽然Valgrind未能检测出问题，但通过gperftools的heap检查，最终发现了内存未被正确释放的问题，提示了强制释放不再使用的缓冲区的解决方案。

摘要由CSDN通过智能技术生成

一个偶然的机会，发现一个进程使用了超过14G的内存。这个进程是一个RPC server，只是作为中转，绝对不应该使用这么多内存的。即使并发量太多，存在内存中的数据太多，那么在并发减少的情况下，这个内存使用肯定会降下来。但是事实上，这个内存会一直涨，直到被OOM Killer杀掉。

由于这个rpc server的逻辑比较简单，先走读源码，除了发现一些简单的编程上面的问题外，没有大的问题。先上valgrind：

valgrind --tool=memcheck --leak-check=full -v ./rpc_server

原来的情况是，一般都会检查出内存泄露的。这次没有（否则也不会有本文了）：

实际上至少10G的“内存泄露”。既然没有检查出，说明这些内存还是活着的。设想一下这个场景：每个请求都new一块内存，放到一个列表中。正常的话请求处理完需要从这个列表中删除这块内存。如果没有删除，那么这就算是内存泄露。但是valgrind检查不出来。

由于上面这个进程使用了tcmalloc，是不是tcmalloc的问题？我们知道tcmalloc的效率要优于malloc，那么是不是tcmalloc的问题，如果它一直申请内存，不释放，就会造成这种”内存泄露“。注意下面一段话：

Releasing Memory Back to the System

By default, tcmalloc will release no-longer-used memory back to the kernel gradually, 
over time.
The tcmalloc_release_rate flag controls how quickly this happens. 
You can also force a release at a given point in the progam execution like so:

   MallocExtension::instance()->ReleaseFreeMemory();
You can also call SetMemoryReleaseRate() to change the tcmalloc_release_rate value
 at runtime, or GetMemoryReleaseRate to see what the current release