Content      ..      1      2      3      ..

Greenplum Database (V6.2.1) - 2

Greenplum Database 管理员指南 V6.2.1

此图展示的是内存配额的情况，该图与官方文档中有不同，因为 default_group

资源组的 memory_limit 是 0，应该是只能使用全局共享内存的资源。

当一个查询的内存消耗超过了资源组中定额部分的限制，将可以从该资源组的可共

享部分获取，因此，对于一个事务槽位来说，可以获得的最大内存使用量，是每个槽位

的专享定额部分 + 可共享部分总量。不过，当有全局共享内存时，资源组的可共享部

分用完之后，还可以从全局共享内存获得内存资源。

全局共享内存

为所有资源组(包括缺省的 admin_group 和 default_group)配置的

MEMORY_LIMIT 属性的总和，是数据库为这些资源组预留的专享配额。如果总和小于

100，剩余部分就会作为全局共享内存来管理。全局共享内存，只有使用了 vmtracker

内存管理模式(基于 ROLE 的资源组)的资源组可以使用。

如果可以的话，数据库会在为查询分配了资源组的定额部分的内存和可共享部分

(如果有的话)的内存之后，为事务分配全局共享内存。这部分内存的分配也是按照先

到先得的原则。

注意：数据库会统计(但不主动监测)资源组中事务的内存使用情况，如果资源组中的

事务使用内存的情况达到了以下所有条件，该事务将会失败：

 资源组中可共享部分的内存耗尽。

 全局共享内存耗尽。

版权所有：Esena(陈淼 ) 编写：陈淼 - 54 -

Greenplum Database 管理员指南 V6.2.1

查看资源组配额

通过 gp_toolkit.gp_resgroup_config 视图可以查看资源组的配额设置。不

过，编者建议可以重建该视图，原有的视图定义实在不够优雅：

=# CREATE OR REPLACE VIEW gp_toolkit.gp_resgroup_config AS

SELECT groupid,groupname,

vs[1] AS concurrency,

vs[2] AS cpu_rate_limit,

vs[3] AS memory_limit,

vs[4] AS memory_shared_quota,

vs[5] AS memory_spill_ratio,

DECODE(vs[6],null,'vmtracker','0','vmtracker',

'1','cgroup','unknown') AS memory_auditor,

vs[7] AS cpuset

FROM (

SELECT g.oid AS groupid,

g.rsgname AS groupname,

array_agg(c.value order by reslimittype) vs

FROM pg_resgroup g, pg_resgroupcapability c

WHERE g.oid = c.resgroupid

GROUP BY 1,2

) t;

ALTER TABLE gp_toolkit.gp_resgroup_config OWNER TO gpadmin;

GRANT ALL ON TABLE gp_toolkit.gp_resgroup_config TO gpadmin;

GRANT SELECT ON TABLE gp_toolkit.gp_resgroup_config TO public;

查看资源组的配额设置：

=# SELECT * FROM gp_toolkit.gp_resgroup_config;

查看资源组的查询状态和 CPU 内存使用量

通过 gp_toolkit.gp_resgroup_status 视图来查看资源组的事务活跃情况，

版权所有：Esena(陈淼 ) 编写：陈淼 - 63 -

Greenplum Database 管理员指南 V6.2.1

式排队。在查询优先级启用的情况下，系统会定期的重新分配计算资源。编者想说，排

队也是要消耗内存的，资源队列的排队相当于是在等待锁，而且查询的执行计划已经生

成并开始执行，只是未获取必要的锁，实际上内存已经分配，如果有大量消耗大量内存

的语句在排队，可能会出现内存不足的报错。

超级用户是不受资源队列限制的。超级用户的查询语句总是被立即执行，不管其所

在的资源队列如何限制。

内存限制如何工作

在资源队列上设置的内存限制使得每个Instance上该资源队列能够使用的内存

总和不能超过设定的最大值。每个查询语句分配的内存大小是资源队列的内存限制除以

最大活动语句数量(建议与活动语句数限制结合使用，而不是与cost限制结合使用，如

果是与cost限制结合使用，将按照cost的权重进行分配)。例如，资源队列的内存限

制为2000MB，活动语句数限制为10，那么每条执行语句可以得到200MB的内存。缺省

的内存分配可以针对每条语句通过设置statement_mem参数来覆盖(最大可以达到资

源队列限制的值)。一旦一条语句开始执行，其分配的内存一直到执行结束才会释放(即

便其实际使用的内存小于分配的内存)。

执行优先级如何工作

资源限制是针对活动语句来说的，内存和成本的限制属于是否许可类型，其决定查

询语句是允许进入查询状态还是保持排队状态。在语句处于活动状态时，其需要分享

CPU资源，这部分的资源由资源队列的优先级控制。当一个更高优先级的语句进入运行

状态时，其要求获得更多的CPU资源，相应的需要减少其他运行中语句的CPU资源。

语句的规模和复杂程度不会影响到CPU资源的分配。例如一个简单低cost的查询

与一个庞大复杂的查询同时执行却有着相同的优先级，他们在同一时间段内将分配到相

同的CPU资源。当一个新的语句开始执行，CPU资源分配的比重需要被重新计算，不过，

相同优先级的语句之间获得的CPU资源仍然是相同的。

版权所有：Esena(陈淼 ) 编写：陈淼 - 69 -

Greenplum Database 管理员指南 V6.2.1

例如，管理员想要创建3个资源队列：adhoc用于做持续查询的业务分析，

reporting用于做定期的报表工作，executive用于高级用户查询。管理员希望确保

定期报表工作不受到adhoc分析查询不可预测的资源消耗的影响，希望高级用户提交的

查询能够获得更多计算资源。因此，资源队列优先级可以设置为这样：

 adhoc -- Low priority

 reporting -- High priority

 executive -- Maximum priority

运行时，CPU资源由正在运行语句的优先级决定如何分配。如果语句1与语句2来自

reporting队列且同时运行，他们将获得相同CPU资源。当一个来自adhoc队列语句

开始运行，其需要较少的CPU资源。CPU资源的分配将做调整，他们之间的比重受他们

的优先级决定：

注意：该图显示的是粗略的百分比。在CPU的使用上，并不总是按照精确的比值来

分配资源，因为资源组做不到CPU资源的精细控制。

当一个来自executive的语句开始执行，CPU资源将根据他们的优先级重新调整。

该语句相对于adhoc和reporting来说可能是很简单的，但在其执行完之前，其仍获

取最大份额的CPU资源。

版权所有：Esena(陈淼 ) 编写：陈淼 - 70 -

Greenplum Database 管理员指南 V6.2.1

资源队列评估的语句类型

并不是所有的SQL语句都被资源队列评估和限制。缺省状态下只有SELECT、

SELECT INTO、CREATE TABLE AS SELECT和DECLARE CURSOR语句被评估和限

制。若将Server端参数resource_select_only设置为off，INSERT、UPDATE和

DELETE语句也将被评估和限制。

使用资源队列做资源管理的步骤

在GP中使用资源队列做资源管理涉及到如下几个任务：

1. 创建资源队列并设置合适的限制。

2. 为User Role指定资源队列。

3. 使用资源队列相关的系统视图监控和管理资源队列。

配置资源队列管理资源

在初始化GP集群时资源管理缺省使用资源队列。缺省的资源队列是pg_default，

活动语句数量限制为20，成本(Cost)无限制，内存(Memory)无限制，中(Medium)

优先级。建议为不同类型的工作负载，创建不同类型的资源队列。

版权所有：Esena(陈淼 ) 编写：陈淼 - 71 -

Greenplum Database 管理员指南 V6.2.1

清除资源队列中等待的语句

有时候可能需要清除资源队列中处于等待状态的语句。例如，想要清除在资源队列

中处于等待状态还没有得到执行的语句，也有可能想要终止一个已经开始而需要很长时

间才能完成的语句，或者该语句处于空闲的事务状态而希望把其占用的资源让给其他需

要的ROLE。要达到这些目的，首先需要知道哪些语句需要被清除，确定该进程的PID，

然后使用pg_cancel_backend函数来终止该进程。

例如，查看当前处于活动状态或者等待状态的语句：

=# SET from_collapse_limit TO 1;

SELECT rolname, rsqname, a.pid, granted, a.query, datname

FROM pg_roles r, gp_toolkit.gp_resqueue_status s, pg_locks l,

pg_stat_activity a

WHERE r.rolresqueue = l.objid AND r.rolname = a.usename

AND l.objid=s.queueid AND a.pid=l.pid;

若没有结果返回，意味着当前没有语句处于资源队列中。例如有两个语句在资源队

列中可能是这种样子的：

根据输出结果确定需要清除语句的进程PID(pid)。通过下面的方式清除语句：

=# SELECT pg_cancel_backend(1855);

注意：尽量不要使用OS的KILL命令。当然也不是完全不可以用，除非有把握确保不会

导致数据库损坏。

查看活动语句的优先级

在gp_toolkit模式中有个视图gp_resq_priority_statement，其包含了所

有正在执行的语句的优先级，会话ID等信息。该视图只能通过gp_toolkit模式访问。

版权所有：Esena(陈淼 ) 编写：陈淼 - 81 -

Greenplum Database 管理员指南 V6.2.1

如果一个表空间与DB关联，那么其将存储所有该DB的系统表、临时文件等。此外，

其也是在该DB上创建表、索引等缺省的表空间(除非通过TABLESPACE或者

default_tablespace参数重新指定)。如果DB在创建的时候没有与特定的表空间相

关联，那么该DB与其使用的模版DB使用相同的表空间。

一旦表空间被创建了，将可以被任何有访问权限的用户在任意的DB中使用。

查看现有的表空间和文件空间

每个GP系统都有两个缺省的表空间：pg_global(用以存储全局系统表的数据，

系统保留，不可使用)和pg_default(缺省表空间，存储template1和template0

模版数据库和postgres数据库，也是其他数据库的缺省表空间)。

注意：此处所说的是6版本之前的概念。

在6之前的版本中，这些缺省的表空间使用的是缺省的文件空间pg_system(这是

GP集群在初始化的时候建立的，使用的是Instance的工作目录)。

要获取文件空间的信息，可以通过系统表pg_filespace和

pg_filespace_entry进行关联查询。例如：

=# SELECT fsname AS filespace, fsedbid AS dbid,fselocation AS datadir

FROM pg_filespace f, pg_filespace_entry e

WHERE e.fsefsoid = f.oid ORDER BY filespace,dbid;

可通过上述两个系统表与pg_tablespace关联查看表空间的完整定义。例如：

=# SELECT spcname AS tablespace, fsname AS filespace, fsedbid AS dbid,

fselocation ||

decode(spcname,'pg_default','/base','pg_global','/global','/'||t.oid) AS

datadir

FROM pg_tablespace t, pg_filespace f, pg_filespace_entry e

版权所有：Esena(陈淼 ) 编写：陈淼 - 91 -

Greenplum Database 管理员指南 V6.2.1

WHERE t.spcfsoid = e.fsefsoid AND e.fsefsoid = f.oid

ORDER BY tablespace, dbid;

注意：此处所说的是6版本的概念。

在6版本中，这些缺省的表空间，使用的是系统初始化时指定的Master和

Instance的工作目录。

要获取表空间的信息，可以查询pg_tablespace系统表。例如：

=# SELECT oid,* FROM pg_tablespace;

然后使用gp_tablespace_location()函数来查看具体某个表空间的目录信息。

例如：

=# SELECT * FROM gp_tablespace_location(86891) ORDER BY gp_segment_id;

通过该函数无法查询到缺省表空间pg_global和pg_default的目录信息，不过，

这些信息，可以通过查询gp_segment_configuration系统表的datadir字段来获

取。

版权所有：Esena(陈淼 ) 编写：陈淼 - 92 -