內存異常增長的排查經歷

背景介紹

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

問題描述

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

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

分析&驗證

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

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

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

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

堆外內存分析驗證

glibc內存管理

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

tcmalloc內存管理

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

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

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

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

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

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

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

代碼位置：

報錯日志信息：

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

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

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

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

解決&總結

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

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

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

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

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

結語

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

審核編輯：湯梓紅