【華爲雲技術分享】五個Taurus垃圾回收compactor優化方案，減小系統資源佔用

TaurusDB是一種基於MySQL的計算與存儲分離架構的雲原生數據庫，一個集羣中包含多個存儲幾點，每一個存儲節點包含多塊磁盤，每塊磁盤對應一個或者多個slicestore的內存邏輯結構來管理. 在taurus的slicestore中將數據劃爲多個slice進行管理，每一個slice的大小是10G，Taurus架構圖以下：

TauruDB的存儲層支持append-only寫和隨機讀，最小數據存儲邏輯單元爲plog，每一個slice中包含多個plog，默認每一個plog的大小爲64M。slice中的plog主要用來存放page。Plog中存放中不一樣版本的page，有些老page已通過期，須要刪除；有些page是新page，須要被保留下來。

Compator主要用來清理plog中過時的page，把一個plog上全部沒有過時的page搬移到一個新plog，老的plog刪除掉。

Compactor的任務須要頻繁訪問內存中索引結構和讀寫plog中的page頁，這兩部分都屬於整個系統中關鍵資源，鎖競爭的壓力比較大，會直接影響性能，因此compactor的優化方案主要圍繞減小內存訪問和磁盤IO，須要考慮如下幾個點：

A、 選取的清理的plog集最優問題，每次回收須要搬運有效page，搬運的有效page數越少，磁盤IO就越小。如何每次調度都選取到垃圾量最大的一批plog；

B、 垃圾量是否分佈均勻，如何讓垃圾集中到一塊兒，回收垃圾集中的plog，提升回收效率；

C、 回收週期是固定的，怎麼樣保證在每一個週期內，都能取到最優plog集。

當前，咱們提出了幾個能夠有效減小page搬運數，從而達到減小IO目的的方案。

 

關鍵點1：全局調度

全局調度的方案增大plog垃圾量的排序範圍，從slice的範圍增大到slicestore的範圍。由於考慮到後面須要針對單個磁盤進行「加速回收」，因此不擴大到一個存儲節點的全局範圍。

全局調度方案按照slicestore來選取回收plog，先遍歷全部的slicestore，而後在slicestore內部進行垃圾量排序，選取最多的若干個plog進行回收；

優勢：有效避免一個slicestore中因爲垃圾分佈不均勻引發的plog的無效搬運，減小對plog的讀寫產生的IO；

缺點：排序範圍增大後，排序算法會增長CPU的消耗；

 

關鍵點2：排序算法優化

原始方案中在slice內部對plog按照垃圾量排序採用C++標準庫排序（std::sort），該算法內部基於快速排序、插入排序和堆排序實現。原始方案中每一個slice中最多存有160個plog，小數據量的排序或許效率影響不大，可是一個slicestore中存儲成百上千的slice，排序算法的效率問題就值得關注。

Taurus設計了一種topN算法，可以提高該場景下的效率。假設須要在n個元素中選取m個最大的元素，兩種算法的時間複雜度和空間複雜度：

C++標準庫排序時間複雜度爲O(nlogn)，空間複雜度爲O(nlogn)；

topN算法排序時間複雜度爲O(nlogm),空間複雜度爲O(1);

Compactor應用場景中，n和m相差幾個數量級，topN算法在時間和空間上都更具優點。

優勢：減小時間複雜度和空間複雜度；

 

關鍵點3：調度數優化

公共線程池分配給compactor的線程數是固定的，每一個週期調度器生成一次任務。原始方案中compactor的每次生成的任務數由slice個數決定，會致使任務隊列中的任務數過多或者過少。過多的話會失去時效性，也就是說plog的垃圾量會隨着時間改變，若是在隊列等待執行的時間太長，可能就不是當前最高垃圾量的plog，同時一次挑選的plog個數太多，會增長算法的時間和空間複雜度；過少的話，compactor線程沒有跑滿，會致使垃圾回收速度下降。

調度數優化也是基於全局調度優化，調度策略只須要保證在一個調度週期內，任務隊列中任務數恰好知足compactor線程執行。假設有8個slicestore，分配了24個執行線程，每一個線程每一個調度週期完成一個plog的回收，則每一個調度週期每一個slicestore只須要生成3個任務。

調度數優化即記錄公共線程池中正在執行和準備執行的任務數，跟據記錄決定本輪調度生成多少個回收任務，從而保證執行線程恰好夠用，且很少很多。

優勢：保證垃圾回收速度，最優回收的plog集，有效的減小page的搬運量。

 

關鍵點4：冷熱分區優化

在數據庫系統中，數據的更新並非相同頻率，一些數據頁更新或者寫入會更加頻繁（例如系統頁），這部分頁面被稱做熱頁，另一些更新不頻繁的稱做冷頁。若是把冷頁和熱頁混合放到一塊兒，就會致使更高的寫放大。舉個簡單的例子，假設有100個熱頁和10個冷頁，冷頁基本不更新可是每次垃圾回收，都須要重複把冷頁搬運一次。若是把冷頁單獨寫入一個plog，那麼在垃圾回收階段，就能夠減小重複搬運這部分冷頁，達到減小IO放大的效果。

   優勢：提升垃圾回收的效率和速度。

   缺點：須要額外的內存記錄熱度信息。

 

關鍵點5：磁盤逃生優化

爲了後臺線程好比備份、快照、垃圾回收、頁面回放等線程有足夠的磁盤空間運行，在磁盤容量使用到達必定閾值，會置Full標誌位，同時中止前臺IO。在極端狀況下，磁盤使用到閾值前臺IO會出現斷崖式下跌爲零：

爲了不在磁盤容量達到必定閾值以後前臺IO徹底中止，在磁盤使用率未達到閾值時，就應該有相應的處理機制。好比說在磁盤使用率未達閾值時，增長以下處理：

A、 下降前臺IO，減小磁盤的壓力；

B、 加速垃圾回收，也就是TaurusDB中的compactor機制；

A點不涉及compactor的功能，因此本文先不涉及，下面主要介紹兩種加速機制：

1、修改寫IO優先級

Compactor做爲後臺線程，考慮到整個系統的效率，正常運行時plog寫IO優先級默認爲low。在加速回收階段，plog的IO須要修改成high。

2、提升執行速度

前文可知，公共線程池爲compactor分配固定數目執行線程，並且運行過程當中只支持擴容不支持恢復。若是壓縮其餘後臺任務的執行線程，對整個系統的影響太大，量也不易控制。因此不考慮。

考慮到過程當中不能擴容，那就初始化就擴容，經過控制調度任務數控制任務執行速度。例如，假設compactor的運行線程在正常場景下爲4個，加速狀態下須要增長到8個。能夠在公共線程池中先分配8個線程，在正常場景下，控制任務隊列爲4個，另外4個線程處於wait狀態，只會佔用文件句柄，並不影響CPU。而在加速狀態下，控制任務隊列中的任務數爲8，就能夠實現上述的加速邏輯。

因此，提高寫IO的優先級可以加速page的搬運，提高垃圾回收速度。經過控制調度任務數控制任務執行速度卻很難控制很精準，上下會有必定的小波動。

 

最後

以上提到的垃圾回收compactor優化方案中，磁盤逃生優化可以處理磁盤容量緊急狀況。目前根據本地測試，在500G的小數據集狀況下，IO放大能減小到原來的1/6。系統資源佔用減小到原來的1/3。

 

點擊這裏，瞭解更多精彩內容