工作负载及资源管理
查询分析-查看EXPLAIN输出
- EXPLAIN输出一个计划为节点组成的树
- 每个节点表示一个独立的操作
- 计划应该从下向上读,每个节点得到的记录向上传递
- 成本评估项:
cost - 获取的磁盘页数,1.0等于一个连续的磁盘页读取;第一个评估是开始成本,第二个评估是总成本
rows - 输出的记录数,通常小于真实处理的数量。顶层节点评估的数量最接近真实值
width - 输出的总字节数。
devdw=# explain select * from tb_cp_02 t where t.id = 1;
QUERY PLAN
-----------------------------------------------------------------------------------
Gather Motion 1:1 (slice1; segments: 1) (cost=0.00..6.08 rows=7 width=22)
-> Append (cost=0.00..6.08 rows=4 width=22)
-> Seq Scan on tb_cp_02_1_prt_extra t (cost=0.00..2.08 rows=2 width=18)
Filter: id = 1
-> Seq Scan on tb_cp_02_1_prt_2 t (cost=0.00..1.00 rows=1 width=24)
Filter: id = 1
-> Seq Scan on tb_cp_02_1_prt_3 t (cost=0.00..1.00 rows=1 width=24)
Filter: id = 1
-> Seq Scan on tb_cp_02_1_prt_4 t (cost=0.00..1.00 rows=1 width=24)
Filter: id = 1
-> Seq Scan on tb_cp_02_1_prt_5 t (cost=0.00..1.00 rows=1 width=24)
Filter: id = 1
(12 rows)
查询分析-查看EXPLAIN ANALYZE输出
- EXPLAIN输出真实运行的评估结果
- 输出的额外信息:
- 执行查询花费的总时间
- 参与每个节点计划的节点数,只有返回记录的segment实例被统计
- 操作中的segment实例返回的最大结果数量及其ID
- 返回最大结果数量的segment实例产生记录的开始时间和结束时间
- Slice数量及其内存消耗
如何看查询计划
- 若一个查询性能很差,查看查询计划有可能帮助我们找到问题
- 关注的几个方面:
-计划中是否有一个操作花费时间过长?
-优化器的评估是否接近实际情况?
-选择性强的条件是否较早出现?
-优化器是否选择了最佳的关联顺序?
-优化器是否选择性的扫描分区表?
-优化器是否合适的选择了HASH聚合与HASH关联操作?
HASH操作通常比其他类型的操作要快;
记录在内存中的比较排序比磁盘块
Work_mem wanted: 33649K bytes avg, 33649K bytes max (seg0) to lessen
GP工作负载管理
- 目的是控制同时活动的查询数量以避免造成系统资源耗尽
- GP已经具备基于ROLE体系的资源队列
- 资源队列可以限制执行查询的数量及CPU资源使用优先级
- 资源队列如何工作
缺省资源队列pg_default
GP建议管理员为不同类型工作负载创建结构性独立的资源队列
目前资源队列对活动语句的限制:
a) 成本;
b) 数量;
c) 内存使用量
每个实例上该资源队列能够使用的内存总和不能超过设定的最大值;
每个查询语句分配的内存大小是内存限制除以最大活动语句数量。
d) 优先级
当一个更高优先级的语句进入运行状态时,将获得更多的CPU资源;
语句的规模和复杂程度不会影响到CPU资源的分配。 - 资源队列评估的语句类型
a) 当resource_select_only参数为on时,只有SELECT、SELECT INTO、CREATE TABLE AS SELECT和DECLARE CURSOR语句被评估限制
b) 为off时,INSERT、UPDATE和DELETE语句也将被评估和限制;
devdw=# show resource_select_only;
resource_select_only
----------------------
off
(1 row)
- 开启工作负载管理的步骤
a) 创建资源对联并设置合适的限制;
b) 为User Role指定资源队列;一个角色只能分配一个资源队列,一个资源队列可以管理多个角色;
c) 使用工作负载管理相关的视图监控和管理资源队列,gp中存在相关视图监控相关。 - 配置工作负载管理
a) 缺省pg_default,活动语句连接数量为20,成本和内存无限制,CPU中等优先级
GP工作负载管理-配置工作负载管理
- 一般资源队列配置参数
max_resource_queues
– 最多资源队列数max_resource_portals_per_transaction
– 事务最多打开的游标数resource_cleanup_gangs_on_wait
– 开启新查询前清空队列中空闲进程stats_queue_level
– 激活资源
devdw=# show max_resource_queues;
max_resource_queues
———————
9(1 row)
devdw=# show max_resource_portals_per_transaction ;
max_resource_portals_per_transaction
————————————–
64
(1 row)
devdw=# show resource_cleanup_gangs_on_wait;
resource_cleanup_gangs_on_wait
——————————–
on
(1 row)
devdw=# show stats_queue_level ;
stats_queue_level
——————-
off
(1 row)- 与内存有关的参数
gp_resqueue_memory_policy
– GP内存管理特性,默认是eager_free;statement_mem and max_statement_mem
– 每个活动语句内存分配量(可以覆盖资源队列的内存限制),前者默认200MB,后者默认2000MB;gp_vmem_protect_limit
– 所有segment实例可使用的物理内存总量,默认是8192M。gp_vmem_idle_resource_timeout and gp_vmem_protect_segworker_cache_limit
– 用于释放被空间DB进程占用的内存,前者默认是18s,后者默认是500
- 与内存有关的参数
- 与查询优先级有关的参数(注意,都是local参数,必须修改每个instance上的postgresql.conf文件)
gp_resqueue_priority
– 开启优先级特性,默认是on;gp_resqueue_priority_sweeper_interval
– 设置CPU为所有语句重新计算CPU资源分配的时间,默认是1000;gp_resqueue_priority_cpucores_per_segment
– 设置每个实例使用的CPU,默认是4; 可使用gpconfig命令来查看和修改工作负载配置参数
查看一个参数值$ gpconfig –show gp_vmem_protect_limit
修改一个参数的值,且Master与Segment不同
$ gpconfig –c gp_resqueue_priority_cpucores_per_segment –v 2 –m 8
重启GP以确保修改的参数生效
$ gpstop –rf (加上f命令,将所有session都关闭)
创建资源队列
- 创建资源队列涉及到Name、成本、活动语句数量、执行优先级等
- 通过CREATE RESOURCE QUEUE命令来创建新的资源队列
- 创建活动语句数量限制的资源队列
通过设置ACTIVE_STATEMENTS控制活动语句的数量。例如,
=# CREATE RESOURCE QUEUE req_01 WITH (ACTIVE_STATEMENTS=2);
devdw=# create resource queue req_01 with (active_statements=2);
CREATE QUEUE
devdw=# select * from pg_resqueue;
rsqname | rsqcountlimit | rsqcostlimit | rsqovercommit | rsqignorecostlimit
------------+---------------+--------------+---------------+--------------------
req_01 | 2 | -1 | f | 0
pg_default |20 | -1 | f | 0
(2 rows)
- 创建内存限制的资源队列
a) 通过设置MEMEORY_LIMIT控制该队列所有语句可以使用的内存总量,需要考虑到当前每台主机的内存数量。
b) GP建议将MEMORY_LIMIT控制在该Instance可以得到的物理内存总数的90%以下。
c) GP推荐与ACTIVE_STATEMENTS结合使用而不与MAX_COST结合使用 - 当与ACTIVE_STATEMENTS结合使用时,缺省每个语句获得的内存为: MEMORY_LIMIT/ ACTIVE_STATEMENTS,例如:
=# CREATE RESOURCE QUEUE req_02 WITH (ACTIVE_STATEMENTS=10, MEMORY_LIMIT=‘2000MB’);
devdw=# CREATE RESOURCE QUEUE req_02 WITH (ACTIVE_STATEMENTS=10, MEMORY_LIMIT='200MBB');
CREATE QUEUE
devdw=# select * from pg_resqueue;
rsqname | rsqcountlimit | rsqcostlimit | rsqovercommit | rsqignorecostlimit
------------+---------------+--------------+---------------+--------------------
req_01 | 2 | -1 | f | 0
pg_default |20 | -1 | f | 0
req_02 |10 | -1 | f | 0
(3 rows)
- 创建成本限制的资源队列
a) 通过设置MAX_COST限制被执行的语句可消耗的最大成本。
b) Cost是GP查询优化器评估出来的总预估成本。
c) Cost以一个浮点数(如100.0或者科学计数法如1e+2)来指定。例如,
=# CREATE RESOURCE QUEUE req_03 WITH (MAX_COST=1000000.0);
devdw=# CREATE RESOURCE QUEUE req_03 WITH (MAX_COST=1000000.0);
CREATE QUEUE
devdw=# select * from pg_resqueue;
rsqname | rsqcountlimit | rsqcostlimit | rsqovercommit | rsqignorecostlimit
------------+---------------+--------------+---------------+--------------------
req_01 | 2 | -1 | f | 0
pg_default |20 | -1 | f | 0
req_02 |10 | -1 | f | 0
req_03 |-1 |1e+06 | f | 0
(4 rows)
d) 允许系统空闲时执行语句
如果资源队列配置了Cost阀值,管理员可以允许COST_OVERCOMMIT,超过资源队列Cost阀值的语句可以被执行;
如果COST_OVERCOMMIT为false,超过cost阀值语句永远被拒绝。
e) 允许小查询绕过队列限制
可以设置MIN_COST指明什么样的开销作为小查询,那些低于MIN_COST的语句将立即得到执行。
MIN_COST不仅可以同MAX_COST一起使用,还可以和ACTIVE_STATEMENTS一起使用。例如,
=# CREATE RESOURCE QUEUE req_04 WITH (ACTIVE_STATEMENTS=10, MIN_COST=100.0);
devdw=# CREATE RESOURCE QUEUE req_04 WITH (ACTIVE_STATEMENTS=10, MIN_COST=100.0);
CREATE QUEUE
devdw=# select * from pg_resqueue;
rsqname | rsqcountlimit | rsqcostlimit | rsqovercommit | rsqignorecostlimit
------------+---------------+--------------+---------------+--------------------
req_01 | 2 | -1 | f | 0
pg_default |20 | -1 | f | 0
req_02 |10 | -1 | f | 0
req_03 |-1 |1e+06 | f | 0
req_04 |10 | -1 | f |100
创建资源队列
- 设置优先级级别
为了控制CPU资源的使用,可以设置合适的优先级。例如,
=# CREATE RESOURCE QUEUE req_05 WITH (ACTIVE_STATEMENTS=3, PRIORITY=MAX);
devdw=# CREATE RESOURCE QUEUE req_05 WITH (ACTIVE_STATEMENTS=3, PRIORITY=MAX);
CREATE QUEUE
devdw=# select * from pg_resqueue;
rsqname | rsqcountlimit | rsqcostlimit | rsqovercommit | rsqignorecostlimit
------------+---------------+--------------+---------------+--------------------
req_01 | 2 | -1 | f | 0
pg_default |20 | -1 | f | 0
req_02 |10 | -1 | f | 0
req_03 |-1 |1e+06 | f | 0
req_04 |10 | -1 | f |100
req_05 | 3 | -1 | f | 0
(6 rows)
- 在查询优先级特性开启时,资源队列的优先级缺省为MEDIUM
分配ROLE(User)到资源队列
- 资源队列被创建好后,需要把ROLE(User)分配到合适的资源队列
- 使用ALTER ROLE或者CREATE ROLE命令来分配。例如,
=# ALTER ROLE dylan RESOURCE QUEUE seq_01;
=# CREATE ROLE jack WITH LOGIN RESOURCE QUEUE seq_02;
devdw=# \du
List of roles
Role name | Attributes | Member of
-----------+--------------------------------------+-----------
admin | Create role, Create DB, Cannot login |
gpadmin | Superuser, Create role, Create DB|
mavshuang | | {admin}
devdw=# alter role mavshuang resource queue req_01;
ALTER ROLE
devdw=# create role jack with login resource queue req_02;
CREATE ROLE
devdw=# \du
List of roles
Role name | Attributes | Member of
-----------+--------------------------------------+-----------
admin | Create role, Create DB, Cannot login |
gpadmin | Superuser, Create role, Create DB|
jack | |
mavshuang | | {admin}
- 每个ROLE同一时间只能被分配到一个资源队列
- 对GROUP ROLE进行资源分配并不会将其USER分配到该资源队列
- SUPERUSER总是不受资源队列限制的。
- 从资源队列中移除ROLE
所有ROLE都需要分配到资源队列 将ROLE从现有资源队列中移除并放到缺省队列中,
=# ALTER ROLE jack RESOURCE QUEUE none;
修改资源队列
变更资源队列
a) 使用ALTER RESOURCE QUEUE命令来改变资源队列的限制
=# ALTER RESOURCE QUEUE req_01 WITH (ACTIVE_STATEMENTS=3);
=# ALTER RESOURCE QUEUE req_02 WITH (MAX_COST=100000.0);
b) 将活动语句数量或者内存限制重置为无限制,可以使用-1值。=# ALTER RESOURCE QUEUE req_01 WITH (MAX_COST=-1.0, MEMORY_LIMIT=‘2GB’);
c) 改变查询优先级=# ALTER RESOURCE QUEUE req_01 WITH (PRIORITY=MIN);
- 删除资源队列
a) 要删除一个资源队列,该队列不能与任何ROLE相关。 使用DROP RESOURCE QUEUE命令删除资源队列。
=# DROP RESOURCE QUEUE req_04;
检查资源队列状态
- 查看排队语句和资源队列状态
该视图展示系统中每个资源队列有多少语句在等待执行,多少正在执行:
=# SELECT * FROM gp_toolkit.gp_resqueue_status; - 查看资源队列统计信息
确认开启统计信息收集(会带来轻微的资源开销):stats_queue_level=on
使用系统视图pg_stat_resqueues来查看资源队列使用的统计信息。 - 查看分配到资源队列的ROLE
查看ROLE与资源队列之间的关系,是使用系统日志表pg_roles和gp_toolkit.gp_resqueue_status来获得:
=# SELECT rolname, rsqname
FROM pg_roles rol, gp_toolkit.gp_resqueue_status res
WHERE rol.rolresqueue=res.queueid;
4. 查看活动语句的优先级
使用gp_toolkit.gp_resq_priority_statement
视图
重置活动语句的优先级
5. SUPERUSER可以在语句运行期间通过内置函数gp_adjust_priority(session_id, statement_count
调整优先级。例如,
select gp_adjust_priority(752,24905,'HIGH');
该语句只对指定的语句有效,同一资源队列随后的语句仍然使用其预先设定的优先级
来源:oschina
链接:https://my.oschina.net/u/4353003/blog/4486296