Greenplum资源管理——Resource Queue常见使用问题

概述 

Resource Queue（资源队列）是Greenplum最早的资源管理方式，能够对数据库的CPU、内存等资源进行限制，对多租户资源限制、保障数据库稳定运行具有一定的作用。

在之前的文章中笔者对资源队列的基础原理和使用方式等内容进行了介绍，如果对这些内容感兴趣可以参考笔者前面的文章：

常见问题

1）哪些类型的SQL受资源队列控制？

答：非explain analyze执行的insert/update/delete/select语句。

2）哪些数据库账户受资源队列控制？

superuser账户资源不受队列控制，其他类型账户受资源队列控制。

3）哪些数据库账户可以修改资源队列配置？

Greenplum的superuser可以修改资源队列配置，其他类型账户不可以修改资源队列配置，但是可以查看配置。

4）资源队列与资源组是什么关系，能否同时使用，修改一类配置是否会影响另一类？

资源组是Greenplum另外一种资源管理方式，对资源组感兴趣可以参考笔者之前的文章：

资源队列与资源组不能同时使用，同一时间只能使用一种资源管理方式，可以通过gp_resource_manager查看，切换资源管理方式需要重启。任何时候，修改一类资源管理方式的配置不会影响另一种资源管理方式。举个例子，在当前资源管理方式为Queue的时候，可以通过ALTER SQL修改Resouce Group的配置，但不会对资源队列或者资源组的运行造成任何影响。

5）如何确认某个查询是由于资源队列原因在等锁？

第一步确认这个查询处于等锁状态：select * from pg_stat_activity where waiting_reason='lock';

第二步确认这个查询的等待类型：select locktype from pg_locks where pid= $targetpid;

如果查询类型是resource queue说明对应SQL由于资源队列原因处于锁等待状态。

6）资源队列相关命令是否能在事务块中运行？

不可以，资源队列相关命令（CREATE/ALTER Resource Queue等）无法在事务块中运行，但会运行在简单事务中，有ACID保证。

7）Resource Queue配置调整完会立刻生效吗，需不需要重启？

答：会立刻生效，不需要重启；

8）调完Resource Queue的各类上限，已经在队伍里等待的队列会立刻开始执行吗？

答：不会，比如提高了并发值，已经在队列里等待的确实不会立即执行，需要同一队列的查询执行完一条SQL清理自己的锁的时候，才会唤醒已经在队列里等待的其他SQL。

9）Resource Queue的队列优先级max和high的区别是什么？

答：ADB PG通过队列优先级管理不同队列上的CPU分配。每个队列的优先级有五种：

"MAX", "HIGH", "MEDIUM", "LOW", "MIN"

在对查询进行CPU份额管理的时候，会为每个query分配一个weight，分配时每个query所占的CPU份额等于：当前query的权重除以所有active的query的权重的总和。而当前query的权重是与所在队列的优先级有关。各个优先级的权重如下：

{"MAX", 1000000},

{"HIGH", 1000},

{"MEDIUM", 500},

{"LOW", 200},

{"MIN", 100},

所以来说，MAX在设计上使所在队列毫无疑问的占有99%以上的CPU，达到绝对的CPU份额优势；High也能抢占medium/low/min队列的份额，但是优势就没有这么大了。可以根据自己的业务需求情况分配各个业务队列的优先级。

10）单个语句能否占多个资源队列槽位？

答：可以的，在显式开启cursor，以及一些隐式使用cursor的场景下（plsql/Java extend 协议fetchSize参数不为0），单个session/statement可能获取多把资源组的锁，可以看到active状态的session个数少于队列状态视图中的活跃槽位数。

11）Resource Queue诱发了死锁，是什么原因？应该怎么解决？

在实际并发高于资源队列限制时，容易出现资源队列死锁问题，具体来说容易出现两种死锁：

一、业务锁与资源队列锁混合等待导致的死锁问题，我们考虑如下场景：

session1 and session2 connect server with role test1; test1 is associated with a queue with active_statements=1;

session1: accquire resource lock;

session2: vaccum full t1; accquire lock on t1;

session1: insert into t1 values ..;      --hold resource queue lock; wait for table lock on t1;

session2: select * from t1;                --hold table lock on t1; wait for resource queue lock; 

deadlock detected.

业务锁与资源队列锁混合等待导致的死锁问题如何解决：

0）重试大概率可以解决单个SQL的死锁问题；

1）增大资源队列并发上限可以缓解死锁问题；

2）换用资源组（resource group）可以解决这个问题。

二、资源队列锁环装等待构成的死锁问题：

下图就是一个经典的资源队列锁环装等待构成的死锁问题，可以看到三个进程是在互相等待resource queue lock。

这是因为在存在cursor的情况下（显式开启cursor，以及一些隐式使用cursor的场景下：plsql/Java extend 协议fetchSize参数不为0），一个进程可能会尝试获取多把锁，会在已经拥有锁、阻塞其他进程的情况下，再次尝试获取第二把锁，从而构成环状等待。

资源队列锁环装等待构成的死锁问题如何解决：

0）重试大概率可以解决单个SQL的死锁问题；

1）增大资源队列并发上限可以缓解死锁问题；

2）对于使用JDBC extend导致隐式开启cursor的客户，可以换用simple协议，或者将fetchSize参数设为0，来规避问题。

3）换用资源组（resource group）可以解决这个问题。