摘要：资源管控的目的是基于业务场景和可用资源，进行合理的资源与并发度管控，以保障数据库可以在高负载场景下正常运行，不会因为资源争抢和耗尽出现系统卡死，提升系统整体吞吐量。
一、摘要
项目交付中可能会遇到同时包含核心交易（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强制限制（这点与限额不同），业务高峰时可以根据业务情况弹性扩展。
点击这里→了解更多精彩内容