內(nèi)存異常增長的排查經(jīng)歷

背景介紹

華為云數(shù)據(jù)庫GaussDB(for Cassandra)是一款基于計算存儲分離架構(gòu)，兼容Cassandra生態(tài)的云原生NoSQL數(shù)據(jù)庫；它依靠共享存儲池實現(xiàn)了強一致，保證數(shù)據(jù)的安全可靠。核心特點是：存算分離、低成本、高性能。

問題描述

GaussDB(for Cassandra)自研架構(gòu)下遇到一些挑戰(zhàn)性問題，比如cpu過高，內(nèi)存泄漏，內(nèi)存異常增長，時延高等問題，這些也都是開發(fā)過程中遇到的典型問題。分析內(nèi)存異常增長是一個比較大的挑戰(zhàn)，內(nèi)存的異常增長對于程序來說是一個致命的問題，因為其可能觸發(fā)OOM，進程異常宕機，業(yè)務(wù)中斷等結(jié)果，所以對內(nèi)存進行合理的規(guī)劃使用及控制就顯得尤為重要。通過調(diào)整cache容量，bloom過濾器大小，以及memtable大小等等，實現(xiàn)性能提升，讀寫時延改善等效果。

在線下測試過程中發(fā)現(xiàn)內(nèi)核在長時間運行后，內(nèi)存只增不減，出現(xiàn)異常增長的情況，懷疑可能存在內(nèi)存泄漏。

分析&驗證

首先根據(jù)內(nèi)存使用，將內(nèi)存分為堆內(nèi)和堆外兩個部分，分別進行該兩塊內(nèi)存的分析。確定有問題的內(nèi)存是堆外內(nèi)存，進一步對堆外內(nèi)存分析。引入更高效的內(nèi)存管理工具tcmalloc，解決內(nèi)存異常增長問題。下面為具體分析驗證過程。

確定內(nèi)存異常區(qū)域

使用jdk的jmap命令和Cassandra的監(jiān)控(配置jvm.memory.*監(jiān)控項)等方法，每隔1min采集jvm的堆內(nèi)內(nèi)存及進程整體內(nèi)存。

啟動測試用例，直到內(nèi)核的整體內(nèi)存達到上限。分析采集到的堆內(nèi)內(nèi)存和進程內(nèi)存變化曲線，發(fā)現(xiàn)其堆內(nèi)內(nèi)存仍保持相對穩(wěn)定，未出現(xiàn)一直持續(xù)上漲，但期間內(nèi)核的整體內(nèi)存仍然在持續(xù)上漲，兩者的增長曲線不符。即問題應(yīng)該發(fā)生在堆外內(nèi)存。

堆外內(nèi)存分析驗證

glibc內(nèi)存管理

使用pmap命令打印進程的內(nèi)存地址空間分布，發(fā)現(xiàn)有大量的64MB的內(nèi)存塊和許多內(nèi)存碎片，該現(xiàn)象與glibc的內(nèi)存分配方式有關(guān)。堆外內(nèi)存的使用和進程整體的內(nèi)存增長趨勢相近，初步懷疑該問題是由堆外內(nèi)存導(dǎo)致。加之glibc歸還內(nèi)存的條件苛刻，即內(nèi)存不易及時釋放，內(nèi)存碎片多，猜測問題和gblic有關(guān)系。當內(nèi)存碎片過多，空閑內(nèi)存浪費嚴重，最終進程內(nèi)存的最大使用量會出現(xiàn)超過預(yù)期計劃最大值的可能，甚至出現(xiàn)OOM。

tcmalloc內(nèi)存管理

引入tcmalloc內(nèi)存管理器，代替glibc的ptmalloc內(nèi)存管理方式。減少過多的內(nèi)存碎片，提高內(nèi)存使用效率，本次分析驗證采用gperftools-2.7源碼進行tcmalloc的編譯。運行相同的測試用例，發(fā)現(xiàn)內(nèi)存仍在持續(xù)上漲，但是上漲幅度較之前降低，通過pmap打印出該內(nèi)存地址分布情況，發(fā)現(xiàn)之前的小內(nèi)存塊和內(nèi)存碎片顯著減小，說明該工具有一定優(yōu)化效果，印證了前面提到內(nèi)存碎片過多的猜測。

但是內(nèi)存異常增長的問題仍然存在，有點像是tcmalloc的回收不及時或者不回收導(dǎo)致。實際上tcmalloc的內(nèi)存回收是比較"reluctant"的，主要是為了當再次需要內(nèi)存申請時可以直接使用，減少系統(tǒng)調(diào)用次數(shù)，提高性能。基于此原因，下來進行手動調(diào)用其釋放內(nèi)存接口releasefreememory。發(fā)現(xiàn)效果不明顯，原因暫時未知(可能確實存在沒待釋放的空閑內(nèi)存)。

手動觸發(fā)tcmalloc的releasefreememory接口

為驗證該問題，通過設(shè)置cache容量的方式進行。

1.先設(shè)置cache的容量為6GB，然后將讀請求壓起來，使cache的6GB容量填滿

2.修改cache的容量為2GB，為快速是內(nèi)存釋放，手動調(diào)用tcmalloc的releasefreememory接口，發(fā)現(xiàn)沒有效果，推測采用tcmalloc之后，內(nèi)存仍然一直上漲不下跌的原因可能與該接口的有關(guān)。

3.在releasefreememory接口內(nèi)部的多個地方記錄日志，然后啟動進程再次測試，發(fā)現(xiàn)一處報錯是在進行系統(tǒng)調(diào)用madvise時有出現(xiàn)失敗。

代碼位置：

報錯日志信息：

1.通過該處的調(diào)用失敗，分析代碼。發(fā)現(xiàn)tcmalloc的內(nèi)存釋放邏輯是“round-robin”，即中間有一個span釋放失敗，則后續(xù)待釋放的span被終止，releasefreememory邏輯調(diào)用結(jié)束。這個就和前面的現(xiàn)象吻合，執(zhí)行完releasefreememory接口后基本沒有效果，發(fā)現(xiàn)每次都是在釋放了幾十MB時，因為該接口的調(diào)用失敗導(dǎo)致釋放邏輯終止。

2.再次分析該系統(tǒng)調(diào)用madvise失敗原因。通過給內(nèi)核的該方法打patch，發(fā)現(xiàn)其失敗原因是因為傳入的地址塊對應(yīng)的內(nèi)存狀態(tài)是LOCKED狀態(tài)。導(dǎo)致系統(tǒng)調(diào)用失敗，報錯為非法參數(shù)。

3.內(nèi)存為LOCKED狀態(tài)，和該狀態(tài)相關(guān)的有代碼調(diào)用mlock系統(tǒng)方法、系統(tǒng)的ulimit配置。分析相關(guān)代碼未發(fā)現(xiàn)異常點。查詢系統(tǒng)ulimit配置，發(fā)現(xiàn)max locked memory為unlimited。修改其配置為16MB，重啟Cassandra進程，再次測試，發(fā)現(xiàn)內(nèi)存釋放效果顯著。

4.繼續(xù)運行測試，發(fā)現(xiàn)內(nèi)存持續(xù)上漲的情況消失。在業(yè)務(wù)持續(xù)存在的情況下，內(nèi)存會上漲到最高，不再上漲，保持平穩(wěn)，符合內(nèi)存計劃使用量。業(yè)務(wù)壓力減少甚至停止后，內(nèi)存出現(xiàn)緩慢下降趨勢。

解決&總結(jié)

1.引入tcmalloc工具，優(yōu)化內(nèi)存管理。比較優(yōu)秀的內(nèi)存管理器有Google的tcmalloc和Facebook的jemalloc等

2.修改系統(tǒng)的max locked memory參數(shù)配置。

合理分配進程需要使用內(nèi)存的最大值，并預(yù)留一定容量，對于不符合預(yù)期增長的內(nèi)存需要進一步分析。內(nèi)存相關(guān)問題和程序相關(guān)性較強。系統(tǒng)的關(guān)鍵配置需謹慎，要評估其影響。同時排查了類似的所有配置。

增加releasefreememory的命令，后端進行調(diào)用，優(yōu)化tcmalloc hold內(nèi)存不釋放問題。不過releasefreememory命令的執(zhí)行會鎖整個pageHeap，可能導(dǎo)致內(nèi)存分配請求被hang，所以需要小心執(zhí)行。

后端增加可動態(tài)配置tcmalloc_release_rate的參數(shù)，來調(diào)整tcmalloc將內(nèi)存交還給操作系統(tǒng)的頻率。該值的合理范圍是[0-10]，0表示永遠不交還，值越大，表示交還的頻率越高，默認值是1。

結(jié)語

本文通過分析開發(fā)過程中遇到的內(nèi)存增長問題，使用更優(yōu)秀的內(nèi)存管理工具，以及更細粒度的內(nèi)存監(jiān)控，更直觀的監(jiān)控數(shù)據(jù)庫運行期間的內(nèi)存狀態(tài)，確保數(shù)據(jù)庫平穩(wěn)高性能運行。

審核編輯：湯梓紅