玩转GaussDB(DWS)资源负载管理系列 -- 这么多资源和参数，该怎么配置配多少合适？

GaussDB(DWS)具备强大的资源管理能力，针对存储空间、CPU、内存、以及每个租户/用户的并发等资源，都可以进行控制调配。但是实际上的使用经常会因为配置相对复杂，让很多人望而却步，不去使用功能，造成资源的争抢或者浪费。

本文主要作为一个普及以及配置指导，针对各项功能规格做一个介绍，并针对某些场景给出一个合理的配置推荐方案，以便大家可以使用GaussDB(DWS)的负载管理功能，使集群的资源得到合理的利用，让集群平稳运行。

文章分为以下几个部分进行说明介绍：

一、当前规格梳理（线下FIM版本，以8.0版本为标准；线上HCS版本）

二、针对代表性场景配置举例说明

• 目前各个功能规格说明梳理

1. 线下版本介绍（PS:本次主要线下版本的功能，线上版本目前使用较少，同线下有一些变化，会继续补充）。

- 关于并发控制

1.功能作用：

控制全局每个cn上的活跃语句最大数量；控制用户级别的活跃语句最大数量；该功能作用主要为控制集群负载不要过大，使用过程中可以根据不同的场景配置不同的数值，使集群能在资源可容忍的负载下运行，避免负载过大导致资源争抢等情况。

1. 规格说明：

GaussDB(DWS)支持全局的并发控制，以及租户级别的并发控制。所有语句的执行流程，会先走到全局并发控制的入口之后，符合了全局并发控制的下发条件，即最大并发数量没有达到max_active_statements的限制，之后会继续走到局部租户级别管控，租户上会区分简单作业和复杂作业（短查询、长查询），采取不同的机制进行控制。

• 全局并发控制：所谓全局并发管控，其实指的是单个cn的并发数量控制，通过设置参数max_active_statements的值可以实现，举例：设置该参数为10，有3个cn，那么负载均衡的情况下，整个集群可以有3*10=30个并发。（不区分简单复杂作业）
• 局部并发控制：所谓局部也就是租户级别的控制，在实际的逻辑中，其实是相当于设置一个资源池，对该资源池进行各种资源划分，一个资源池上只有一定的资源（内存、io、并发），之后将用户放到这个池子中，那么这个用户就只能享有该资源池中的资源。作业分为简单作业和复杂作业，区分方法等详细介绍可以参照：GaussDB(DWS)负载管理简介

复杂作业的管控大概原理举个例子：比如这个资源池（子租户或者说队列）配置了5G内存，该子租户下的用户已经跑了2个语句，每个用2G内存，再来一个需要2G的语句到了资源池一看，内存不足了，就排队等待资源。以这样的控制方式来控制用户上的并发数量。

简单作业则通过资源池上的参数max_dop来配置，这个参数的意义是该资源池在每个cn上可以运行多少简单作业。

1. 配置方法：

复杂作业的控制，前台通过配置子租户所使用的内存来控制复杂作业并发，如果将内存设置为0的情况下，会由并发数量生效管控复杂作业的并发。

简单作业的控制，由后台配置资源池参数max_dop进行控制。

连接数据库后执行：alter resource pool respoolname with(max_dop=10);

       即可达到控制该资源池用户在每个cn只能并发运行10个简单作业的效果。

- 关于磁盘空间的控制

1.功能作用：

如果磁盘空间经常处于高水位，70%+，随时可能因为数据倾斜或者是大量数据导入达到90%，就会造成集群只读，业务中断。因此对于经常性使用率较高的集群，有必要对于用户所使用的磁盘空间进行管理，避免因为一些异常使用影响业务。

2.规格说明：

当前版本的磁盘空间控制，支持进行用户级别的三种类型的磁盘空间控制：永久表空间控制、临时表空间控制、算子落盘空间控制。

• 永久表空间：即用户的普通表使用的存储空间大小。
• 临时表空间：即用户一个session中使用临时表之后，可以允许临时表使用的最大空间。
• 算子落盘空间：当算子使用的内存超过了work_mem的限制，会导致下盘，下盘不仅仅会导致计算的性能大幅度下降，还会导致磁盘空间使用率的上升，也可能导致集群只读。

1. 配置方法：

本功能支持界面配置，也支持后台内核直接配置。

界面配置为租户级配置，点击子租户资源界面编辑修改即可；

后台配置语法如下：

CREATE USER tenant_space_test WITH PASSWORD 'Gauss_234' PERM SPACE '100G' TEMP SPACE '50G' SPILL SPACE '100G';

ALTER USER tenant_space_test PERM SPACE 'unlimited';

- 关于租户/用户内存控制

1.功能作用：语句的使用内存不太可控，有的语句使用的内存很小，有的语句使用的内存很大，就我个人来看，有存在一个语句会把内存吃满的情况，估算内存可以达到将近90G，会将其余所有语句都阻塞，或者会导致动态内存使用耗尽，导致业务出现内存不可用的报错。

2.规格说明：

目前对于内存的控制功能主要有以下两种机制：

• 动态内存自适应机制（PS：show enable_dynamic_workload；为on则该功能开启，5.1版本之后默认开启，该功能无需配置）。

该功能打开的情况下，会自动对于全局内存进行把控，根据当前全集群各个dn的可用内存情况，判断是否可以让客户端发来的语句继续下发。举个例子，全局可用内存汇聚到ccn上，比如当前总共20G，使用了18G，剩余2G，这时来一个优化器估算内存为5G的语句，就不能让他继续执行，这个语句就会等待其他语句执行完，释放内存，到了空闲内存大于5G时候让他执行。等待期间的状态为wait in ccn queue。

此机制配置方案：可以直接打开enable_dynamic_workload参数，配置为on，需要重启集群生效。

• 租户级内存管控机制（相当于对于整个资源池控制内存，比如该内存可以是总体内存的50%）

这个机制相当于通过内存自适应之后的下一层管控，走过了上述的内存自适应这部分之后，会走到此机制进行下一步控制。该部分简单说明如下：

GaussB(DWS)的内存分为以下几种：

主要关注图中的红框部分，max_process_memory为可配置的进程最大使用内存，max_dynamic_memory为从max_process_memory中，扣除掉cstore buffer/shared buffer等用户行列存文件扫描的内存外，剩余的用于进行sql计算的内存。

内存管控的机制，即以max_dynamic_memory作为全部内存，将其保留一部分之后进行分配，分配到各个租户下，限制每个租户能使用的内存。支持两层分配，举个例子：总体为20G，父租户分配60%，子租户再分配父租户的50%，那么该子租户可以使用的内存为20*0.6*0.5 = 6G。

所有属于该子租户的业务用户共享6G内存。当该子租户下用户所使用的内存达到6G时，就会出现语句在资源池排队的情况，此时语句的状态为：wait in resource pool。

同样，等资源池上的内存释放之后，排队的语句可以继续往下执行。

3． 配置方法：

         界面配置：1）先创建父租户，选择父租户内存分配占比；2）创建子租户，选择子租户内存分配占比；3）关联用户到子租户。

后台配置：1）创建父控制组；2）创建子控制组；3）创建父资源池；4）创建业务资源池指定上一步父资源池；5）关联用户到子资源池。

- 关于CPU的限制

1. 功能作用：控制一个子租户能使用的CPU配额或者限额，保证集群在CPU高负载情况下也能保证业务能获取到CPU资源以及在有的用户可能出现异常会突然占用太多CPU的情况下，也可以对其进行限制，保证其他用户的使用。
2. 规格说明：GaussDB(DWS)支持两种CPU管控，配额以及限额，配额代表软限制，给一个用户配置20%配额的CPU，在整体机器空闲的情况下，该用户可以使用超过20%的CPU，相当于可以给资源一个合理利用；限额代表硬限制，给一个用户配置20%配额的CPU，在任何情况下，该用户都不能使用超过20%的CPU。
3. 配置方法（限额的配置1版本界面不支持，只能后台配置限额）：

界面创建父子租户时即可选取相应配额以及限额；1）先创建父租户，选择父租户CPU占比；2）创建子租户，选择子租户CPU配额/限额占比；3）关联用户到子租户。

后台配置：1）创建父控制组；2）创建子控制组；3）创建父资源池；4）创建业务资源池指定上一步父资源池；5）关联用户到子资源池。

二、配置场景举例：

    场景A：业务用户分为跑批业务和灵活查询业务，分别使用不同的用户下发业务，例如：userA用户运行跑批业务，userB运行灵活查询业务。

参考配置：给userA分配资源：85%内存配置；80%CPU限额；磁盘空间根据实际使用情况分配；给userB分配资源：15%内存配置；20%CPU配额；简单作业并发数max_dop设置为10，磁盘空间根据实际使用情况分配；

解释说明：A用户跑批会使用大量的资源，因此分配资源较多，充分利用资源提升跑批效率；B用户灵活查询大多都是简单作业，基本不需要资源限制，并且在DWS管控机制中，简单作业也不会走资源控制的逻辑，只走并发控制的逻辑。

场景B：用户A属于重要业务，要保证连接，用户B属于准实时业务，随时会连接到数据库进行一些查询，会发起大量的连接。

参考配置：全局cn上的总并发控制：max_active_statements设置为一个很大的值例如600；配置两个租户，在租户级别分别限制A和B的并发数量。A租户内存配置放大，参考值80%左右，理由与上述场景A一致；B租户设置max_dop限制并发数量，这样保证了B的并发受到控制的情况下，A也可以正常连接。

    解释说明：max_active_statements是共享资源，所有用户的语句连接都会经过这一层的过滤，因此这个值如果设置很小，会出现一个会产生大量连接的用户将所有并发都吃满，导致其余用户的语句很容易处于一个排队状态，看起来就像是连不上一样；因此想要管控一部分用户的并发时，最好直接在租户层进行控制，通过全局控制会影响到其余用户。