使用语法
Command: CREATE RESOURCE QUEUE
Description: create a new resource queue for workload management
Syntax:
CREATE RESOURCE QUEUE name WITH (queue_attribute=value [, ... ])
where queue_attribute is:
ACTIVE_STATEMENTS=integer
[ MAX_COST=float [COST_OVERCOMMIT={TRUE|FALSE}] ]
[ MIN_COST=float ]
[ PRIORITY={MIN|LOW|MEDIUM|HIGH|MAX} ]
[ MEMORY_LIMIT='memory_units' ]
参数说明
| 参数 | 说明 | |
|---|---|---|
| name | text | 资源队列的名字。 |
| ACTIVE_STATEMENTS | integer | 带有 ACTIVE_STATEMENTS 阀值的资源队列限制了分配到队列角色所能够执行的查询的数量。它（阀值）控制着活跃查询的数量，活跃查询是在同一时间允许运行的查询数量。ACTIVE_STATEMENTS 的值应该是一个大于0的整数值。 |
| MEMORY_LIMIT | memory_units | 对于所有从该资源队列中提交的语句设置总内存配额。内存单元可以指定为kB, MB或者GB。对于一个资源队列来说最小的内存配额是10MB， 没有最大限值，但是查询执行的上边界由Segment主机的物理内存所限定。默认值时没有限制为（-1）。 |
| MAX_COST | float | 带有MAX_COST 阀值的资源队列对查询代价设置了一个最大限制。该查询能够被分配到该队列的用户所执行。代价由Greenplum数据库查询优化器（正如查询EXPLAIN 输出显示的）确定的查询的 估计共代价 进行衡量的。因此，管理员必须要熟悉在系统中执行的典型查询，以对队列设置一个合理的阀值。成本以磁盘页提取为单位进行衡量；1.0 等于顺序读取一个磁盘页。MAX_COST 的值可以被指定为浮点数（例如 100.0） 或者可以被指定为（例如 1e+2）。 |
| COST_OVERCOMMIT | boolean | 如果基于 MAX_COST限制资源队列，则管理员可以允许 COST_OVERCOMMIT（默认）。这意味着超过允许的成本阈值的查询将被允许运行，但只有在系统空闲时才能运行。如果指定 COST_OVERCOMMIT=FALSE ，超过成本限制的查询将始终被拒绝，从不允许运行。 |
| MIN_COST | float | 该是最小查询的最小查询成本限制。成本低于此限制的查询将不会排队等待立即运行。成本由Greenplum数据库查询优化器（正如查询 EXPLAIN 输出所示）确定的查询的估计总成本所衡量。因此，管理员必须熟悉通常在系统上执行的查询，以便为被认为是小型查询设置适当的成本。成本是以磁盘页提取为单位来衡量的; 1.0等于一个顺序的磁盘页面读取。MIN_COST 的值可以被指定为浮点数（例如 100.0）或也可以被指定为一个指数（例如 1e+2）。 |
| PRIORITY | MIN/LOW/MEDIUM/HIGH/MAX | 设置和资源队列相关查询的优先级。队里中拥有高优先级的查询和语句会在竞争中拥有更大的可用CPU资源份额。队列中拥有低优先级的查询将会被推迟，同时，更高优先级的查询将会被执行。如果没有指定优先级，和队列相关的查询的优先级为 MEDIUM。 |
官方建议使用MEMORY_LIMIT 和ACTIVE_STATEMENTS 来替代max_cost
如果队列中未设置MEMORY_LIMIT，则每个查询可用的内存值为系统参数statement_mem的值，最大可用内存为statement_mem ACTIVE_STATEMENTS
并不是所有语句都受资源队列限制，默认情况下，只有SELECT, SELECT INTO, CREATE TABLE AS SELECT, 和DECLARE CURSOR受限，如果配置参数resource_select_only = off，则INSERT, UPDATE,DELETE语句也会受限
如果没有设置max_cost,那么每个语句使用的内存是MEMORY_LIMIT/ACTIVE_STATEMENTS,如果设置了max_cost,内存是MEMORY_LIMIT*(query_cost/max_cost),query_cost为实际SQL的cost
使用示例
创建资源队列
create resource queue q1 with (ACTIVE_STATEMENTS=10,MEMORY_LIMIT='128MB',priority=min);
create resource queue q2 with (ACTIVE_STATEMENTS=10,MEMORY_LIMIT='1GB',PRIORITY=HIGH,COST_OVERCOMMIT=true,MIN_COST=100,MAX_COST=1000000);
修改变更资源队列
a) 使用ALTER RESOURCE QUEUE命令来改变资源队列的限制
=# ALTER RESOURCE QUEUE q1 WITH (ACTIVE_STATEMENTS=3);
=# ALTER RESOURCE QUEUE q2 WITH (MAX_COST=100000.0);
b) 将活动语句数量或者内存限制重置为无限制，可以使用-1值。
=# ALTER RESOURCE QUEUE q1 WITH (MAX_COST=-1.0, MEMORY_LIMIT='2GB');c) 改变查询优先级
=# ALTER RESOURCE QUEUE q2 WITH (PRIORITY=MIN);删除资源队列
要删除一个资源队列，该队列不能与任何ROLE相关。使用DROP RESOURCE QUEUE命令删除资源队列。
=# DROP RESOURCE QUEUE q1;添加用户到资源队列中
a) 赋予role资源管理队列
alter role user1 resource queue q1;b) 恢复到使用默认的资源队列
ALTER ROLE hank RESOURCE QUEUE none;资源队列的相关查询语句
--查看资源队列的配置参数
select * from pg_resqueue_attributes
where rsqname in ('q1','q2');
--查询角色分配的资源队列
SELECT * from gp_toolkit.gp_resq_role
where rrrsqname in ('q1','q2');
--查看资源队列相关使用情况
SELECT * FROM gp_toolkit.gp_resqueue_status;
--查看队列的运行状态
select * from gp_toolkit.gp_resq_activity_by_queue
--查看资源队列统计信息,需要开启参数stats_queue_level
SELECT * FROM pg_stat_resqueues;
--查看资源队列的等待查询
SELECT * FROM gp_toolkit.gp_locks_on_resqueue WHERE lorwaiting='true';
--清理资源队列中等待的查询
SELECT rolname, rsqname, pid, granted,current_query, datname
FROM pg_roles, gp_toolkit.gp_resqueue_status, pg_locks,pg_stat_activity
WHERE pg_roles.rolresqueue=pg_locks.objid
AND pg_locks.objid=gp_toolkit.gp_resqueue_status.queueid
AND pg_stat_activity.procpid=pg_locks.pid
AND pg_stat_activity.usename=pg_roles.rolname;
--查询活动语句的优先级
select * from gp_toolkit.gp_resq_priority_statement;
重置活动语句的优先权
SELECT gp_adjust_priority(session_id, statement_count, 'rqppriority')从视图gp_toolkit.gp_resq_priority_statement获取对应的值
gp_adjust_priority()函数只影响指定的语句。同一资源队列中后续的语句还是使用该队列正常指派的优先权执行。
rqpsession列的值用作session_id参数
rqpcommand列的值用作statement_count参数
rqppriority列的值是当前优先权。可以指定字符串值MAX、HIGH、MEDIUM或者LOW作为priority。
select 'SELECT gp_adjust_priority('||rqpsession||', '||rqpcommand||', ''priority_text'');' as adjust
from gp_toolkit.gp_resq_priority_statement;
相关参数配置
资源队列
max_resource_queues - 设置资源队列的最大数量。
max_resource_portals_per_transaction - 设置每个事务允许同时打开的游标的最大数量。注意一个打开的游标将在资源队列中占有一个活动查询槽。
resource_select_only - 如果被设置为on，那么SELECT、SELECT INTO、CREATE TABLE ASSELECT和DECLARE CURSOR命令会被评估。如果被设置为off，INSERT、UPDATE以及DELETE也将被评估。
resource_cleanup_gangs_on_wait - 在资源队列中取得一个槽之前清除空转的Segment工作者进程。
stats_queue_level - 在资源队列使用上启用统计信息收集，然后可以通过查询pg_stat_resqueues系统视图来查看收集到的信息。
内存利用
gp_resqueue_memory_policy - 启用Greenplum数据库的内存管理特性。
在Greenplum数据库4.2和其后的版本中，分布算法eager_free会利用并非所有操作符都会同时执行这一事实。查询计划被划分成阶段并且Greenplum数据库会饥渴地在上一阶段执行结束时释放分配给上一阶段的内存，然后将释放出来的内存饥渴地分配给新的阶段。
当被设置为none时，内存管理与4.1之前Greenplum数据库发行版相同。当被设置为auto时，查询内存使用由statement_mem和资源队列内存限制所控制。
statement_mem和max_statement_mem - 被用来在运行时给一个特定查询分配内存（覆盖资源队列指派的默认分配）。max_statement_mem被数据库超级用户设置以防止常规数据库用户过度分配。
gp_vmem_protect_limit - 设置所有查询处理能消耗的上界并且不应超过Segment主机的物理内存量。当一台Segment主机在查询执行时达到这一限制，导致超过限制的查询将被取消。
gp_vmem_idle_resource_timeout和gp_vmem_protect_segworker_cache_limit - 被用来释放Segment主机上由闲置数据库进程持有的内存。管理员可能想要在有大量并发的系统上调整这些设置。
shared_buffers - 设置Greenplum服务器实例用作共享内存缓冲区的内存量。这个设置必须至少为128千字节并且至少为16千字节乘以max_connections。该值不能超过操作系统共享内存最大分配请求尺寸，该尺寸由Linux上的shmmax控制。推荐的OS内存设置请见Greenplum数据库安装指南。
查询优先相关
gp_resqueue_priority - 查询优先特性默认被启用。
gp_resqueue_priority_sweeper_interval - 设置所有活动语句重新计算CPU使用的时间间隔。这个参数的默认值应该足够用于通常的数据库操作。
gp_resqueue_priority_cpucores_per_segment - 指定每个Segment实例分配的CPU核数。Master和Segment的默认值是4。对于Greenplum Data Computing Appliance Version 2，Segment的默认值是4而Master默认值是25。
如果参数值未被设置正确，要么是CPU可能不会被完全利用，要么是查询优先可能无法按照预期工作
注意：操作系统任何可用的CPU核都会被包括在CPU核数中。例如，虚拟CPU核会被包括在CPU核数中。
