在现代数据库系统中，RocksDB 作为一种高性能的键值存储引擎，广泛应用于需要高吞吐量和低延迟的场景。然而，在使用过程中观察到 RocksDB 的内存使用常常超出预设的阈值，这一现象对系统的稳定性和可用性构成了严重威胁。

RocksDB 提供了通过 block-cache-size 参数来控制缓存使用的机制。开发者可以通过以下代码片段设置缓存大小：

左右滑动查看完整代码

然而，实际应用中发现，RocksDB 的内存占用往往超出了设定的 cache_size 值。这种内存使用的不可预测性导致了内存分配的失控，甚至触发了程序的 OOM（Out of Memory）错误，严重影响了服务的连续性和可靠性。

有部分开发者报告了相似的内存超额使用问题，该问题在 GitHub 社区也引起了广泛关注。

图片来源：https://learn.lianglianglee.com/

其中，第一步和第二步可以观察到内存问题的现象，而最难的往往是第三步，对内存的使用情况进行分析。第三步中需要结合业务代码，对问题的根因提出假设，然后配合一些工具来验证假设。分析的过程更像在做实验：提出假设，收集数据，验证假设，得出结论。下文中，也会搭配内存工具进行分析，供读者参考。

在前文所述的 RocksDB 内存使用问题背景下，我们业务生产环境遭遇了相似的挑战。应用程序采用 glibc 的 ptmalloc 作为内存分配器。在程序中，存在两个 RocksDB 实例，分别用于存储不同类型的数据。根据配置，两个实例的 block-cache-size 分别被设定为4GB和8GB。然而，实际的内存消耗量远远超出了这一预设值，导致整体内存使用量显著高于预期。

通过执行 free -g 命令，监测到程序的内存使用量达到了59GB，这一数值已经接近了物理服务器的内存容量阈值。此外，通过定期执行 vmstat 3 命令，观察到自服务启动以来，内存使用量持续上升，直至接近100%的使用率。这一现象表明，系统内存已极度紧张，存在触发 OOM（Out of Memory）错误的风险。

鉴于当前内存使用情况，确认了内存管理问题的存在，并认识到需要进一步结合源代码进行深入分析，以识别内存使用异常的根本原因，并探索相应的优化措施。

3.1 内存泄露分析

以下分析均在内部测试环境中进行，使用的是16C32G的机器。起初，怀疑 RocksDB 存在内存泄露，会不断申请内存并且不会回收。

分析内存泄露的常用工具有 valgrind、memleak、strace、jemalloc 的 jeprof。这里用到的工具是 jemalloc 的 jeprof。jeprof 的原理主要是在内存的 malloc 和 free 的地方进行监控并收集数据，使用时可以设置定期打印数据。

通过 RocksDB 提供的的 db.getProperty()  方法对各个模块占用内存情况进行取值，结果如下：

左右滑动查看完整代码

发现主要占用内存的地方有两个：block-cache-usage 和  estimate-table-readers-mem。这两个属性分别对应了 RocksDB 中的 block_cache 以及 indexs/filters。

但是随着时间的推移，block_cache 和 indexs/filters 会达到一个均衡点，不再增加上涨。与 RocksDB 存在内存泄露的假设不相符。

进一步分析 RocksDB 分配内存的调用堆栈，由于 glibc ptmalloc 无法打印调用堆栈，将 glibc ptmalloc 切换成了 jemalloc，通过 jeprof 进行内存调用堆栈的打印，以下是 jemalloc 的安装方法：

左右滑动查看完整代码

上述命令中，--enable-prof 代表开启 jemalloc 的 jeprof 功能。

安装完成后，通过 LD_PRELOAD 命令来开启 jemalloc 的 malloc 和 free。LD_PRELOAD 的原理是直接使用 jemalloc 的 malloc 和 free 方法替换掉 glibc 的 malloc/free。

通过以下命令启动程序：

左右滑动查看完整代码

上述命令中 

export MALLOC_CONF="prof:true,lg_prof_interval:29" 

代表开启 jeprof 的信息捕获，内存每次上涨 2的29次方 btyes (512MB) 便记录一次信息。最终输出了结果，可以通过以下命令将结果转成调用堆栈图：

左右滑动查看完整代码

查看了线上机器的 /proc/meminfo，大部分内存主要用在了程序申请的栈内存和堆内存中，可以看到下图中 Active(anon)  匿名内存占用了52G，这部分内存申请后没有被释放。

glibc 申请的内存均属于这部分内存。

为什么会创建这么多的64M的内存区域？这个跟 glibc 的内存分配器有关系。glibc 每次进行 mmap 分配时申请内存的大小在64位系统上默认为64MB。

此时便进一步提出了新的假设：是否因为 glibc 的内存分配机制不合理，导致内存不断申请，但是不释放资源？

分析 glibc 分配的内存情况，可以使用 glibc 提供的接口：

malloc_info(https://man7.org/linux/man-pages/man3/malloc_info.3.html

左右滑动查看完整代码

左右滑动查看完整代码

左右滑动查看完整代码

因此，fast 和 rest 加起来为当前 glibc 中空闲的未归还给操作系统的内存。通过命令 awk 将文件中所有 fast 和 rest 占用的内存加起来后，发现约为 4G 。

发现是 glibc ptmalloc 的问题之后，解决也相对简单，业内有更好的 ptmalloc 替代方案，如 jemalloc 以及 tcmalloc。

将 jemalloc 应用到线上环境之后发现，确实像预期那样，内存的使用相比于 ptmalloc 更少，此前，机器的内存一直维持在高位，使用 jemalloc 之后，内存的使用下降了1/4（从95%+下降到80%+），随着内存地释放，有更多的内存可用于处理请求，IO和CPU的使用率就降低了，下图是内存、磁盘IO使用率以及 CPU 空闲率的对比图。

在进行内存超量使用问题的分析过程中，最初怀疑是 RocksDB 存在一些内存管理不合理的地方导致了内存超量使用。然而，经过深入研究和分析，发现实际的原因主要由 glibc的 ptmalloc 内存回收机制所导致。整个分析过程较为繁琐，需要结合一些合适的内存分析工具，逐层深入，不断假设并验证猜想。

总的来说，内存超量使用问题得到了解释，也成功解决。通过逐步深入，持续假设和验证，最终找到了真正的问题所在，希望能为读者在解决类似问题上提供一些灵感和思路。

1. https://github.com/facebook/rocksdb/wiki/Partitioned-Index-Filters

2. https://github.com/facebook/rocksdb/wiki/Memory-usage-in-RocksDB

3. http://jemalloc.net/jemalloc.3.html
   https://paper.seebug.org/papers/Archive/refs/heap/glibc%E5%86%85%E5%AD%98%E7%AE%A1%E7%90%86ptmalloc%E6%BA%90%E4%BB%A3%E7%A0%81%E5%88%86%E6%9E%90.pdf

4. https://man7.org/linux/man-pages/man3/malloc_info.3.html