摘要：資源管控的目的是基於業務場景和可用資源，進行合理的資源與併發度管控，以保障數據庫可以在高負載場景下正常運行，不會因爲資源爭搶和耗盡出現系統卡死，提升系統整體吞吐量。
一、摘要
項目交付中可能會遇到同時包含核心交易（OLTP）和報表分析（OLAP）的混合業務場景，其中報表分析類業務複雜度高，消耗大量系統資源，但實時性要求較低，而核心交易類業務併發較大，多爲簡單事務處理，對實時性要求高。當系統處於業務高峯時，報表分析類業務併發操作會加劇系統負載，且長時間佔用資源無法釋放，最終可能導致整體性能裂化，實時性要求較高的核心交易類業務因資源爭搶而無法得到響應，從而影響客戶整體體驗。
資源管控的目的是基於業務場景和可用資源，進行合理的資源與併發度管控，以保障數據庫可以在高負載場景下正常運行，不會因爲資源爭搶和耗盡出現系統卡死，提升系統整體吞吐量。
二、場景分析
如上圖所示，業務場景主要分爲核心交易（OLTP）和報表分析（OLAP）兩大類，其中報表服務的優先級相對較低，在合理的情況下優先保障業務系統的正常運行。
業務系統中運行的SQL分爲簡單SQL和複雜SQL，大量複雜SQL的併發執行會導致數據庫服務器資源爭搶，簡單SQL的大量併發對服務器不構成持續壓力，短時間內可執行完成，不會造成業務堆積。其中報表服務中運行的SQL以複雜SQL居多，整體業務邏輯相對複雜，在數據庫層面需要分別對核心交易和報表服務進行合理的資源管控，以保障業務系統正常運行。
三、方案規劃
(一) 靜態資源池規劃
靜態資源池可以控制數據庫能使用服務器資源的上限，由於服務器操作系統運行也需要消耗一定的資源，因此預留一定的服務器資源來保障操作系統的正常運行。推薦靜態資源池配置：數據庫分配93% CPU資源和70% 內存資源。這樣可以保證服務器能夠正常響應系統請求。
- 靜態資源池分配93% CPU資源和70% 內存資源。
(二) 交易用戶和報表用戶分離
報表分析類業務的優先級和實時性相對較低，但是複雜度更高，爲有效進行資源管控，將報表分析和核心交易業務進行數據庫用戶分離，例如核心交易業務使用數據庫用戶budget_config_user，報表分析業務使用數據庫用戶report_user。針對交易用戶和報表用戶分別進行CPU資源和併發數控制以保障數據庫穩定運行。
結合報表分析業務的負載調研、日常監控和測試驗證，20併發以內的複雜報表SQL不會引起服務器資源爭搶，不會引起業務系統卡慢，因此配置報表用戶最多使用20%的CPU資源。
結合核心交易業務的的負載調研、日常監控和測試驗證，50併發以內的複雜SQL不會對系統造成持續壓力，整體CPU負載小於60%。
- 交易用戶分配60%的CPU配額和50併發。
- 報表用戶分配20%的CPU限額和20併發。
其中CPU配額是指佔用CPU時間片的百分比。若分配給某個用戶的CPU配額資源未使用，系統會自動將這些資源共享給其他用戶。CPU限額是指用戶可以使用的CPU核數的百分比。系統會將百分比換算成具體的核數供用戶使用，且用戶可使用的CPU限額資源不超過通過百分比換算的核數範圍。
(三) 併發管控閾值設置
資源管控的併發控制是基於SQL的cost值（SQL執行代價）來評估，結合客戶場景、硬件配置和SQL測試分析，當SQL的cost值小於1000時，SQL併發對服務器不構成持續壓力，短時間內可執行完成，不會造成業務堆積。當SQL的cost值大於1000時，大量併發會導致服務器資源爭搶，引起系統卡慢。
因此將受控SQL的cost的臨界值設置爲1000。當SQL的cost值大於1000時受資源管控的併發度控制，當SQL的cost值小於1000時不受資源管控的併發度控制。
- 區分SQL複雜和簡單的cost值設置爲1000
四、實施方案
(一)配置靜態資源池
登錄運維管理頁面，配置靜態服務池，設置cpu爲93%，內存爲70%
(二)數據庫用戶分離
創建交易用戶（budget_config_user）和報表用戶（report_user）。
(三) 配置cgroup
使用omm用戶登錄數據服務器，執行如下命令設置CPU配額：
source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile
gs_ssh -c "gs_cgroup -c -S class1 -s 60"
gs_ssh -c "gs_cgroup -c -S class1 -G wg1 -g 99"
gs_ssh -c "gs_cgroup -c -S class2 -s 20 "
gs_ssh -c "gs_cgroup -u -S class2 -s 20 --fixed"
gs_ssh -c "gs_cgroup -c -S class2 -G wg2 -g 99 "
(四) 創建資源池並綁定cgroup
使用omm用戶登錄數據庫服務器，執行如下命令設置併發管控：
source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile
gSQL -d postgres -p 25308 -c "create resource pool rp1 with (mem_percent=0,active_statements=50,control_group='class1:wg1');”
gSQL -d postgres -p 25308 -c "create resource pool rp2 with (mem_percent=0,active_statements=20,control_group='class2:wg2');"
(五) 用戶綁定資源池
使用omm用戶登錄數據庫服務器，執行如下命令將用戶綁定資源池：
source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile
gSQL -d postgres -p 25308 -c "alter user budget_config_user resource pool 'rp1';"
gSQL -d postgres -p 25308 -c "alter user report_user resource pool 'rp2';"
(六) 修改數據庫參數並重啓生效
使用omm用戶登錄數據庫服務器，執行如下命令修改數據庫參數：
source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile
gs_guc reload -Z coordinator -Z datanode -N all -I all -c "parctl_min_cost=1000"
gs_guc set -Z coordinator -Z datanode -N all -I all -c "enable_dynamic_workload=off"
cm_ctl stop
cm_ctl start
五、資源管控測試驗證
(一)測試SQL樣例五、資源管控測試驗證
select count(1) from p#fasp_t_glctrl122299 a,p#fasp_t_glctrl122299 b;
打印執行計劃如下，cost值大於1000，已按方案設置資源管控的併發控制閾值cost爲1000：
(二) 交易用戶併發驗證
- 使用交易用戶budget_config_user
- 使用測試SQL樣例（cost值大於1000）
- 啓動100併發測試
使用budget_config_user進行100併發樣例SQL驗證，當併發數達到50時管控，超過50併發後剩餘SQL在管道內排隊等待執行。
(三)報表用戶併發驗證
- 使用報表用戶report_user
- 使用測試SQL樣例（cost值大於1000）
- 啓動100併發測試
使用report_user進行100併發樣例SQL驗證，當併發數達到20時管控，超過20併發後剩餘SQL在管道內排隊，等待執行。
(四)報表用戶和交易用戶同時併發驗證
- 分別使用交易用戶budget_config_user和報表用戶report_user
- 使用測試SQL樣例（cost值大於1000）
- 分別啓動100併發測試
使用budget_config_user和report_user分別進行100併發樣例SQL驗證，交易用戶併發50受控，報表用戶併發20受控。
(五)報表用戶限額CPU驗證
- 使用報表用戶report_user
- 使用測試SQL樣例（cost值大於1000）
- 啓動100併發測試
CPU限額設置20%，使用report_user進行100併發樣例SQL驗證，CPU使用達到20%時進行資源管控。
CPU限額設置30%，使用report_user進行100併發樣例SQL驗證，CPU使用達到30%時進行資源管控。
(六)交易用戶配額CPU驗證
- 使用交易用戶budget_config_user
- 使用測試SQL樣例（cost值大於1000）
- 啓動100併發測試
在配額60%CPU的情況下，CPU使用可以超過60%，不進行CPU強制限制（這點與限額不同），業務高峯時可以根據業務情況彈性擴展。
點擊這裏→瞭解更多精彩內容