細說GaussDB(DWS)複雜多樣的資源負載管理手段
摘要：對於如此多的管控功能，管控起來實際的效果到底如何，本篇文章就基於當前最新版本，進行效果實測，並進行一定的分析說明。
本文分享自華為雲社區《GaussDB(DWS) 資源負載管理：並發管控以及CPU管控效果實測以及分析說明【這次高斯不是數學家】》，作者： Malick 。
背景
GaussDB(DWS)提供了複雜多樣的資源負載管理手段：既可以從單個cn的總並發數限制作業的數量(max_active_statements)，也可以創建資源池，對於指定資源池的用戶進行並發限制。在資源池上，即可以進行記憶體、CPU的限制，也可以不進行資源限制。對於CPU資源的管控，即可以使用指定具體核數的硬限制，也可以使用空閑時按需分配，cpu跑滿時按照配比分配資源的軟限制。
正因為有這麼多的功能配置，才可以讓DWS在不同的業務場景中，採取不同的配置方案，維持業務穩定性，保證重要業務的資源使用。
對於如此多的管控功能，管控起來實際的效果到底如何，本篇文章就基於當前最新版本，進行效果實測，並進行一定的分析說明。主要分為以下幾個部分：
- 並發數限制在資源瓶頸時的作用
- CPU限額的實際使用效果
- CPU配額的實際效果，配額CPU與限額CPU的能力對比
場景一：並發數限制在資源瓶頸時的作用
所謂資源瓶頸，即CPU、記憶體、IO、網路其中的一項或者多項達到瓶頸，出現作業之前爭搶資源，造成性能大幅下降。對於此類場景，我們日常解決問題時，通常想到的幾個辦法：
1.降低業務的並發量; 2.抓出消耗資源高的sql語句，令其優化；3.對於耗費cpu高的作業進行資源限制，保障其他作業有足夠的資源可以使用。
理論上每個方法都有效果，但是效果如何，並不能簡單得說清楚，需要數據來進行一些印證。
環境搭建
1.配置：3台物理機，規格：
2.GaussDB（DWS）集群規格：
PS：集群的版本對測試結果基本沒有影響，各個版本功能規格基本沒有變化。
數據構造
測試CPU資源管控對於靈活短查詢以及複雜查詢的影響，複雜查詢採取TPCDS數據和靈活查詢採取TPCC數據。此處構造1500x的TPCDS/100xTPCC。
數據來源：
- tpcds數據由tpcds工具構造。耗時近一晚上。啟動本地gds伺服器，創建tpcds相應原表及外表，直接導入。HDD盤，導入性能也較差。
- tpcc數據在其餘測試數據伺服器中有現成數據，直接創建原表外表進行gds導入，100x數據，導入大約10min左右。
測試思路
- 找到tpcds中高CPU消耗的語句，測試幾個並發能將CPU打滿，並且需要運行時間不要過長，避免影響測試效率。
- 找到語句後，定好一批作業的並發數，例如整體作業數量為30個，只需4並發就會將CPU打滿，那麼測試不同的並發控制下，作業性能情況。
- 不同並發下第一個完成作業時間由於CPU爭搶程度不同，時間都不一樣，因此也需要記錄下來。
測試數據
說明：tpcds-Q9，在本測試環境1500x數據下，單並發可使物理機cpu達到30%-50%，單並發運行時間在100s左右。；本測試採取Q9*30作為一批作業。控制不同並發數，記錄每批的運行情況；4並發時cpu基本已經達到瓶頸，因此本輪測試從4並發開始。
測試結果如下：
結論分析
- 首先我們繪製一個並發數與整體執行時間，單個執行時間的趨勢變化圖：
圖表如下：
2.圖表分析，由上折線圖可以看出：
- 隨著並發數的增加，整體運行時間略微有所提升，說明在CPU瓶頸的情況下，並發數的降低，並不能提升批量作業的整體性能。
- 作業整體平均運行時間也比較平穩，平均每個作業運行的時間消耗，在不同並發數下也沒有大的差別。
- 第一個結束的作業運行時間，在並發數為4的情況下，只有400s+，而在並發數30拉滿的情況，達到了1620s+，差距很大，變化趨勢基本是隨著並發數的增長線性變長。
綜合說明
根據測試結論分析，在CPU瓶頸的情況下，限制並發數，實際並不能提升整體運行的性能；但是在不同場景下，可以選擇不同的配置策略。
例如：需要有作業及時響應的，可以將並發數限制少一些，這樣能保證總有作業能以較快的速度完成；需要整體作業運行性能較快的，根據測試數據，可以將並發數設大，這樣整體運行的時間最短。
