一、摘要
項目交付中可能會遇到同時包含核心交易（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強制限制（這點與限額不同），業務高峰時可以根據業務情況彈性擴展。
