五個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。

 

點擊關注,第一時間了解華為雲新鮮技術~

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※想知道最厲害的網頁設計公司"嚨底家"!

※別再煩惱如何寫文案,掌握八大原則!

※產品缺大量曝光嗎?你需要的是一流包裝設計!