本文分享自华为云社区《GaussDB(DWS)资源管理能力介绍与应用示例》，作者：门前一棵葡萄树。

一、资源管理能力

1.1 概述

数据库运行过程中使用的公共资源包含：系统资源（CPU、内存、网络等）和数据库共享资源(锁、计数等)。作业运行过程中总是希望获得更多的公共资源，以获得最好的执行性能。但是公共资源的滥用可能导致数据库系统的不稳定，引发资源过载，影响高优业务的QoS（服务质量），甚至阻塞业务运行。因此，合理地管理和分配系统资源，是保证数据库系统稳定高效运行的关键。

资源管理的目标：

防止资源过载，引发系统级故障；
实现高优业务的优先调度，保证高优业务QoS；
实现业务之间的资源隔离，防止业务之间资源争抢严重；
实现业务的错峰分时调度，防止瞬时高并发影响系统稳定性；
快速识别异常查询，保证正常业务稳定运行。

1.2 基本原理

资源池是一种用于对系统资源进行划分的技术，通过为资源池设置资源上限的方式，实现对其内运行作业的资源管控。资源池可以帮助系统管理员更好地管理和分配系统资源，提高系统的可用性和稳定性。

GaussDB(DWS)提供了资源管理功能，借助资源池实现业务之间的资源隔离和查询调度（不同业务路由至不同资源池）。GaussDB(DWS)支持两种路由策略：

用户-资源池：将用户关联至资源池，用户执行作业时，根据“用户-资源池”的关联关系，将作业路由至对应资源池执行。
query_band负载识别：业务设置query_band（USERSET参数），根据query_band和资源池关联关系，将作业路由至对应资源池执行。

实际应用过程中，建议优先使用用户-资源池的路由方式；在用户-资源池的路由方式无法满足隔离诉求时，使用query_band负载识别实现业务隔离。

1.3 能力介绍

GaussDB(DWS)支持负载管理、资源管控、异常规则、查询过滤器以及负载计划等资源管理能力，不同的资源管理能力有不同的使用场景，实际应用中可能会用到其中1~N个资源管理能力。

1.3.1 负载管理

支持基于并发和估算内存的查询调度，防止并发过大引发资源争抢严重、导致查询堆积。多CN场景下，CN之间互相不感知负载情况，因此无法精确控制整个集群的并发和内存使用，可能触发内存不足报错。因此为保证多CN场景下的并发和内存可控，设计实现CCN用于查询的统一调度。CM在第一次集群启动时，通过集群部署形式，选择编号最小的CN作为CCN，CCN故障之后，由CM选择新的CCN进行替换。

虽然CCN管控可以实现更为精准的管控，但是CCN管控逻辑更为复杂且涉及CN-CCN间通信，通信延迟（10ms~1s之间）和复杂的管控逻辑可能导致作业性能不稳定，此外CCN还可能成为提高系统并发的瓶颈。因此设计实现“短查询加速”功能，实现对简单查询和复杂查询的分别管控。复杂查询执行时间长、内存消耗大，CCN管控对其性能影响有限；简单查询执行时间短、内存消耗小，CN管控可以降低管控对其的性能影响。CCN管控的主要目的是防止内存不足报错，因此我们根据估算内存对查询进行分类：

简单查询：估算内存小于32MB；
复杂查询：估算内存大于等于32MB。

为提升简单查询性能，默认情况下简单查询只进行并发控制，而不进行内存和CPU管控。实际应用场景下，优先级低的业务可能性能不敏感，而且需要精准管控其使用的CPU和内存资源，此时简单查询也需要进行资源管控。为适应更多的使用场景，短查询加速功能支持开启和关闭：

开启短查询加速：简单查询在CN进行管控，复杂查询在CCN管控；
关闭短查询加速：不区分简单查询和复杂查询，所有查询均在CCN进行管控。

为了便于区分，我们将CN管控称为快车道，CCN管控称为慢车道。快车道只在CN上进行并发控制，不支持内存和CPU管控；慢车道在CCN上进行并发和内存控制，同时支持CPU管控。其中，快车道并发对应资源池max_dop参数，慢车道并发对应资源池active_statements参数，慢车道内存对应资源池mem_percent参数。

1.3.2 CPU资源管控

GaussDB(DWS)基于cgroups实现了两种CPU管控能力：基于cpu.shares的共享配额管控和基于cpuset的专属限额管控。

专属限额限制资源池内作业可以使用的CPU核，隔离更为彻底，用于防止低优作业占用过多CPU，影响高优作业性能。

共享配额仅在CPU繁忙时生效，不同资源池之间按照配额比例轮询占用CPU，不同业务之间存在CPU争抢，可能影响业务性能。

1.3.3 网络管控（821以上版本支持）

GaussDB(DWS)支持基于SP+DWRR算法的网络调度与基于令牌桶的网络流控，实现资源池之间按比例的网络调度的同时，实现了网络欠佳SQL的降级与流控。

1.3.4 空间管控（非本文重点）

空间管控主要有两层目的：一是防止磁盘满，一是对业务使用磁盘空间进行限制。GaussDB(DWS)支持以下空间管控能力：

数据库只读：CM每10分钟检测一次数据盘使用率，使用率超过阈值时，设置数据库只读；使用率低于阈值时，解除数据库只读。数据库只读情况下，只允许只读作业执行。数据库只读后，通过读写事务内执行DROP/TRUNCATE清理磁盘空间： " START TRANSACTION READ WRITE;DROP/TRUNCATE TABLE;COMMIT; "。

用户空间管控：限制用户在单个CN/DN上可以使用的空间上限，根据表的属主（owner）进行管控，而不管执行插入的用户是谁。相关语法：CREATE ALTER USER xxx PERM SPACE ‘xxx G/M/K’。

Schema空间管控：提供Schema级别的单实例空间管控能力，相关语法：CREATE/ALTER SCHEMA xxx WITH PERM SPACE 'xx G/M/K'。

1.3.5 异常规则

异常规则用于预防单个作业占用资源过多、执行时间过长，防止单个作业长时间大量占用资源，导致系统整体吞吐下降、影响其他作业性能。GaussDB(DWS)支持以下异常规则：

1.3.6 查询过滤器

GaussDB(DWS)查询过滤器提供查询过滤功能，对加入黑名单的作业进行过滤，禁止执行。主要应用场景包含以下两种：

异常熔断机制：配置异常规则后，作业频繁触发异常规则，对于触发异常规则次数达到阈值的查询自动加入黑名单进行过滤。
紧急拦截：作业引发CORE、hang或性能大幅下降等问题时，需要紧急规避时，可以将作业加入黑名单进行过滤。

1.3.7 资源管理计划

用户在不同时间需要重点保障的业务可能不一样，每个业务所需的并发和资源在不同时间段也可能不相同，因此用户在不同时间所需的资源管理配置可能就有所不同。资源管理计划支持在指定时间自动切换资源管理配置，用户可按需创建多个资源管理计划。创建资源管理计划、配置计划生效时间并启动计划后，GaussDB(DWS)将在计划生效时间自动切换资源配置。

1.4 能力边界（注意点）

首先，需要明确的一点是资源管理不是万能的，并不是所有的资源类问题资源管理都能解决，大部分资源不足类问题资源管理基本都解决不了。其次需要清楚资源管理有两个主要目的：其一是为了避免资源的无序使用，从而防止系统级故障的发生，同时避免查询堆积的情况出现；其二是为了实现业务之间的资源隔离，防止不同业务之间因为资源争抢而导致高优业务性能下降，从而影响高优业务的QoS。明确了以上几点，我们再来看资源管理能干什么、不能干什么，可能就更好理解了：

资源管理可以对业务并发进行限制，实现流量削峰。但是限制并发也就意味着吞吐量的下降，如果业务并发持续走高，限制并发可能导致业务运行不完，不限制并发又会影响其他业务，此时可能就需要考虑其他方法提升业务性能（扩容/升配/SQL优化）。
资源管理并不能提升系统整体吞吐量，相反，资源隔离很有可能降低系统整体吞吐。例如：应用资源管理前，CPU持续飙高在90%以上，查询堆积严重，业务运行不完。这种情况下对低优业务进行CPU限额隔离后，很有可能可以大幅降低CPU使用率；但是相应的低优业务可能大面积报错或无法完成。
资源管理可以实现资源隔离与管控，但是相较于无背景压力，隔离管控后业务性能可能还是有所损耗。例如：有些用户只对低优业务进行了CPU限额管控，而没有对高优业务进行CPU管控。此时高优业务和低优业务很可能使用相同CPU，此时CPU使用率可能不到100%、甚至不足90% 。但是相对无背景压力，同一时刻请求同一CPU的线程会更多，因此CPU调度时延也就越大。想要完成隔离CPU对性能的影响，需要对两个业务都进行CPU限额管控，但是进行限额管控后，相对无背景压力使用所有CPU性能可能也是有所下降的，此处不再展开。
资源管理并不能提升作业性能。有些用户业务并发大、资源需求高，但是系统资源却很少。业务串行可能都难以正常运行结束，此时想通过资源管理保障业务正常运行，基本是不可行的，最好的办法还是扩容/升配/SQL优化。

二、应用示例

2.1 确认业务场景

资源管理的目的是对业务进行隔离管控，因此设计资源管理方案前，首先需要确认用户业务场景：业务分类、业务优先级、业务类型、业务并发情况、业务执行时间段以及业务高峰时间段。

确认业务分类，才能确定应该划分几个资源池；
确认业务优先级，才能确定应该给哪个资源池多预留资源和并发；
确认业务并发和业务类型，才能确定是否需要进行并发控制和异常规则；
确认业务执行时间段，才能确认是否需要使用资源管理计划；
确认业务高峰时间段，才能确认预留多少资源和并发合适。

为了避免过多的资源池对整体吞吐率产生负面影响，同时为了简化资源管理方案，建议将资源池数量控制在5个以下，最好是3个及以下。如果业务分类较少（3个及以下），可以为每个业务分类创建一个资源池，以便更好地进行分类管理。如果业务分类较多，可以将优先级相同的业务归为同一类，并使用同一个资源池来管理。

业务优先级一般分为以下几类：

性能敏感的高优业务：该类业务一般执行时间短、业务并发不大，对性能非常敏感，一般不接受性能抖动；
无时效性要求的低优业务：该类业务对执行性能没有要求，一般只要能出结果就行，包括但不限于：外围应用查询、自助分析业务等；
其他有一定性能要求的业务：该类业务普遍并发较大、执行时间较长，对性能有一定要求，但是可以有性能抖动，比如：标准报告、实时入库等。

2. 2明确管控诉求

确认业务场景后，下一步就需要和用户明确管控诉求。第一步确认业务场景后，其实已经可以形成初步资源管理方案，比如：应该创建几个资源池、限制低优业务并发和资源使用（限额）、是否使用资源管理计划等。

示例：

业务场景：用户业务包含：入库、查询和外部接入。其中入库和查询使用同一用户(user1)，外部接入使用一个用户(user2)；入库优先级略低于查询且入库不能影响查询性能，外部接入优先级很低、接受报错和长时间不出结果；入库并发较大、消耗CPU较高。

对于以上业务场景，有以下基本诉求和初步资源管理方案：

有三类业务且优先级各不相同，且各业务间有隔离管控诉求，因此需要创建3个资源池；
所有业务全部使用自建资源池，资源池进行并发控制，因此单CN并发上限（max_active_statements）可以设置一个较大值（建议300/500）；
外部接入优先级低，因此考虑外部接入并发设置小一些，CPU核分配少一些，同时考虑到对其进行严格的CPU管控，因此关闭短查询加速；
入库和查询使用同一用户，因此需要用到query_band负载识别，用于区分入库和查询业务；
入库优先级略低于查询且入库不能大幅影响查询性能，因此考虑对入库和查询均进行CPU限额管控，同时关闭短查询加速；
查询估算内存可能存在偏差，当估算过大时可能导致异常排队，因此建议设置查询估算内存上限。

初步资源管理方案资源池配置如下：

单CN并发上限：max_active_statements = 300/500 ??

其中，参数值后有“??”的表示参数大小为初步预估，需要与用户沟通确认参数最终大小。

形成初步资源管理方案后，与用户针对资源管理方案进行讨论，确认管控诉求：

资源池：确认资源池数量是否合适，业务与资源池对应关系是否合适（可能存在多个业务对应一个资源池的情况）；
并发控制：各业务是否需要并发控制，并发上限是否合适；（资源管理上线前并发上限较难预估，一般前期会给一个比较大的值，后续上线后根据实际运行效果调整）
内存管控：业务是否需要内存管控，内存大小设置是否合理；（内存资源充足、业务间内存争取不严重的场景下不需要内存管控；内存设置过小，内存管控可能导致不必要的排队，影响系统吞吐）
查询估算内存限制：可以通过TopSQL历史记录中作业估算内存和实际使用内存判断是否合理；（估算内存上限设置过小可能影响作业性能，设置过大可能因为估算偏差导致异常排队，需要综合业务性能和内存使用情况考虑）
CPU管控：通过资源管理上线前，CPU使用率情况确认是否存在CPU瓶颈，同时确认后续是否有新业务上线；（存在CPU瓶颈或者后续可能上限大批新业务情况下建议提前配置好CPU管控，预防业务上线后大幅影响高优业务性能）
资源管理计划：业务高峰时间段不同的情况下，可能需要用到资源管理计划，在不同时间段重点保障不同业务；
其他管控诉求：确认用户是否有其他管控诉求，比如：设置异常规则，防止查询堆积和资源争抢严重（虽然进行了资源隔离，但是烂SQL可能影响本业务内其他作业）。

以上只是列举了常见的管控诉求讨论点，实际应用中可以多发散。

三. 配置资源管理

以上一章节中资源管理方案为例，说明如何配置资源管理方案。

3.1 配置资源池

如下图所示，以respool_select资源池为例，按照用户指南添加资源池中步骤添加资源池。名称填写“respool_select”；CPU资源选择专属限额，限额50%；内存资源限额50%；查询并发（特指慢车道并发）上限100。填写完成后点击确认，完成资源池添加。资源池操作说明详见：添加资源池、修改资源池、删除资源池。

添加资源池完成后，显示下图所示界面。刚刚配置完成的参数在资源配置标签内显示；短查询加速默认开启且不限制简单语句并发上限；中间位置显示资源池关联的异常规则，默认情况下关联有两个默认异常规则：单DN平均消耗CPU占比不超过50%，单DN算子下盘不超过数据盘的1/10，超过限制后作业报错退出；最下方显示资源池关联的用户，点击关联用户按钮将“查询用户”关联至该资源池。同理创建另外两个资源池，并将“外部接入用户”关联至respool_other资源池。

注：对于需要设置自定义异常规则的资源池，在下方异常规则标签栏点击编辑即可配置异常规则。

3.2 短查询加速配置

在资源池下拉列表中选择刚刚添加的资源池respool_select，点击短查询配置右上方的编辑，修改简单语句并发为150，修改完成后点击保存。

对于另外两个资源池，需要关闭短查询加速，在资源池下拉列表中选择对应资源池后，点击短查询配置中“短查询加速”开关，关闭短查询加速。

3.3 查询估算内存设置

查询估算内存上限暂时还不支持在界面配置，可以通过DAS执行SQL直接修改：

3.4 配置query_band

1. 修改用户入库业务，入库业务会话内设置query_band：SET query_band='Jobname=upsert';--执行业务;--作业执行完重置query_band：reset query_band;示例：

postgres=> SET query_band='Jobname=copy_upsert';

SET

postgres=> INSERT INTO t1 SELECT generate_series(1,10000);

INSERT 0 10000

postgres=> RESET query_band;

RESET

2. 配置query_band，将入库业务路由至资源池respool_upsert运行：

postgres=# SELECT * FROM gs_wlm_set_queryband_action('Jobname=copy_upsert', 'respool=respool_upsert');

gs_wlm_set_queryband_action

-----------------------------

t

(1 row)

3. 查询pg_queryband_action视图，确认query_band配置成功：

postgres=# select * from pg_queryband_action;

qband | respool_id | respool | priority | qborder

---------------------+------------+----------------+----------+---------

Jobname=copy_upsert | 2147483648 | respool_upsert | medium | -1

(1 row)复制

4. 运行入库作业过程中，查询TopSQL实时视图，确认query_band是否生效

postgres=# SELECT username, query_band, resource_pool, substr(query, 1, 30) FROM pgxc_wlm_session_statistics WHERE query_band IS NOT NULL;

username | query_band | resource_pool | substr

----------+---------------------+----------------+--------------------------------

user_elk | Jobname=copy_upsert | respool_upsert | INSERT INTO t1 SELECT generate

(1 row)

3.5 其他配置

1. 需要使用资源管理计划的，可以参考资源管理计划操作配置资源管理计划。

2. GaussDB(DWS) 8.2.1及以上版本支持网络资源管控，假设三个资源池网络带宽权重配比为respool_select:respool_upsert:respool_other = 5:4:1，使用DAS执行以下SQL配置网络管控：

ALTER RESOURCE POOL respool_select WITH(WEIGHT=5);

ALTER RESOURCE POOL respool_upsert WITH(WEIGHT=4);

ALTER RESOURCE POOL respool_other WITH(WEIGHT=1);

配置示例参见下图：

假设外部接入业务运行超过20min，且网络带宽占用超过128MB降级：

CREATE EXCEPT RULE bandwidth_rule1 WITH(bandwidth=128, ELAPSEDTIME=1200, action='penalty'); -- 创建异常规则

ALTER RESOURCE POOL respool_other WITH(EXCEPT_RULE='bandwidth_rule1'); -- 将异常规则关联至资源池respool_other