OB有問必答 | OceanBase的記憶體管理是怎麼做的？在實際的生産環境中是如何應用的？

記憶體管理是C高性能伺服器的核心問題。一些通用的記憶體管理庫，比如Google TCMalloc在記憶體申請/釋放速度、小記憶體管理、鎖開銷等方面都已經做得相當卓越了。然而，我們并沒有采用。這是因為通用記憶體管理庫在性能上畢竟不如專用的記憶體池，更為嚴重的是，它鼓勵了開發人員忽視記憶體管理的陋習，比如在伺服器程式中濫用C标準模闆庫（STL）。

在分布式存儲系統開發初期，記憶體相關的Bug相當常見，比如記憶體越界，伺服器出現Core Dump，這些Bug都非常難以調試。是以，這個時期記憶體管理的首要問題并不是高效，而是可控性，并防止記憶體碎片。

OceanBase系統有一個全局的定長記憶體池，這個記憶體池維護了由64KB大小的定長記憶體塊組成的空閑連結清單。OceanBase的全局記憶體池實作簡單，但記憶體使用率比較低，即使申請幾個位元組的記憶體，也需要占用大小為64KB的記憶體塊。

是以，全局記憶體池不适合管理小塊記憶體，每個需要申請記憶體的子產品，比如UpdateServer中的memtable，ChunkServer中的緩存，等等，都隻能從全局記憶體池中申請大塊記憶體，每個子產品内部再實作專用的記憶體池。每個線程處理讀寫請求時需要使用臨時記憶體，為了提高效率，每個線程會緩存若幹個大小分别為64KB和2MB的記憶體塊，每個線程總是首先嘗試從線程局部緩存中申請記憶體，如果申請不到，再從全局記憶體池中申請。

OceanBase的記憶體管理雖然沒有采用高深的技術，但是已經很好地滿足了系統初期的兩個最主要的需求：可控性以及沒有記憶體碎片。

那麼，在實際的生産環境中OceanBase的記憶體管理政策是什麼？

接下來我們為大家介紹三種最主要的場景：

1、OLTP場景

業務特點：讀寫RT敏感、資料一緻性敏感、SQL多以key-value類型為主、範圍查詢及連表查詢較少且也都走最優索引、讀寫比相差不大、業務存在明顯高峰期。

場景解讀：一般OLTP場景對讀寫RT要求嚴格，GB級OB庫一般要求RT保證在10ms以内，TB級OB庫甚至要求更低比如5ms。日常交易或者說事務要求嚴格保證資料一緻性，如發生RT抖動，鎖沖突驟增、極易發生業務資料錯誤。日常讀寫流量比基本上在3：1~1：1之間，且日常流量一般存在峰值，跟社會生活正常作息時間正相關。涉及行業一般有金融、電商、物流、社會各類服務業等。

配置推薦：對于此類場景的特點，一般需要将OB記憶體切換時間調整到最小，在日常流量峰值期間盡可能避免叢集發生合并，而将日常合并時間盡量調整到業務低峰期保證叢集合并對叢集性能影響最小，具體推薦配置參數如下：

memory_limit=0(預設即可，即OB使用實體機作業系統記憶體上限由memory_limit_percentage參數決定)

memory_limit_percentage=80/90(根據實體機可用記憶體大小決定，512G以下的使用80%，512及以上的采用90%)

freeze_trigger_percentage=60~75%（根據讀寫比例判斷，建議寫越高則取數越趨近于memory_limit_percentage值，目的是能更多的存放dml資料到記憶體，減少轉儲和合并）

minor_freeze_times=3-8（根據每日dml量決定，轉儲可快速釋放記憶體但也存在輕微抖動，轉儲速度取決于存儲媒體，ssd>hdd>sata）

2、OLAP場景

業務特點：讀寫RT可容忍在百毫秒甚至秒級、資料一緻性不敏感（可容忍毫秒級節點間資料不一緻，且分析型業務聚合計算資料都是萬到百萬級别量級）、SQL多以條件範圍排序、連表聚合計算為主（此類AP查詢SQL在OB中隻需走分區鍵索引或主鍵即可）、讀寫比往往是讀遠小于寫、僅讀業務存在高峰期、寫業務峰值往往有周期性或間歇性（主要原因為大多數AP類業務都有實時、離線周期性同步任務）。涉及行業一般有金融、電商、彩票、服務業、咨詢、科學計算領域等，較AP類業務更常見。

配置推薦：對于此類場景的特點，一般需要将OB記憶體切換時間調整到盡可能小的程度以保證資料同步性能不受合并影響，但同時也要考慮到AP場景實體機存儲媒體對合并影響的問題。日常合并次數減少帶來的一個問題就是合并時間也會增加（相比于每日開多輪轉儲和不開轉儲的情況）。是以這類場景需要結合存儲媒體進行決策，如采用ssd媒體可相對增加轉儲次數，盡量将合并控制在資料同步低峰期；如采用sata慢速存儲媒體，可優化合并線程數并減少轉儲次數（類似于曆史庫場景），盡可能增加合并速度，減少合并對寫入的影響。具體推薦配置參數如下：

memory_limit_percentage=80(建議使用80的配置，保證更多記憶體配置設定到cache和sql線程等動态伸縮記憶體中，保證讀資料正常傳回)

freeze_trigger_percentage=60%（這裡建議調小合并門檻值，保證剩餘記憶體能支援當機後記憶體未釋放期間的批量寫入，進而不影響到同步寫資料任務）

minor_freeze_times=3-5（該場景下建議ssd和hdd存儲媒體開啟轉儲，轉儲可快速釋放記憶體但也存在輕微抖動，轉儲速度取決于存儲媒體，ssd>hdd>sata，sata盤在此場景中不建議開啟轉儲）

3、曆史庫場景

業務特點：讀RT與TP類型業務無太大差異，對資料一緻性敏感，但對寫RT不敏感，SQL類型與TP類業務相似，多為key-value查詢，偶爾有統計及聚合類SQL但量不大。讀業務存在高峰期，寫業務無絕對峰值但存在規律性（同步資料任務為主）。涉及行業及使用場景場景的有金融行業的冷備庫、電商行業訂單類冷備庫等，主要作用為存放有價值的冷資料，提供資料回溯、曆史記錄查詢、曆史資料統計等，需保證讀RT在毫秒級，寫流量持續穩定，存儲資料量級一般在TB甚至PB級，故一般存儲媒體采用sata盤。

配置推薦：根據此類場景的特點，需要控制OB在記憶體切換時不影響讀性能，同時由于存儲媒體帶寬比較低，故還需控制合并效率，參數如下：

memory_limit_percentage=80(根據實體機可用記憶體大小決定，512G以下的使用80%，512及以上的采用90%)

freeze_trigger_percentage=80%（這裡建議将合并門檻值調到跟memstore參數一緻，保證每日合并次數盡可能少）

minor_freeze_times=0（該場景多為sata盤，sata盤在此場景中不建議開啟轉儲）

sys_bkgd_io_percentage = 90（調整系統IO線程占比到90，保證合并時資料盤帶寬能開到最大）

merge_thread_count= 48（預設為0，即由租戶線程自動配置設定合并線程，将其調整到48，使更多線程參與到合并中保證合并時間不會太久）

總結來說，使用OceanBase的過程中需要根據使用場景以及實體機型去調整記憶體管理參數，使叢集性能與業務要求達到最佳比對，在充分發揮出OceanBase記憶體表查詢低RT的優勢的同時，保證了在高可用前提下裝置的最大使用率，在性能和成本效益之間達到最佳均衡。