背景

对于一个数据库实例来说，CPU和内存资源是有限的，而这些资源又极大地影响着数据库的查询性能。因此，当数据库负载高到一定程度的时，各个查询之间可能会相互竞争CPU和内存资源，造成整体的查询性能低下。这对于那些延迟敏感的业务来说，是不可忍受的情况。在AnalyticDB for PostgreSQL（简称ADB PG）中，提供了系统资源负载管理工具--resource queue。用户可以根据自身业务的情况，指定数据库可运行的并发查询数、每个查询可以使用的内存大小、以及可使用的CPU资源。这样可以保证查询有预期的系统资源，从而得到符合预期的查询性能。

使用resource queue进行负载管理与隔离

本节介绍如何在ADB PG中创建和使用resource queue。

创建resource queue

在ADB for PG中resource queue创建的语法如下

CREATE RESOURCE QUEUE name WITH (queue_attribute=value [, ... ])

其中queue_attribute为resource queue的属性，可以取如下值：

    ACTIVE_STATEMENTS=integer
        [ MAX_COST=float [COST_OVERCOMMIT={TRUE|FALSE}] ]
        [ MIN_COST=float ]
        [ PRIORITY={MIN|LOW|MEDIUM|HIGH|MAX} ]
        [ MEMORY_LIMIT='memory_units' ]

 | MAX_COST=float [ COST_OVERCOMMIT={TRUE|FALSE} ]
        [ ACTIVE_STATEMENTS=integer ]
        [ MIN_COST=float ]
        [ PRIORITY={MIN|LOW|MEDIUM|HIGH|MAX} ]
        [ MEMORY_LIMIT='memory_units' ]

其中，ACTIVE_STATEMENTS指定了resource queue在某个时间点最多的活跃查询（正在执行的查询）数量。MEMORY_LIMIT设定了resource queue所有查询在单个计算节点（segment）上最多可以使用的内存大小，单位可以为KB，MB或者GB，默认值为-1，表示没有限制。MAX_COST设定了resource queue查询代价的最大值，这里的查询代价是指ADB for PG优化器估算出来的查询代价，默认值为-1，表示没有限制。COST_OVERCOMMIT参数与MAX_COST参数相关，如果设置了MAX_COST参数，那么当COST_OVERCOMMIT为true时，表示查询代价大于MAX_COST的那些查询可以在系统空闲的时候执行，而如果为false，则表示查询代价大于MAX_COST的那些查询将会被拒绝执行。MIN_COST设定了resource queue最小的查询代价，当查询代价小于MIN_COST的查询，将不会排队等待而是会立即被执行。PRIORITY设置了resource queue的优先级，优先级高的查询将会被分配更多的CPU资源用于执行，如果没有指定优先级，默认值为MEDIUM。

在create resource queue时，ACTIVE_STATEMENTS和MAX_COST两个属性中必须指定一个，否则创建无法成功。

postgres=>  CREATE RESOURCE QUEUE adhoc2 WITH (MEMORY_LIMIT='2000MB');
ERROR:  at least one threshold ("ACTIVE_STATEMENTS", "MAX_COST") must be specified

• 创建resource queue时可以指定这个resource queue里的用户可以并发执行的查询数量

  CREATE RESOURCE QUEUE adhoc WITH (ACTIVE_STATEMENTS=3);

  这里创建了一个名为adhoc的resource queue，这个resource queue里的用户在某一个给定的时间点，最多只会有3个查询在执行。如果此时adhoc队列中，用户正在执行的查询数量为3个，如果此时有新的查询进入，那么这个查询将会处于waiting状态，直到前面有查询执行完毕。

• 创建resource queue时可以指定这个resource queue里查询使用的内存上限

  CREATE RESOURCE QUEUE myqueue WITH (ACTIVE_STATEMENTS=20, MEMORY_LIMIT='2000MB');

  这里创建了一个名为myqueue的resource queue，在这个resource queue里的所有query最多能用2000MB的内存大小。其中每个查询在执行的时候，会在计算节点（segment）占用MEMORY_LIMIT/ACTIVE_STATEMENTS的内存，对于myqueue这个resource queue来说每个查询会占用2000MB/20=100MB的内存。如果对于某些查询查询需要单独可用的内存大小，可以使用系统参数statement_mem来设置，但是需要保证不超过resource queue设定的MEMORY_LIMIT和系统参数max_statement_mem。示例如下：

  SET statement_mem='1GB';
  SELECT * FROM test_adbpg WHERE col='adb4pg' ORDER BY id;
  RESET statement_mem;

• 设置优先级队列
  给不同的resource queue设置优先级可以控制resource queue中的查询对CPU资源的使用。例如，当系统中有大规模并发查询的时候，高优先级resource queue中的查询会比低优先的resource queue中的查询使用更多的CPU资源，从而保证高优先级的查询有更充分的CPU资源来执行，以便获得更低的响应延迟。resource queue优先级的设置可以在创建时或者也可以在创建完成之后使用alter...with语句进行修改。示例如下：

  CREATE RESOURCE QUEUE executive WITH (ACTIVE_STATEMENTS=3, PRIORITY=MAX);
  
  ALTER RESOURCE QUEUE adhoc WITH (PRIORITY=LOW);
  ALTER RESOURCE QUEUE reporting WITH (PRIORITY=HIGH);

优先级与ACTIVE_STATEMENTS和MEMORY_LIMIT的机制不同的是：ACTIVE_STATEMENTS和MEMORY_LIMIT会在查询执行之前判断其是否允许被执行。而优先级机制则是在一个查询开始执行后，根据系统的运行状态动态地给这个对应的查询根据其所在队列的优先级分配可用的CPU资源。例如，某个时刻ADB PG中有一些低优先级的查询在执行，然后一个高优先级的查询进到了ADB PG中并准备执行。那么ADB PG会为这个查询分配更多的CPU资源，并减少低优先级查询的CPU资源。CPU资源分配的规则如下：相同优先级的查询所能被分配到的CPU资源一致。当系统中同时有高、中、低三个优先级别的查询的时候，高优先级的查询会分配得到系统90%的CPU资源，剩下的10%会留给中和低优先级的查询去分配，在这10%的系统CPU资源中，中优先级的查询会得到其中90%的CPU资源，低优先级查询则得到剩余的10%。

resource queue被创建完毕之后，可以使用gp_toolkit.gp_resqueue_status系统视图查看限制设置和当前资源队列的状态，如下所示：

postgres=> SELECT * from gp_toolkit.gp_resqueue_status WHERE
postgres->   rsqname='adhoc';
 queueid | rsqname | rsqcountlimit | rsqcountvalue | rsqcostlimit | rsqcostvalue | rsqmemorylimit | rsqmemoryvalue | rsqwaiters | rsqholders
---------+---------+---------------+---------------+--------------+--------------+----------------+----------------+------------+------------
   19283 | adhoc   |             3 |             0 |           -1 |            0 |             -1 |              0 |          0 |          0
(1 行记录)

另外，resource queue的创建不能在事务块内进行：

postgres=> begin;
BEGIN
postgres=> CREATE RESOURCE QUEUE test_q WITH (ACTIVE_STATEMENTS=3, PRIORITY=MAX);
ERROR:  CREATE RESOURCE QUEUE cannot run inside a transaction block

并不是所有的sql都会受到resource queue的限制，当resource_select_only被设置成on的时候，只有SELECT, SELECT INTO, CREATE TABLE AS SELECT, and DECLARE CURSOR会受到约束。而resource_select_only为off的时候，INSERT, UPDATE, and DELETE也会被资源队列管理起来。在ADB PG中，resource_select_only默认设置成了off。

将role分配给resource queue

创建好resource queue之后，我们必须将一个或多个用户分配给这个resource queue，这样这个resource queue就会为其中用户的所有查询进行资源管理。如果一个用户，没有显示指定分配个哪个resource queue，那么ADB PG会默认将他分配给pg_default资源队列。在ADB PG中，pg_default可以同时运行500个活跃的查询语句，没有cost limit的限制，优先级为medium：

postgres=> SELECT * from gp_toolkit.gp_resqueue_status WHERE rsqname='pg_default';
 queueid |  rsqname   | rsqcountlimit | rsqcountvalue | rsqcostlimit | rsqcostvalue | rsqmemorylimit | rsqmemoryvalue | rsqwaiters | rsqholders
---------+------------+---------------+---------------+--------------+--------------+----------------+----------------+------------+------------
    6055 | pg_default |           500 |             1 |           -1 |          126 |             -1 |   2.096128e+09 |          0 |          1
(1 行记录)

将一个role分配给一个resource queue的语法如下：

ALTER ROLE name RESOURCE QUEUE queue_name;
CREATE ROLE name WITH LOGIN RESOURCE QUEUE queue_name;

用户既可在role创建之后修改其所属的resource queue，也可以在role创建之时为其指定resource queue。需要注意的是，在任意时刻一个role只能归属于一个resource queue。

删除resource queue某个归属的role

一个role必须要归属于一个resource queue，当我们需要把某个role移除出指定的resource queue，然后重新放回到pg_default这个resource queue时，可以使用

ALTER ROLE role_name RESOURCE QUEUE none;

修改resource queue的配置

resource queue创建完毕后，可以使用alter语句对resource queue的资源配置进行修改，如下：

修改活跃的查询数：
ALTER RESOURCE QUEUE adhoc WITH (ACTIVE_STATEMENTS=5);
修改resource queue优先级：
ALTER RESOURCE QUEUE exec WITH (PRIORITY=MAX);
修改resource queue内存和计划代价约束：
ALTER RESOURCE QUEUE adhoc WITH (MAX_COST=-1.0, MEMORY_LIMIT='2GB');

删除resource queue

在删除一个resouce queue之前，我们需要保证这个resource queue没有被分配的role，以及没有任何查询处于waiting状态。否则，删除不会成功。

DROP RESOURCE QUEUE name;

参考资料

https://gp-docs-cn.github.io/docs/ref_guide/sql_commands/CREATE_RESOURCE_QUEUE.html
http://gpdb.docs.pivotal.io/43330/admin_guide/workload_mgmt.html#topic9