使用指南

配置基于内存使用的自动查询终止

YMatrix 支持 Runaway 检测。对于由资源组管理的查询,可以根据查询所使用的内存量自动终止查询。 相关的配置参数如下:

  • gp_vmem_protect_limit:设置活动 segment 实例中所有 postgres 进程可以消耗的内存量。如果一个查询导致这个限制被超过,将不会分配内存,查询将失败。
  • runaway_detector_activation_percent:当启用资源组时,如果使用的内存量超过了指定值 gp_vmem_protect_limit * runaway_detector_activation_percent,YMatrix 将根据内存使用量来终止由资源组(不包括 system_group 资源组中的查询)管理的查询。查询终止将从消耗内存量最大的查询开始,直到内存使用量低于指定的百分比终止。

分配资源组给角色

  • 使用 CREATE ROLEALTER ROLE 命令的 RESOURCE GROUP 子句将资源组分配给数据库角色。

    ALTER ROLE bill RESOURCE GROUP rg_light;
    CREATE ROLE mary RESOURCE GROUP exec;

    可以将资源组分配给一个或多个角色。如果已定义角色的层次结构,分配给父角色的资源组不会向下传播到该角色组的成员。

  • 如果需要从角色中删除资源组分配并为角色分配默认组,可将角色的组名分配更改为 NONE

    ALTER ROLE mary RESOURCE GROUP NONE;

监控资源组状态

  • 查看资源组限制
    SELECT * FROM gp_toolkit.gp_resgroup_config;
  • 查看资源组查询状态
    SELECT * FROM gp_toolkit.gp_resgroup_status;
  • 查看每台主机上资源组的内存使用情况
    SELECT * FROM gp_toolkit.gp_resgroup_status_per_host;
  • 查看分配给角色的资源组
    SELECT rolname, rsgname FROM pg_roles, pg_resgroup
    WHERE pg_roles.rolresgroup=pg_resgroup.oid;
  • 查看资源组的运行中和待处理查询
    SELECT query, rsgname,wait_event_type, wait_event 
    FROM pg_stat_activity;
  • 取消资源组中正在运行或排队的事务 手动取消正在运行或排队的事务,必须先确定与事务关联的进程 id 或 pid。获得进程 id 后,可调用 pg_cancel_backend() 来结束该进程。 具体步骤如下:

a. 首先运行以下查询,查看所有资源组中当前活动或空闲的所有语句关联的流程信息。如果查询没有返回任何结果,则说明资源组中都没有正在运行或排队的事务。

SELECT rolname, g.rsgname, pid, waiting, state, query, datname 
FROM pg_roles, gp_toolkit.gp_resgroup_status g, pg_stat_activity 
WHERE pg_roles.rolresgroup=g.groupid
AND pg_stat_activity.usename=pg_roles.rolname;

b. 查询结果示例

rolname | rsgname  | pid     | waiting | state  |          query           | datname 
---------+----------+---------+---------+--------+-------------------------+---------
 sammy  | rg_light |  31861  |    f    | idle   | SELECT * FROM mytesttbl; | testdb
 billy  | rg_light |  31905  |    t    | active | SELECT * FROM topten;    | testdb

c. 事务进程结束

SELECT pg_cancel_backend(31905);

注意!
不要使用操作系统 KILL 命令取消任何 YMatrix 数据库进程。

移动查询至不同资源组

具有超级用户权限的用户可以运行 gp_toolkit.pg_resgroup_move_query() 函数将正在运行的查询从一个资源组移动到另一个资源组,而不会停止该查询。使用此函数可以通过将长时间运行的查询移动到资源分配或可用性更高的资源组来加快查询速度。

pg_resgroup_move_query() 仅将指定的查询移动到目标资源组,后续提交的查询仍分配至原资源组。

注意!
只能将活动或正在运行的查询移动到新资源组。由于并发或内存限制,不能移动处于空闲状态的排队或挂起的查询。

pg_resgroup_move_query() 需要正在运行的查询的进程 id 或 pid,以及要将查询移动到的资源组的名称。

pg_resgroup_move_query( pid int4, group_name text );

如取消资源组中正在运行或排队的事务中所述,可以使用 gp_toolkit.gp_resgroup_status 视图列出每个资源组的名称、id 和状态。

当调用 pg_resgroup_move_query() 函数时,正在运行的查询会受到目标资源组配置的限制,这些限制包括并发任务限制、内存限制等。

  • 如果目标资源组已达到其并发任务限制,数据库会将查询排队,直到有可用的槽位,或者如果设置了 gp_resource_group_queuing_timeout,则会排队等待指定的毫秒数。
  • 如果目标资源组有空闲插槽,pg_resgroup_move_query() 会尝试将槽位控制权交给目标进程,最多尝试 gp_resource_group_move_timeout 指定的毫秒数。如果目标进程在 gp_resource_group_queuing_timeout 时间内无法处理移动请求,数据库会返回错误信息。
  • 如果 pg_resgroup_move_query() 被取消,但目标进程已经获得了所有插槽空之前,segment 进程将不会移动到新组,目标进程将保留插槽。这种不一致的状态将在事务结束时或目标进程在同一事务中调度的任何下一个命令中修复。
  • 如果目标资源组没有足够的可用存储器来满足查询的当前内存需求,数据库将返回错误信息。可以选择增加目标资源组分配的共享内存,或者等待一段时间,让正在运行的查询完成,然后再调用该函数。

移动查询后,无法保证目标资源组中当前运行的查询不会超过该组内存配额。在这种情况下,目标资源组中一个或多个正在运行的查询可能会失败,包括移动的查询。可通过预留足够的资源组全局共享内存,以尽量减少这种情况发生的可能性。