关于数据库:GaussDBDWS应用实践丨负载管理与作业排队处理方法

摘要：本文用来总结一些 GaussDB(DWS)在理论利用过程中，可能呈现的各种作业排队的状况，以及呈现排队时，咱们应该怎么去判断是否失常，调整一些参数，让资源分配与负载治理更合乎以后的业务；或者在作业阻塞的时候，怎么去解决这些状况，让业务立即恢复正常。

概述

数据库系统的负载治理和资源管理，在整个零碎中起着很重要的作用，比方很多用户的业务压力过大时，有时会导致连贯数量被占满，有时会导致某种计算资源被占满，有时会导致存储空间被占满，这些状况都会导致整个集群进入异样甚至不可用的状态：正在执行的作业相互争抢 CPU，会导致大家都不能好好执行；大量作业执行时，占用大量内存，很容易触发到内存瓶颈，造成作业内存不可用问题，导致业务报错等等。在不进行并发管制的状况下，这些状况都很可能会呈现，影响到失常业务。

本文用来总结一些 GaussDB(DWS)在理论利用过程中，可能呈现的各种作业排队的状况，以及呈现排队时，咱们应该怎么去判断是否失常，调整一些参数，让资源分配与负载治理更合乎以后的业务；或者在作业阻塞的时候，怎么去解决这些状况，让业务立即恢复正常。

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

• 一、负载治理简介：双层排队简述
• 二、罕用视图以及应用办法介绍
• 三、负载治理常见问题以及解决
• 四、局部负载治理配置计划介绍
• 五、小结

一、负载治理简介：双层并发管制简述

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

DWS 并发管制逻辑示意图如下：

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

一种是 全局队列（global queue），这种队列不辨别简略和简单作业，也不辨别是 DDL 或者是一般语句，

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

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

二、罕用视图以及应用办法介绍

这里介绍几个罕用视图以及 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 之类状态的语句，也会占用一个并发数量，因为一个事务块的业务还未提交，天然也算是正在执行的业务，对于这种状况，后续能够思考进行一个处于此类状态的超时工夫的管制。

三、负载治理常见问题

个别当业务上发现工作阻塞时，能够从后盾查问局部语句排查目前的状况，此时要先看下景象上是什么状况，个别并发管制有以下几种景象，临时先列出这么多，后续持续补充：

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 左右。

因而这种场景下，内存资源只能满足以后两个语句的执行，其余属于该用户的语句都会进行排队。

• 解决方法：
• 办法一、此类问题，若在资源容许的状况下，能够适当调大租户相干的内存资源，让更多语句可能同时运行。
• 办法二、优化相干语句的执行效率，缩短执行工夫，让语句能够高效执行，防止大量沉积。

4. 执行的作业根本都是一个用户的，其余用户的作业根本都在排队中无奈执行。

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

比方：max_active_statements=20，其中某用户始终继续不停公开发 DDL，此时在 DWS 设计 ap 场景并未波及此类场景。会呈现该 20 个并发设置广泛被该用户占用的状况，其余用户可能呈现连不上的状况。

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

解决计划：

针对高并发 DDL 的不合理业务场景进行优化，比方把间断创立删除长期表的动作，改为对永恒表的操作，此时就能够极大幅度缩小 DDL 并发数量，保障本身业务以及其余用户业务的失常连贯和运行。

四、局部场景配置计划

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’;

五、小结

并发治理的用途，次要是为了避免用户跑太多的作业，导致集群负载过大，资源产生争抢，零碎不能稳固运行，会因为资源呈现各种问题，CPU/ 内存 /IO，哪一个都是让人头疼的问题，并发管制也能够同步控制某一个用户的并发作业，防止因为一个用户的作业数量太大，导致其余用户在应用数据库的时候呈现问题。

负载治理最次要的景象就是会呈现作业排队的状况，排队是否正当，是否因为不合理的参数配置导致大量的业务阻塞；或者配置失常，然而没有达到下限就呈现排队，本文的次要目标就是解决此类问题，或者及时定界到是什么起因导致了阻塞。

理论应用过程中，许多时候呈现排队的状况，都可能和正在执行的语句无关，正在执行的语句占用着这个地位，又执行不完，其余语句天然会排队。因而咱们碰到语句大量阻塞的状况，要迅速定界到是因为什么而造成阻塞，怎么样能恢复正常应用。找到问题的语句后，要及时去将它做一些适当的调优，防止再次执行到这个语句，还会呈现一样的状况。

点击关注，第一工夫理解华为云陈腐技术~