背景

技术架构

我们先来看下细粒度资源管控的技术架构和运行原理：

从上图中可以看到，GaussDB提供资源池模块来完成CPU、内存与IO的管控逻辑。用户可以创建一个资源池并指定其可以使用的CPU、内存与IO的份额，并把资源池与用户绑定。之后该用户发起的作业在数据库内核优化解析、执行引擎以及存储引擎模块运行的过程中都会受到实时资源管控，确保其CPU、内存与IO都在对应资源池的范围内。

 

假设A公司部署了一套GaussDB实例，其同时存在三个不同的应用来访问该实例，如OLTP业务、报表业务、其他低优先级业务。A公司希望对三个业务做资源的合理管控，在保证资源使用最大化的情况下，系统平稳运行。我们可以使用系统管理员执行如下命令来为三个业务的用户设置，其资源份额比例为50:30:10，剩余的10%为系统预留。

 

这里仅做简单的使用示例，每一个参数的具体含义会在后面的章节进行详细说明。

 

create resource pool respool_tp with(control_group="cgroup_tp", max_dynamic_memory="5GB", max_shared_memory="5GB", io_limits=50, io_priority="High");
alter role tp_user RESOURCE POOL 'respool_tp';

create resource pool respool_report with(control_group="cgroup_report", max_dynamic_memory="3GB", max_shared_memory="3GB", io_limits=30, io_priority="Medium");
alter role report_user RESOURCE POOL 'respool_report';

create resource pool respool_other with(control_group="cgroup_other", max_dynamic_memory="1GB", max_shared_memory="1GB", io_limits=10, io_priority="Low");
alter role other_user RESOURCE POOL 'respool_other';

如上操作后，OLTP业务、报表业务与其他低优先级业务分别使用tp_user、report_user与other_user连入GaussDB执行作业时，这三个业务则会受到对应的资源池respool_tp、respool_report与respool_other的管控，在资源发生争抢的时候保证三个业务分别可以使用GaussDB集群50%、30%以及10%的资源。

关键能力

在了解了细粒度资源管控的整体架构和使用方法之后，我们再来看看它具备哪些关键能力，这些能力可以为客户带来什么样的业务价值。

GaussDB的CPU管控是以资源池粒度来做用户资源管控的，每一个资源池绑定一个控制组，通过控制组（Control Group，CGroup）来实现CPU的管控。CGroup是Linux内核提供的一种限制、记录、隔离进程组所使用的物理资源（如CPU、Memory、IO等）的机制。

 

考虑到数据库系统、用户、作业不同维度的隔离性和可配置性，GaussDB使用控制组的层级特性构造符合数据库场景的模型（见下图），其满足客户SLA的关键特性，并支持三个维度的层次隔离和控制：数据库程序与非数据库程序隔离、数据库常驻后备线程与执行作业线程隔离以及数据库多用户之间的隔离。

GaussDB控制组可以设置CPU的百分比以及核数的上限，其中根节点负责管控GaussDB进程可用的CPU份额；Backend控制组负责管控数据库常驻后台线程的CPU份额(Vacuum、DefaultBackend)；Class控制组负责管控用户的作业线程的CPU份额(UserClass1,UserClass2,...UserClassN)；Class控制组内还可以创建Workload控制组(TopWD,RemainWD...)进行更细粒度的管控。

 

接上面的示例，我们用GaussDB提供的CGroup工具来为A公司的OLTP业务、报表业务以及其他低优先级业务分别创建控制组，CPU分配比例为50%、30%与10%。

 

gs_cgroup -c -S cgroup_tp -s 50;
gs_cgroup -c -S cgroup_report -s 30;
gs_cgroup -c -S cgroup_other -s 10;

执行如上命令就代表我们成功创建了3个控制组，之后可以在创建资源池时指定该控制组名称。绑定资源池的用户所发起的作业就会收到控制组对应CPU份额的管控。

 

CGroup管控CPU有两个问题需要注意：

 

 

基于这些问题GaussDB提出了线程组的概念，每一个资源池对应一个线程组，线程组里的线程都绑定了该资源池所对应的CGroup。同时，GaussDB会将每一个线程组的线程数量调整到与对应CGroup的CPU份额一致。具体可见下图：

每一个用户发起的作业都会被分发到对应的线程组里的线程来执行，由于线程已经绑定了对应的Cgroup节点，所以操作系统会在线程调度时完成CPU管控。

 

GaussDB提供两层用户机制，绑定Class控制组的资源池称之为组资源池，对应的用户为组用户，绑定Workload控制组的资源池称之为业务资源池，对应的用户为业务用户。组用户一般对应一个部门，而业务用户对应这个部门的不同的业务。业务资源池的各个资源维度的资源份额会不会超过所属组资源池的份额，从而达到两级资源管控的目标。

 

CPU管控也提供名称为session_respool的GUC来限制单个会话的CPU不超过对应资源池的CPU上限。

GaussDB提供动态内存与共享缓存的管控，创建资源池时可以指定max_dynamic_memory与max_shared_memory来分别完成动态内存与共享缓存的阈值设置。

 

动态内存管控并没有更改其原有的内存资源分配机制，仅在分配内存之前增加一个逻辑判断层，对多分配出的内存进行记账，通过检查该记账值是否达到允许使用的内存上限来完成内存的管控。当动态内存超过上限时，作业申请内存会失败。作业退出时，该作业已申请的内存会进行释放来保证其他作业可以正常执行。同理，当作业使用的共享缓存超过资源池的管控上限时，再次申请共享缓存，需要先释放自己已经占用的共享缓存，比如BufferPool，作业申请页面时，会对自己已经占用的页面进行淘汰，淘汰之后空余出来的页面供自己继续使用。

 

GaussDB除了用户粒度的内存管控外，也提供session_max_dynamic_memory与query_max_mem两个GUC参数来完成会话级与语句级动态内存的管控，当一个会话或者语句所使用的动态内存达到GUC的阈值时，作业申请内存失败。

GaussDB的磁盘读写IO都由后台线程完成，该线程无法区分页面属主，只是按照时间顺序依次落盘，无法针对不同用户管控不同的IO使用。基于此，考虑IO管控功能采用逻辑IO统计方式，对用户或者会话的读写IO进行管控限制，在工作线程和共享缓存之间增加了逻辑IO计数，对于行存表来说每6000（可通过io_control_unit GUC进行修改）行算做一次IO，当一秒产生的读写IO请求数超过资源池设置的阈值时，则将该IO请求加入到后台线程的一个等待队列里，后台线程将对等待队列里的这些IO请求进行监控，当其等待时间符合条件时，将这些IO请求从等待队列中唤醒。

 

GaussDB支持两种模式的IO资源管控，上线数值模式是通过设置固定的触发IO次数的数值，进行IO资源控制；优先级模式是指在当前磁盘长时间使用率达到95%以上，所有作业都无法达到上线数值模式时，用户可通过该模式进行IO控制，控制该作业原本触发IO的优先级比例，优先级包含三挡：High、Medium与Low。

 

接上面的示例，我们为A公司的OLTP业务、报表业务以及其他低优先级业务分别创建资源池，IO权重分别设置的为High、Medium与Low。那么，OLTP业务能使用50%的IO请求向BufferPool中读取或写入数据，少量的IO请求会进入等待队列等待；报表业务能使用20%的IO请求向BufferPool中读取或写入数据，较多的IO请求会进入等待队列等待；其他低优先级业务能使用10%的IO请求向BufferPool中读取或写入数据，较多的IO请求会进入等待队列等待；后台监控线程会周期性的遍历IO等待队列，唤醒等待时间符合要求的IO请求从BufferPool读取或写入数据。

 

GaussDB除了支持用户粒度的IO管控外，也支持通过设置会话级GUC参数io_limits与io_priority，来完成指定会话上允许作业的IO管控。

GaussDB提供基于资源池的连接数管控与并发管控，创建资源池时可以指定max_connections与max_concurrency来分别完成连接数与并发数的设置，可以使用如下SQL，为前面示例A公司的三个业务对应的资源池完成连接数与并发数管控:

 

alter resource pool respool_tp with(max_connections=-1, max_concurrency = -1);
alter resource pool respool_report with(max_connections=200, max_concurrency = 100);
alter resource pool respool_other with(max_connections=100, max_concurrency = 50);

如上SQL执行成功后，实时生效。A公司OLTP业务的连接数与并发数不受限制，只有集群有资源它都可以使用到；报表业务的最大连接数为200，其他低优先级业务的最大连接数为100，当这两个业务建立的连接数超过该值时，GaussDB内核会自动拦截，报当前连接数不足，链接失败；报表业务的最大并发数为100，其他低优先级业务的最大并发数为50，当这两个业务同时发起的作业数超过该值时，超出的作业将会进入等待队列，直到已有的作业完成之后GaussDB才会将其唤醒继续执行作业。

存储空间管控，用于限定不同用户可以使用的空间配额，防止单用户存储空间使用过大导致整个数据库业务受阻。GaussDB通过在创建用户时指定存储空间的大小来实现对存储资源的管控。

 

存储空间资源分为三种类型：永久表空间（Perm Space）、临时表空间（Temp Space）与算子下盘空间（Spill Space）。

 

可以使用如下SQL，为前面示例A公司的三个业务对应的用户完成磁盘空间额管控。

 

alter user tp_user PERM SPACE '200G' TEMP SPACE '20G' SPILL SPACE '20G';
alter user report_user PERM SPACE '100G' TEMP SPACE '10G' SPILL SPACE '10G';
alter user other_user PERM SPACE '100G' TEMP SPACE '10G' SPILL SPACE '10G';

 

存储空间管理支持对组用户和业务用户的存储空间管理。当业务用户对应的组用户存在空间限制时，业务用户的空间也受到该组用户的空间限制。指定存储空间的大小后，该用户在DN上所有的写操作会增加用户已用空间，删除操作减少用户已用空间，CN会周期性的从DN获取一次已用空间总和，并对用户已用空间进行判断，超过最大值后cancel掉写作业（insert/create table as/copy），后面写作业报错退出。

特性演示这里我们就简单的为大家演示一下CPU的管控效果，因为对业务影响最大的就是CPU。

 

创建两个资源池分别设置20%与60%的CPU，然后使用两个绑定了该资源池的用户开始跑业务。观测CPU的实际使用情况。

CREATE RESOURCE POOL xuuer_pool with(control_group = "class1");
CREATE RESOURCE POOL xyuser1_pool with(control_group = "class2");

create role user1 RESOURCE POOL 'xuuer_pool';
create role user2 RESOURCE POOL 'xyuser1_pool';

4. 通过Top观察系统CPU状态，同时细粒度资源管控提供gs_wlm_respool_cpu_info函数来观察各个资源池的CPU实时情况。

如上图，可知初期系统CPU是空闲状态，资源池的CPU监控视图也显示CPU使用为0。让user1开始跑业务，观测可知系统CPU有一定业务占用，查询资源池的CPU监控视图显示，user1可以使用80%的CPU。此时，让user2也开始跑业务，观测可知系统CPU进入繁忙状态，查询资源池的CPU资源监控的系统函数可知user1的CPU使用率开始下降，user2的CPU使用率开始上升。

总结

细粒度资源管控特性目前支持集中式与分布式。分布式下的计算资源管控是各个节点独立管控自己节点的资源，存储资源管控是以集群维度来整体管控的。