GaussDB(DWS)应用实践丨负载管理与做业排队处理方法

摘要：本文用来总结一些GaussDB(DWS)在实际应用过程当中，可能出现的各类做业排队的状况，以及出现排队时，咱们应该怎么去判断是否正常，调整一些参数，让资源分配与负载管理更符合当前的业务；或者在做业阻塞的时候，怎么去处理这些状况，让业务马上恢复正常。

概述

数据库系统的负载管理和资源管理，在整个系统中起着很重要的做用，好比不少用户的业务压力过大时，有时会致使链接数量被占满，有时会致使某种计算资源被占满，有时会致使存储空间被占满，这些状况都会致使整个集群进入异常甚至不可用的状态：正在执行的做业互相争抢CPU，会致使你们都不能好好执行；大量做业执行时，占用大量内存，很容易触发到内存瓶颈，形成做业内存不可用问题，致使业务报错等等。在不进行并发控制的状况下，这些状况都极可能会出现，影响到正常业务。

本文用来总结一些GaussDB(DWS)在实际应用过程当中，可能出现的各类做业排队的状况，以及出现排队时，咱们应该怎么去判断是否正常，调整一些参数，让资源分配与负载管理更符合当前的业务；或者在做业阻塞的时候，怎么去处理这些状况，让业务马上恢复正常。

本文分为如下几个小节去介绍并解答以上问题：

• 1、负载管理简介：双层排队简述
• 2、经常使用视图以及使用方法介绍
• 3、负载管理常见问题以及处理
• 4、部分负载管理配置方案介绍
• 5、小结

1、负载管理简介：双层并发控制简述

DWS的负载管理分为两层，第一层为cn的全局并发控制，第二层为资源池级别的并发控制。在经过第一层控制的时候，会继续向前走到第二层资源池控制，根据资源池当前的负载资源状况决定做业继续执行或者排队。

DWS并发控制逻辑示意图以下：

从本图的逻辑咱们能够看到，实际做业执行中，可能会在两种队列中排队：

一种是全局队列（global queue），这种队列不区分简单和复杂做业，也不区分是DDL或者是普通语句，

一种是资源池队列(resource pool queue),用户下发的通常语句会根据资源消耗估算以及复杂程度在这里进行判断是否排队。

在两层队列的过滤下，DWS会筛选出当前能执行的语句，使其正常运行，运行时也会受到其所属资源池资源的限制（只能使用资源池配置的CPU、内存、IO配额）。

2、经常使用视图以及使用方法介绍

这里介绍几个经常使用视图以及SQL语句，能够迅速判断目前的业务出现问题的缘由，受限根据如下视图能够看到目前的做业是否是在排队，以后要迅速分析为何在排队，是由于负载管理各个参数配置问题，仍是由于正在执行的语句占据了过多的资源致使的排队。

• pgxc_stat_activity(pg_stat_activity)

经常使用语句：

#查询当前执行时间最长的语句的排队状态，query_id(数据库中做业的惟一标识)，以及详细的语句信息。
select coorname,usename, current_timestamp-query_start as duration, enqueue,query_id,query from pgxc_stat_activity where state='active' and usename <> 'Ruby' order by duration desc;

根据该语句能够迅速判断出哪些语句执行时间很长，是什么样的语句执行很慢以及该语句的query_id，便于迅速进入下一步排查。

执行结果以下：

上图解说：图中为在没有做业的状况下查询，能够看到有几个WLM的语句已经执行了不少，不过这两个是内部常驻线程，因此不影响业务，也不会占用链接数等数据库资源。

其他的行能够看到有bi用户，在执行一些做业，时间大概1-6分钟左右。

• pg_session_wlmstat (记录每一个cn的语句执行状况，资源使用状况，排队状况等信息)

经常使用语句：

#查询每一个用户下的做业执行状况，排队状况以及做业的复杂状况和内存消耗状况。
select usename,enqueue,datname,status,attribute,count(*),sum(statement_mem) from pg_session_wlmstat group by 3,1,2,4,5 order by 1,3,4,5 ;

执行结果以下：

上图解说：

上图中说明当前链接的cn中有用户名为usr1的用户执行做业，而且在资源池上排队（第一节介绍的resourcepool队列），数据库为postgres，做业在排队因此当前status为pending状态。

其余字段包括做业的属性和当前使用内存资源的总和状况（根据该数值能够看出是否由于内存资源不足而进入排队状态）。做业在排队时候不涉及到资源消耗，所以可能没有具体数值。

• pgxc_thread_wait_status（查看数据库中各个线程的执行状况，当前在等待哪一步骤执行完成，在哪一个实例等待，均可以经过该视图查询）;

经常使用语句：

#在根据pgxc_stat_activity查询到具体执行时间长的语句以后，能够根据本视图查询：
select * from pgxc_thread_wait_status where query_id = xxxxxxxx;

该语句能够查看执行慢语句的阻塞点，语句卡住时，能够经过该语句查看语句卡在了哪一个步骤。

举例以下：

上图能够看到做业在wait io，此时能够检查下磁盘的读写速度是否，raid卡读写策略是否正常等等。

当出现排队的时候，wait_status通常的状态是waiting in ccn queue/waiting resourcepool queue等状态。

• 查询并发数量的方法，就是查看pgxc_stat_activity中，状态（state字段）是active的语句，enqueue字段为null的语句，除此以外，idle in transaction之类状态的语句，也会占用一个并发数量，由于一个事务块的业务还未提交，天然也算是正在执行的业务，对于这种状况，后续能够考虑进行一个处于此类状态的超时时间的控制。

3、负载管理常见问题

通常当业务上发现任务阻塞时，能够从后台查询部分语句排查目前的状况，此时要先看下现象上是什么状况，通常并发控制有如下几种现象，暂时先列出这么多，后续继续补充：

1. 业务反馈没法链接到数据库，好比DS链接一直转圈，过一段时间以后会超时报错。

• 此时能够开始排查当前的配置状况，通常链接不到数据库，实际上是一种表象，主要是由于做业已经进入了排队的状态，语句自己就有不少在排队，没法执行，此时用ds链接以后，ds自己就会下发语句查询一些系统表之类的信息，因此也会进入排队的状态，在客户层面的影响就是ds一直处于一个链接中的状态，其实是ds的链接在数据库中。
• 查询参数配置，看当前每一个cn能够接受的最大并发数量是多少：

1. show max_active_statements;

若是当前cn的活跃做业超过这个参数，会出现语句排队的状况，主要排队状况为waiting in global queue，以下图所示，下图状况中，max_active_statements=6。

1. 查看业务链接是否主要只链接一个cn，能够一样经过查询pgxc_stat_activity判断coorname，查看是否大量的语句都是集中在某一个cn上执行，当语句下发集中在某个cn上时，这个cn的并发数量也只是max_active_statements设置的大小，举个例子：若是业务链接3个cn，每一个cn的max_active_statements设置都是10，那么最大能够同时运行30个做业；若是这30个做业都下发到一个cn上，那么就有20个排队，同时只能执行10个，会大大影响执行效率，同时也会形成这种看似没法链接到该cn的现象。

• 解决方法：

1. 业务负载不均：配置LVS，均衡业务，避免负载不均致使的排队。
2. max_active_statements参数设置太小：在资源负载容许的状况下继续调大，若是资源达到瓶颈，继续放大可能会致使资源争抢，效果不大。
3. 链接被空闲事务占用：如上图中状况，能够看到有不少链接的状态都是idle in transaction，这种状态处于事务块完成可是没有提交，也会占用一个并发，致使其他做业并发量减少，致使排队。此类状况须要排查业务应用的执行状况，整改业务，避免处于这种空闲还占用并发的状况。严重阻塞业务的状况，紧急处理能够将该类语句直接terminate掉。
4. 确实已经有不少做业在执行，资源使用也已经达到一个瓶颈，这时候就须要去扩容或者下降业务量，来避免这种状况出现。

2. 做业长时间执行不出来，而且有不少做业在排队，总体业务受到阻塞。

• 此类状况能够继续使用上述查询pgxc_stat_activity的语句，查看语句的运行状况，结果可能以下：

如图：图中最下方的两个做业，执行时间已经达到了11小时，可是仍然没有执行完，后面还有未执行的语句在排队。总体对于客户来讲就是数据库已经hang死了，什么做业都执行不出来。

排查步骤

• 排查当前集群是否在使用动态自适应功能，查看以下参数：

show enable_dynamic_workload; //查看该参数目前是否为打开状态（2020年的版本都是默认打开）

• 若是该参数打开，那么就要查看这几个正在运行做业目前的内存使用状况，大几率正是由于这几个做业一直使用着内存不释放，才会出现总体的排队状况。

经过链接cn 5001查询视图：

select * from pg_session_wlmstat where threadid = $query_id;

该视图能够看到某个语句使用了多大的内存，statement_mem字段能够看到我这个语句是使用了1G，可是实际状况中，1个语句使用几十个语句的状况不少。当一个或者几个语句的内存达到整个集群的整体可用内存上限，或者达到资源池上限的时候，就会使这些语句后面的语句开始排队。资源不放，排队不止。

• 处理方法

应急处理：及时将卡住的语句terminate，释放其占用的资源，后续进行优化以后再执行，优化手段不少，包括计划调优，analyze等操做，均可以免一个语句占用太大内存，也能够提高执行效率。

3. 全局资源可用内存不少，资源使用很小，并发数量也没有达到上限，可是查询显示不少做业处于排队状态。

举例：查询pgxc_stat_activity时，语句的执行状态以下：能够看到，全部语句都在waiting in ccn queue，只有两个语句在运行。此时集群设置的max_active_statements是40，可是该用户实际活跃数量只有2个。

举例：查询pgxc_stat_activity时，语句的执行状态以下：能够看到，全部语句都在waiting in ccn queue，只有两个语句在运行。此时集群设置的max_active_statements是40，可是该用户实际活跃数量只有2个。

• 首先，出现出现waiting in ccn queue的状况，就必定是开启了内存自适应功能(enable_dynamic_workload=on)。此时只有两种状况，第一种是全局资源不足，会排队，第二种是用户所属的资源池内存不足，也会排队。
• 根据图中的现象，咱们看到不少语句都在排队，这时候要查询一个排队视图：select * from pg_stat_get_workload_struct_info();

这个视图能够清晰看到做业是在哪里排队：

首先，上图中有totalsize，这个就是整体可用的最大内存，freesize_limit:执行语句可用的最大内存，freesize:当前可用的最大内存。

因此能够得出结论，此时不是在全局排队，全局内存freesize足够，那么做业就是在资源池排队，资源池排队也会显示waiting in ccn queue。

• 此时查询pg_session_wlmstat视图，能够看到正在运行的为dw用户，正在运行的语句占用的内存为两条各1G。

能够经过界面或者后台查看一下，这个用户对应的租户上，是否是作了内存资源限制：

查看租户界面内存配置以下：

能够看到图中给这个租户或者说给这个用户所在的资源池配置了10%的内存配额，一共是2277MB，即2G左右。

所以这种场景下，内存资源只能知足当前两个语句的执行，其他属于该用户的语句都会进行排队。

• 处理办法：
• 方法1、此类问题，若在资源容许的状况下，能够适当调大租户相关的内存资源，让更多语句可以同时运行。
• 方法2、优化相关语句的执行效率，缩短执行时间，让语句能够高效执行，避免大量堆积。

4.执行的做业基本都是一个用户的，其他用户的做业基本都在排队中没法执行。

举例：以前某局点出现高并发DDL的状况，该类高并发DDL在全局并发计数中会受到统计，占用max_active_statements中的并发数量。

好比：max_active_statements=20，其中某用户一直持续不停地下发DDL，此时在DWS设计ap场景并未涉及此类场景。会出现该20个并发设置广泛被该用户占用的状况，其余用户可能出现连不上的状况。

这种场景下，即时再调大并发，也会再被该用户的DDL语句占用。

处理方案：

针对高并发DDL的不合理业务场景进行优化，好比把连续建立删除临时表的动做，改成对永久表的操做，此时就能够极大幅度减小DDL并发数量，保证自身业务以及其他用户业务的正常链接和运行。

4、部分场景配置方案

1. 限制单用户并发

用户的做业分为如下几种，DDL/DML/以及常规查询，在DWS的视角中，常规查询有分为简单查询和复杂查询。

对于DWS的两层管控，受到第一层管控的有DDL、start transaction、DML、常规查询等，基本是全部语句，只有内部线程的语句（好比WLM线程）以及超级用户权限的用户执行的做业。

受到第二层管控的语句，主要是能够从优化器获取到具体执行计划以及执行代价的语句。

除了DDL/start transaction 之类的语句，以及部分白名单语句，此类语句都是视为基本不消耗资源，而且不会形成阻塞的语句。

针对目前的管控机制来讲，能够将单个用户关联到一个单独的资源池，这个资源池不设置内存配置，只设置并发配置，达到进行做业管控的效果。

具体步骤及解释以下：

1.在全部节点建立好控制组

gs_ssh -c "gs_cgroup -c -S class_a"
gs_ssh -c "gs_cgroup -c -S class_a -G workload_a"

2.建立业务资源池（此时能够同步设置max_dop参数，active_statements会限制复杂做业的并发数量，max_dop参数会限制简单做业的并发数量）

create resource pool p1 with (control_group="class_a:workload_a");
alter resource pool p1 with (active_statements=10,mem_percent=0,max_dop=1);

3.关联用户与该资源池

ALTER USER testuser RESOURCE POOL 'p1';

5、小结

并发管理的用处，主要是为了防止用户跑太多的做业，致使集群负载过大，资源发生争抢，系统不能稳定运行，会由于资源出现各类问题，CPU/内存/IO，哪个都是让人头疼的问题，并发控制也能够同步控制某一个用户的并发做业，避免由于一个用户的做业数量太大，致使其余用户在使用数据库的时候出现问题。

负载管理最主要的现象就是会出现做业排队的状况，排队是否合理，是否由于不合理的参数配置致使大量的业务阻塞；或者配置正常，可是没有达到上限就出现排队，本文的主要目的就是解决此类问题，或者及时定界到是什么缘由致使了阻塞。

实际使用过程当中，许多时候出现排队的状况，均可能和正在执行的语句有关，正在执行的语句占用着这个位置，又执行不完，其他语句天然会排队。所以咱们碰到语句大量阻塞的状况，要迅速定界到是由于什么而形成阻塞，怎么样能恢复正常使用。找到问题的语句后，要及时去将它作一些适当的调优，避免再次执行到这个语句，还会出现同样的状况。

 

点击关注，第一时间了解华为云新鲜技术~