一、背景

1.1 前言

在現(xiàn)代數(shù)據(jù)庫系統(tǒng)中，RocksDB 作為一種高性能的鍵值存儲引擎，廣泛應(yīng)用于需要高吞吐量和低延遲的場景。然而，在使用過程中觀察到 RocksDB 的內(nèi)存使用常常超出預(yù)設(shè)的閾值，這一現(xiàn)象對系統(tǒng)的穩(wěn)定性和可用性構(gòu)成了嚴(yán)重威脅。

RocksDB 提供了通過 block-cache-size 參數(shù)來控制緩存使用的機(jī)制。開發(fā)者可以通過以下代碼片段設(shè)置緩存大小：

std::shared_ptr<rocksdb::Cache> cache = rocksdb::NewLRUCache(cache_size, -1, true);

然而，實際應(yīng)用中發(fā)現(xiàn)，RocksDB 的內(nèi)存占用往往超出了設(shè)定的 cache_size 值。這種內(nèi)存使用的不可預(yù)測性導(dǎo)致了內(nèi)存分配的失控，甚至觸發(fā)了程序的 OOM（Out of Memory）錯誤，嚴(yán)重影響了服務(wù)的連續(xù)性和可靠性。

有部分開發(fā)者報告了相似的內(nèi)存超額使用問題，該問題在 GitHub 社區(qū)也引起了廣泛關(guān)注。

1.2 內(nèi)存分析流程

在分析內(nèi)存的過程中，可以搭配許多 Linux 的命令工具來進(jìn)行。以下是一套內(nèi)存分析的基本思路：

圖片來源：https://learn.lianglianglee.com/

1、可以先用 free 和 top，查看系統(tǒng)整體的內(nèi)存使用情況。
2、再用 vmstat 和 pidstat，查看一段時間的趨勢，從而判斷出內(nèi)存問題的類型。
3、最后進(jìn)行詳細(xì)分析，比如內(nèi)存分配分析、緩存/緩沖區(qū)分析、具體進(jìn)程的內(nèi)存使用分析等。

其中，第一步和第二步可以觀察到內(nèi)存問題的現(xiàn)象，而最難的往往是第三步，對內(nèi)存的使用情況進(jìn)行分析。第三步中需要結(jié)合業(yè)務(wù)代碼，對問題的根因提出假設(shè)，然后配合一些工具來驗證假設(shè)。分析的過程更像在做實驗：提出假設(shè)，收集數(shù)據(jù)，驗證假設(shè)，得出結(jié)論。下文中，也會搭配內(nèi)存工具進(jìn)行分析，供讀者參考。

二、問題描述

在前文所述的 RocksDB 內(nèi)存使用問題背景下，我們業(yè)務(wù)生產(chǎn)環(huán)境遭遇了相似的挑戰(zhàn)。應(yīng)用程序采用 glibc 的 ptmalloc 作為內(nèi)存分配器。在程序中，存在兩個 RocksDB 實例，分別用于存儲不同類型的數(shù)據(jù)。根據(jù)配置，兩個實例的 block-cache-size 分別被設(shè)定為4GB和8GB。然而，實際的內(nèi)存消耗量遠(yuǎn)遠(yuǎn)超出了這一預(yù)設(shè)值，導(dǎo)致整體內(nèi)存使用量顯著高于預(yù)期。

通過執(zhí)行 free -g 命令，監(jiān)測到程序的內(nèi)存使用量達(dá)到了59GB，這一數(shù)值已經(jīng)接近了物理服務(wù)器的內(nèi)存容量閾值。此外，通過定期執(zhí)行 vmstat 3 命令，觀察到自服務(wù)啟動以來，內(nèi)存使用量持續(xù)上升，直至接近100%的使用率。這一現(xiàn)象表明，系統(tǒng)內(nèi)存已極度緊張，存在觸發(fā) OOM（Out of Memory）錯誤的風(fēng)險。

鑒于當(dāng)前內(nèi)存使用情況，確認(rèn)了內(nèi)存管理問題的存在，并認(rèn)識到需要進(jìn)一步結(jié)合源代碼進(jìn)行深入分析，以識別內(nèi)存使用異常的根本原因，并探索相應(yīng)的優(yōu)化措施。

三、分析過程

3.1 內(nèi)存泄露分析

以下分析均在內(nèi)部測試環(huán)境中進(jìn)行，使用的是16C32G的機(jī)器。起初，懷疑 RocksDB 存在內(nèi)存泄露，會不斷申請內(nèi)存并且不會回收。

分析內(nèi)存泄露的常用工具有 valgrind、memleak、strace、jemalloc 的 jeprof。這里用到的工具是 jemalloc 的 jeprof。jeprof 的原理主要是在內(nèi)存的 malloc 和 free 的地方進(jìn)行監(jiān)控并收集數(shù)據(jù)，使用時可以設(shè)置定期打印數(shù)據(jù)。

通過 RocksDB 提供的的 db.getProperty()  方法對各個模塊占用內(nèi)存情況進(jìn)行取值，結(jié)果如下：

rocksdb.estimate-table-readers-mem: 16014055104  // 重點關(guān)注
rocksdb.block-cache-usage: 1073659024  // 重點關(guān)注

發(fā)現(xiàn)主要占用內(nèi)存的地方有兩個：block-cache-usage 和  estimate-table-readers-mem。這兩個屬性分別對應(yīng)了 RocksDB 中的 block_cache 以及 indexs/filters。

但是隨著時間的推移，block_cache 和 indexs/filters 會達(dá)到一個均衡點，不再增加上漲。與 RocksDB 存在內(nèi)存泄露的假設(shè)不相符。

進(jìn)一步分析 RocksDB 分配內(nèi)存的調(diào)用堆棧，由于 glibc ptmalloc 無法打印調(diào)用堆棧，將 glibc ptmalloc 切換成了 jemalloc，通過 jeprof 進(jìn)行內(nèi)存調(diào)用堆棧的打印，以下是 jemalloc 的安裝方法：

# 用jemalloc 對于服務(wù)來說沒有改造成本。
# 可以直接使用LD_PRELOAD=/usr/local/lib/libjemalloc.so這種動態(tài)鏈接的方式去植入
# 前提是Linux機(jī)器上需要先安裝jemalloc：
wget https://github.com/jemalloc/jemalloc/archive/5.1.0.tar.gz tar zxvf jemalloc-5.1.0.tar.gz
cd jemalloc-5.1.0/
./autogen.sh
./configure --prefix=/usr/local/jemalloc-5.1.0 --enable-prof
make && make install_bin install_include install_lib

上述命令中，--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"
LD_PRELOAD=/usr/local/jemalloc-5.1.0/lib/libjemalloc.so ./process_start

上述命令中 export MALLOC_CONF="prof:true,lg_prof_interval:29" 代表開啟 jeprof 的信息捕獲，內(nèi)存每次上漲 2的29次方 btyes (512MB) 便記錄一次信息。最終輸出了結(jié)果，可以通過以下命令將結(jié)果轉(zhuǎn)成調(diào)用堆棧圖：

jeprof  --show_bytes --pdf ./process_start jeprof.34447.0.f.heap > result.pdf

最終觀察堆棧圖（只截取了部分）發(fā)現(xiàn)，RocksDB 正常調(diào)用分配內(nèi)存的方法：rocksdb::AllocateBlock，沒有觀察到有內(nèi)存泄露的情況。

3.2 系統(tǒng) glibc ptmalloc 分析

搜索了很多類似的問題，發(fā)現(xiàn)也有開發(fā)者都遇到了 glibc 內(nèi)存分配不釋放的問題，便懷疑是否是 glibc 的內(nèi)存分配不合理導(dǎo)致的。目前線上環(huán)境 glibc 的版本是2.17。

查看了線上機(jī)器的 /proc/meminfo，大部分內(nèi)存主要用在了程序申請的棧內(nèi)存和堆內(nèi)存中，可以看到下圖中 Active(anon)  匿名內(nèi)存占用了52G，這部分內(nèi)存申請后沒有被釋放。

glibc 申請的內(nèi)存均屬于這部分內(nèi)存。

其次，通過 pmap -X pid 查看進(jìn)程的內(nèi)存塊，發(fā)現(xiàn)有很多64MB的內(nèi)存段。

為什么會創(chuàng)建這么多的64M的內(nèi)存區(qū)域？這個跟 glibc 的內(nèi)存分配器有關(guān)系。glibc 每次進(jìn)行 mmap 分配時申請內(nèi)存的大小在64位系統(tǒng)上默認(rèn)為64MB。

此時便進(jìn)一步提出了新的假設(shè)：是否因為 glibc 的內(nèi)存分配機(jī)制不合理，導(dǎo)致內(nèi)存不斷申請，但是不釋放資源？

分析 glibc 分配的內(nèi)存情況，可以使用 glibc 提供的接口：

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

The malloc_info() function exports an XML string that describes the current state of the memory-allocation implementation in the caller. The string is printed on the file stream stream. The exported string includes information about all arenas.

以下為 malloc_info 的接口定義。該接口會將內(nèi)存分配的情況直接以 XML 的形式輸出到文件中。

#include <malloc.h>
int malloc_info(int options, FILE *stream);

在程序中添加內(nèi)存信息打印的代碼，每隔一段時間觸發(fā)一次打印：

FILE *filePointer;
filePointer = fopen("mem_info.log", "a");
if (filePointer != nullptr) {
  malloc_info(0, filePointer);
  fclose(filePointer);
}

以下為 malloc_info 輸出的內(nèi)容（截取部分內(nèi)容）：

<malloc versinotallow="1">
<heap nr="0">
<sizes>
  <size from="17" to="32" total="32" count="1"/>
  <size from="33" to="48" total="48" count="1"/>
  <size from="81" to="96" total="1824" count="19"/>
  <size from="97" to="112" total="112" count="1"/>
  <size from="33" to="33" total="42636" count="1292"/>
  // ....
</sizes>
<total type="fast" count="22" size="2016"/>
<total type="rest" count="5509" size="33761685"/>
<system type="current" size="230117376"/>
<system type="max" size="230117376"/>
<aspace type="total" size="230117376"/>
<aspace type="mprotect" size="230117376"/>
</heap>

XML 內(nèi)容闡述：

1.nr 即 arena，通常一個線程一個，線程間會相互爭搶 arena。

2.<size from="17" to="32" total="32" count="1"/>

大小在一定范圍內(nèi)的內(nèi)存，會放到一個鏈表里，這就是其中一個鏈表。from 是內(nèi)存下限，to是上限，上面的意思是內(nèi)存分配在 [17,32] 范圍內(nèi)的空閑內(nèi)存總共有32個。

3.<total type="fast" count="22" size="2016"/>

即 fastbin 這鏈表當(dāng)前有22個空閑內(nèi)存塊，大小為2016字節(jié)。

4.<total type="rest" count="5500" size="33761685"/>

除 fastbin 以外，所有鏈表空閑的內(nèi)存數(shù)量，以及內(nèi)存大小，此處內(nèi)存塊數(shù)量為5509，大小為33761685字節(jié)。

因此，fast 和 rest 加起來為當(dāng)前 glibc 中空閑的未歸還給操作系統(tǒng)的內(nèi)存。通過命令 awk 將文件中所有 fast 和 rest 占用的內(nèi)存加起來后，發(fā)現(xiàn)約為 4G 。

當(dāng)前 RocksDB 進(jìn)程的內(nèi)存使用量為20.48G，上述提到 block-cache-usage 和 estimate-table-readers-mem 加起來只有15.9G （1073659024 bytes + 16014055104 bytes）。相當(dāng)于中間差距還有4G左右。剛好和 glibc 占用的空閑內(nèi)存相吻合。

最終確認(rèn)是由于 glibc 的 ptmalloc 內(nèi)存管理器申請內(nèi)存不回收，導(dǎo)致了機(jī)器內(nèi)存緊張。

四、問題解決

發(fā)現(xiàn)是 glibc ptmalloc 的問題之后，解決也相對簡單，業(yè)內(nèi)有更好的 ptmalloc 替代方案，如 jemalloc 以及 tcmalloc。

將 jemalloc 應(yīng)用到線上環(huán)境之后發(fā)現(xiàn)，確實像預(yù)期那樣，內(nèi)存的使用相比于 ptmalloc 更少，此前，機(jī)器的內(nèi)存一直維持在高位，使用 jemalloc 之后，內(nèi)存的使用下降了1/4（從95%+下降到80%+），隨著內(nèi)存地釋放，有更多的內(nèi)存可用于處理請求，IO和CPU的使用率就降低了，下圖是內(nèi)存、磁盤IO使用率以及 CPU 空閑率的對比圖。

在相關(guān)性能指標(biāo)得到優(yōu)化之后，服務(wù)可用性以及RT也得到了提升。

五、總結(jié)

在進(jìn)行內(nèi)存超量使用問題的分析過程中，最初懷疑是 RocksDB 存在一些內(nèi)存管理不合理的地方導(dǎo)致了內(nèi)存超量使用。然而，經(jīng)過深入研究和分析，發(fā)現(xiàn)實際的原因主要由 glibc的 ptmalloc 內(nèi)存回收機(jī)制所導(dǎo)致。整個分析過程較為繁瑣，需要結(jié)合一些合適的內(nèi)存分析工具，逐層深入，不斷假設(shè)并驗證猜想。

總的來說，內(nèi)存超量使用問題得到了解釋，也成功解決。通過逐步深入，持續(xù)假設(shè)和驗證，最終找到了真正的問題所在，希望能為讀者在解決類似問題上提供一些靈感和思路。

六、參考文獻(xiàn)

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.htmlhttps://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