用资源组进行工作负载管理
用户可以使用资源组在Greenplum数据库中设置和实施CPU,内存和并发事务限制。定义资源组后,可以将该组分配给一个或多个Greenplum数据库角色,或分配给外部组件(如PL /Container),以便控制这些角色或组件使用的资源。
当用户将资源组分配到角色(基于角色的资源组),用户定义该组的资源限制应用于所有的该组的所有角色。例如,对于一个资源组的内存限制标识了该组所有Greenplum数据库用户提交的运行事务的最大内存使用量。
同样,将资源组分配给外部组件时,组限制将应用于组件的所有正在运行的实例。 例如,如果为PL/Container外部组件创建资源组,则为组定义的内存限制将指定为其分配组的每个PL/Container运行时的所有正在运行的实例的最大内存使用量。
该章节包含以下小节
Parent topic: 管理资源
理解角色和组件资源组
Greenplum数据库支持两类型型的资源组:管理角色资源的组,以及管理外部组件(如PL/Container)资源的组。
资源组的最常见应用程序是管理不同角色可以在Greenplum数据库群集中并发执行的活动查询的数量。 用户还可以管理Greenplum为每个查询分配的CPU和内存资源量。
角色的资源组使用Linux控制组(cgroup)进行CPU资源管理。Greenplum数据库使用称为vmtracker的内存审计器在内部为这些资源组跟踪虚拟内存。
当用户执行查询时,Greenplum数据库会根据为资源组定义的一组限制来评估查询。如果尚未达到组的资源限制并且查询不会导致组超过并发事务限制,Greenplum数据库会立即执行查询。如果不满足这些条件,Greenplum数据库会对查询进行排队。例如,如果已达到资源组的最大并发事务数,则后续查询将排队,并且必须等待其他查询在运行之前完成。当资源组的并发和内存限制被更改为足够大的值时,Greenplum数据库也可以执行挂起的查询。
在角色的资源组中,事务以先进先出的方式进行评估。 Greenplum数据库定期评估系统的活动工作负载,根据需要重新分配资源和启动/排队作业。
用户还可以使用资源组来管理外部组件(如PL/Container)的CPU和内存资源。 外部组件的资源组使用Linux cgroup来管理组件的总CPU和总内存资源。
Note: Greenplum数据库的容器化部署(例如Greenplum for Kubernetes)可能会创建一组嵌套的cgroup,以管理主机系统资源。 嵌套cgroup会影响Greenplum数据库资源组对CPU百分比,CPU核心和内存的限制(Greenplum数据库外部组件除外)。 Greenplum数据库资源组系统资源限制基于父组的配额。
例如,Greenplum数据库在cgroup演示中运行,Greenplum Database cgroup嵌套在cgroup演示中。 如果cgroup演示配置CPU限制为系统CPU资源的60%且Greenplum数据库资源组CPU限制设置为90%,则主机系统CPU资源的Greenplum数据库限制为54%(0.6 x 0.9)。
嵌套的cgroup不会影响Greenplum数据库外部组件(如PL/Container)的内存限制。 仅当用于管理Greenplum数据库资源的cgroup未嵌套时,才能管理外部组件的内存限制,cgroup配置为顶级cgroup。
有关配置cgroup以供资源组使用的信息,请参阅使用资源组.
资源组的参数和限制
当用户创建一个资源组时,请注意以下几点:
- 通过识别该组存储器是如何审核指定资源组的类型。
- 提供一组限制,用于确定组可用的CPU和内存资源量。
资源组的参数和限制:
限制类型 | 描述 |
---|---|
MEMORY_AUDITOR | 用于资源组的内存审计器。 如果要将资源组分配给角色,则需要vmtracker缺省值)。 指定cgroup以将资源组分配给外部组件。 |
CONCURRENCY | 资源组中允许的最大并发事务数,包括活动和空闲事务。 |
CPU_RATE_LIMIT | 此资源组可用的CPU资源百分比。 |
CPUSET | 为该资源组保留的CPU核心数 |
MEMORY_LIMIT | 该资源组可用的内存资源百分比。 |
MEMORY_SHARED_QUOTA | 提交到该资源组的事务之间共享的内存资源百分比 |
MEMORY_SPILL_RATIO | 内存密集型事务的内存使用阈值。当事务达到此阈值时,它将溢出到磁盘。 |
Note: 不对SET,RESET和SHOW命令强制执行资源限制。
内存审计器
MEMORY_AUDITOR属性通过标识组的内存审计器来指定资源组的类型。 指定vmtrackerMEMORY_AUDITOR的资源组标识角色的资源组。 指定cgroupMEMORY_AUDITOR的资源组标识外部组件的资源组。
默认的MEMORY_AUDITOR是vmtracker。
用户为资源组指定的MEMORY_AUDITOR确定Greenplum数据库是否以及如何使用限制属性来管理CPU和内存资源:
限制类型 | 角色资源组 | 外部组件资源组 |
---|---|---|
CONCURRENCY | 是 | 否;必须为零(0)。 |
CPU_RATE_LIMIT | 是 | 是 |
CPUSET | 是 | 是 |
MEMORY_LIMIT | 是 | Yes |
MEMORY_SHARED_QUOTA | 是 | 视组件决定 |
MEMORY_SPILL_RATIO | 是 | 视组件决定 |
事务并行限制
CONCURRENCY限制控制角色资源组允许的最大并发事务数。
Note: CONCURRENCY限制不适用于外部组件的资源组,对于此类组必须设置为零(0)。
角色的每个资源组在逻辑上被划分为等于CONCURRENCY限制的固定数量的槽。 Greenplum数据库为这些插槽分配相等,固定百分比的内存资源。
角色资源组的默认CONCURRENCY限制值为20。
Greenplum数据库将资源组达到CONCURRENCY限制后提交的任何事务排队。 当正在运行的事务完成时,如果存在足够的内存资源,Greenplum Database将排队并执行最早的排队事务。
用户可以设置服务器配置参数gp_resource_group_bypass来绕过资源组的并行限制。
CPU限制
通过将特定CPU核心分配给组,或通过标识要分配给组的分段CPU资源的百分比,可以配置要为段主机上的资源组保留的CPU资源份额。 Greenplum数据库使用CPUSET和CPU_RATE_LIMIT资源组限制来标识CPU资源分配模式。 配置资源组时,必须仅指定其中一个限制。
用户可以在Greenplum数据库群集中同时使用两种CPU资源分配模式。 用户还可以在运行时更改资源组的CPU资源分配模式。
gp_resource_group_cpu_limit服务器配置参数标识要分配给每个Greenplum数据库段主机上的资源组的系统CPU资源的最大百分比。 无论为组配置的CPU分配模式如何,此限制都将控制段主机上所有资源组的最大CPU使用率。 剩余的未预留CPU资源用于OS内核和Greenplum数据库辅助守护进程。 默认的gp_resource_group_cpu_limit值为.9(90%)。
Note: 如果用户在Greenplum数据库群集节点上运行其他工作负载,则默认的gp_resource_group_cpu_limit值可能不会留下足够的CPU资源,因此请务必相应地调整此服务器配置参数。
Warning: 避免将gp_resource_group_cpu_limit设置为高于.9的值。 这样做可能会导致高工作负载查询接近所有CPU资源,可能使Greenplum数据库辅助进程匮乏。
按核心数分配CPU资源
用户可以使用CPUSET属性标识要为资源组保留的CPU核心。 用户指定的CPU核心必须在系统中可用,并且不能与为其他资源组保留的任何CPU核心重叠。 (尽管Greenplum数据库使用用户专门为该组分配给资源组的核心,但请注意,系统中的非Greenplum进程也可以使用这些CPU核心。)
配置CPUSET时,请指定以逗号分隔的单核数字或数字间隔列表。必须将核心数字/间隔用单引号括起来,例如“1,3-4”。
将CPU核心分配给CPUSET组时,请考虑以下事项:
- 使用CPUSET创建的资源组仅使用指定的核心。如果组中没有正在运行的查询,则保留的核心处于空闲状态,并且其他资源组中的查询无法使用这些核心。 请考虑最小化CPUSET组的数量以避免浪费系统CPU资源。
- CPU核心0未分配:在以下情况下,CPU核心0用作回退机制:
- admin_group和default_group至少需要一个CPU核心。 保留所有CPU内核后,Greenplum Database会将CPU内核0分配给这些默认组。 在这种情况下,用户为其分配CPU核心0的资源组与admin_group和default_group共享核心。
- 如果通过一个节点替换重新启动Greenplum数据库集群,并且节点没有足够的内核来为所有CPUSET资源组提供服务,则会自动为这些组分配CPU核心0以避免系统启动失败。
- 将核心分配给资源组时,请使用尽可能少的核心编号。 如果替换Greenplum数据库节点并且新节点的CPU核心数少于原始节点,或者备份数据库并希望在具有较少CPU核心的节点的群集上还原它,则操作可能会失败。 例如,如果用户的Greenplum数据库群集有16个核心,则分配核心1-7是最佳选择。 如果创建资源组并将CPU核心9分配给该组,则数据库还原到8核心节点将失败。
使用CPUSET配置的资源组在CPU资源上具有更高的优先级。 在段主机上配置了CPUSET的所有资源组的最大CPU资源使用百分比是保留的CPU核心数除以所有CPU核心数乘以100。
为资源组配置CPUSET时,Greenplum数据库会禁用组的CPU_RATE_LIMIT并将值设置为-1。
Note: 在为Greenplum数据库群集启用基于资源组的资源管理后,必须为资源组配置CPUSET。
按百分比分配CPU资源
Greenplum数据库节点CPU百分比在Greenplum节点上的每个段之间平均分配。 使用CPU_RATE_LIMIT配置的每个资源组都保留用于资源管理的段CPU的指定百分比。
用户可以为资源组指定的最小CPU_RATE_LIMIT百分比为1,最大值为100。
在Greenplum数据库群集中定义的所有资源组指定的CPU_RATE_LIMIT的总和不得超过100。
使用CPU_RATE_LIMIT在段主机上配置的所有资源组的最大CPU资源使用量是以下值中的最小值:
- 非保留CPU核心数除以所有CPU核心数乘以100,和
- gp_resource_group_cpu_limit值。
配置有CPU_RATE_LIMIT的资源组的CPU资源分配是弹性的,因为Greenplum数据库可以将空闲资源组的CPU资源分配给更繁忙的资源组。在这种情况下,当该资源组接下来变为活动时,CPU资源被重新分配给先前空闲的资源组。如果多个资源组繁忙,则根据其CPU_RATE_LIMIT的比率为它们分配任何空闲资源组的CPU资源。例如,使用CPU_RATE_LIMIT为40创建的资源组将分配两倍于使用CPU_RATE_LIMIT 为20创建的资源组的额外CPU资源。
为资源组配置CPU_RATE_LIMIT时,Greenplum数据库会禁用组的CPUSET并将值设置为-1。
内存限制
启用资源组后,将在Greenplum数据库节点,段和资源组级别管理内存使用情况。用户还可以使用角色资源组在事务级别管理内存。
gp_resource_group_memory_limit服务器配置参数标识要分配给每个Greenplum数据库段主机上的资源组的系统内存资源的最大百分比。默认的gp_resource_group_memory_limit值为.7(70%)。
Greenplum数据库节点上可用的内存资源在节点上的每个段之间进一步平均分配。当基于资源组的资源管理处于活动状态时,分配给段主机上每个段的内存量是Greenplum数据库可用的内存乘以gp_resource_group_memory_limit服务器配置参数,并除以主机上活动主段的数量:
rg_perseg_mem = ((RAM * (vm.overcommit_ratio / 100) + SWAP) * gp_resource_group_memory_limit) / num_active_primary_segments
每个资源组保留用于资源管理的段内存的百分比。用户可以通过在创建资源组时指定的MEMORY_LIMIT值来标识此百分比。用户可以为资源组指定的最小MEMORY_LIMIT百分比为1,最大值为100。
在Greenplum数据库群集中定义的所有资源组指定的MEMORY_LIMIT总和不得超过100。
于角色的资源组的附加内存限制
资源组为角色保留的内存进一步分为固定和共享组件。创建资源组时指定的MEMORY_SHARED_QUOTA值标识可在当前运行的事务之间共享的预留资源组内存的百分比。此记忆按先到先得的原则分配。正在运行的事务可以使用MEMORY_SHARED_QUOTA中的任何一个,一些或全部。
用户可以指定的最小MEMORY_SHARED_QUOTA为0,最大值为100.默认MEMORY_SHARED_QUOTA为20。
如前所述,CONCURRENCY标识角色资源组中允许的最大并发运行事务数。由资源组保留的固定存储器被分成CONCURRENCY个事务槽数。每个插槽分配一个固定的,相等数量的资源组内存。Greenplum数据库会保证每个事务的固定内存。
Figure 1. 资源组内存分配
当查询的内存使用量超过固定的每事务内存使用量时,Greenplum数据库会将可用的资源组共享内存分配给查询。特定事务槽可用的最大资源组内存量是事务的固定内存和完整资源组共享内存分配的总和。
全局共享内存
为所有资源组(包括默认admin_group和default_group组)配置的MEMORY_LIMIT的总和标识预留资源组内存的百分比。如果此总和小于100,则Greenplum数据库会将任何未预留的内存分配给资源组全局共享内存池。
资源组全局共享内存仅适用于使用vmtracker内存审计器配置的资源组。
在可用时,Greenplum数据库在首次分配插槽和资源组共享内存后为事务分配全局共享内存。Greenplum数据库以先到先得的方式为事务分配资源组全局共享内存。
Note: Greenplum数据库跟踪但不主动监视资源组中的事务内存使用情况。如果资源组的内存使用量超过其固定内存分配,则在满足以下所有条件时,资源组中的事务将失败:
- 没有可用的资源组共享内存。
- 没有可用的全局共享内存。
- 该事务请求额外的内存。
当用户为全局共享内存池保留一些未分配的内存(例如,10-20%)时,Greenplum数据库会更有效地使用资源组内存。全局共享内存的可用性还有助于缓解内存消耗或不可预测的查询失败。
查询运算符内存
大多数查询运算符都是非内存密集型的; 也就是说,在处理过程中,Greenplum数据库可以将其数据保存在已分配的内存中。当内存密集型查询运算符(如连接和排序)处理的数据多于可以保存在内存中的数据时,数据会溢出到磁盘。
gp_resgroup_memory_policy服务器配置参数控制所有查询运算符的内存分配和分配算法。Greenplum数据库支持eager-free(默认)和资源组的自动内存策略。当用户指定自动策略时,Greenplum数据库使用资源组内存限制在查询运算符之间分配内存,为非内存密集型运算符分配固定大小的内存,其余为内存密集型运算符。当eager_free策略到位时,Greenplum数据库通过在稍后的查询阶段将已完成处理的运算符释放的内存重新分配给运算符,从而更好地在运算符之间分配内存。
MEMORY_SPILL_RATIO标识事务中内存密集型运算符的内存使用阈值。达到此阈值时,事务将溢出到磁盘。Greenplum数据库使用MEMORY_SPILL_RATIO来确定要分配给事务的初始内存。
可以为资源组指定的最小MEMORY_SPILL_RATIO百分比为0.最大值为100.默认MEMORY_SPILL_RATIO为20。
在为角色创建资源组时定义MEMORY_SPILL_RATIO,用户可以使用memory_spill_ratio服务器配置参数在会话级别基于每个查询选择性地设置此限制。
memory_spill_ratio和低内存查询
低memory_spill_ratio设置(例如,在0-2%范围内)已被证明可以提高具有低内存要求的查询的性能。使用memory_spill_ratio服务器配置参数可以基于每个查询覆盖该设置。例如:
SET memory_spill_ratio=0;
其他内存注意事项
角色的资源组跟踪通过palloc()函数分配的所有Greenplum数据库内存。使用Linuxpalloc()函数分配的内存不受这些资源组的管理。要确保角色的资源组准确跟踪内存使用情况,请避免使用malloc()在自定义Greenplum数据库用户定义函数中分配大量内存。
使用资源组
Important: 在RedHat 6.x和CentOS 6.x系统上启用基于资源组的工作负载管理时,已观察到显着的Greenplum数据库性能下降。此问题是由Linux cgroup内核错误引起的。这个内核错误已在CentOS 7.x和Red Hat 7.x系统中修复。
如果用户使用RedHat 6并且资源组的性能对于用户的用例是可接受的,请将用户的内核升级到版本2.6.32-696或更高版本,以便从cgroups实现的其他修复程序中受益。
条件
Greenplum数据库资源组使用Linux控制组(cgroup)来管理CPU资源。Greenplum数据库还使用cgroup来管理外部组件的资源组的内存。使用cgroups,Greenplum将Greenplum进程的CPU和外部组件内存使用与节点上的其他进程隔离开来。这允许Greenplum在每个资源组的基础上支持CPU和外部组件内存使用限制。
有关cgroup的详细信息,请参阅Linux发行版的控制组文档。
在Greenplum数据库群集中的每个节点上完成以下任务,以设置用于资源组的cgroup:
- 如果用户在Greenplum数据库群集节点上运行SuSE 11+操作系统,则必须在每个节点上启用交换记帐并重新启动Greenplum数据库群集。swapaccount内核引导参数控制SuSE 11+系统上的交换记帐设置。设置此引导参数后,必须重新引导系统。有关详细信息,请参阅SuSE 11发行说明中的Cgroup交换控制讨论。用户必须是超级用户或具有sudo访问权限才能配置内核引导参数和重新引导系统。
创建Greenplum数据库cgroups配置文件/etc/cgconfig.d/gpdb.conf。用户必须是超级用户或具有sudo访问权限才能创建此文件:
sudo vi /etc/cgconfig.d/gpdb.conf
将以下配置信息添加到 /etc/cgconfig.d/gpdb.conf:
group gpdb {
perm {
task {
uid = gpadmin;
gid = gpadmin;
}
admin {
uid = gpadmin;
gid = gpadmin;
}
}
cpu {
}
cpuacct {
}
cpuset {
}
memory {
}
}
此内容配置由gpadmin用户管理的CPU,CPU计算,CPU核心集和内存控制组。Greenplum数据库仅将内存控制组用于使用cgroupMEMORY_AUDITOR创建的资源组。
如果尚未安装并正在运行,请安装Control Groups操作系统软件包,并在每个Greenplum Database节点上启动cgroups服务。用户运行以执行这些任务的命令将根据节点上安装的操作系统而有所不同。用户必须是超级用户或具有sudo访问权限才能运行这些命令:
Redhat/CentOS 7.x 系统:
sudo yum install libcgroup-tools
sudo cgconfigparser -l /etc/cgconfig.d/gpdb.conf
Redhat/CentOS 6.x systems:
sudo yum install libcgroup
sudo service cgconfig start
SuSE 11+ systems:
sudo zypper install libcgroup-tools
sudo cgconfigparser -l /etc/cgconfig.d/gpdb.conf
标识节点的cgroup目录安装点:
grep cgroup /proc/mounts
第一行输出标识cgroup挂载点。
通过运行以下命令验证是否正确设置了Greenplum Database cgroups配置。将
替换为用户在上一步中标识的安装点: ls -l <cgroup_mount_point>/cpu/gpdb
ls -l <cgroup_mount_point>/cpuacct/gpdb
ls -l <cgroup_mount_point>/cpuset/gpdb
ls -l <cgroup_mount_point>/memory/gpdb
如果这些目录存在且由gpadmin:gpadmin拥有,则用户已成功为Greenplum数据库CPU资源管理配置了cgroup。
要在系统重新启动时自动重新创建Greenplum数据库所需的cgroup层次结构和参数,请将系统配置为启用Linux cgroup服务守护程序cgconfig.service(Redhat / CentOS 7.x和SuSE 11+)或cgconfig(Redhat / CentOS 6.x) )节点启动时。例如,在首选服务自动启动工具中配置以下cgroup服务命令之一:
Redhat/CentOS 7.x 和 SuSE11+ 系统:
sudo systemctl enable cgconfig.service
Redhat/CentOS 6.x systems:
sudo chkconfig cgconfig on
用户可以选择其他方法来重新创建Greenplum数据库资源组cgroup层次结构。
程序
要在Greenplum数据库群集中使用资源组,用户需要:
启用资源组
安装Greenplum Database时,默认情况下会启用资源队列。要使用资源组而不是资源队列,必须设置gp_resource_manager服务器配置参数。
将gp_resource_manager服务器配置参数设置为值”group”:
gpconfig -s gp_resource_manager
gpconfig -c gp_resource_manager -v "group"
重启Greenplum 数据库:
gpstop
gpstart
启用后,角色提交的任何事务都将定向到分配给该角色的资源组,并受该资源组的并发,内存和CPU限制的约束。同样,外部组件的CPU和内存使用量由为分配给组件的资源组配置的CPU和内存限制控制。
Greenplum数据库为名为admin_group和default_group的角色创建两个默认资源组。启用资源组时,将为未明确分配资源组的任何角色分配角色功能的默认组。SUPERUSER角色分配了admin_group,非管理员角色分配了名为default_group的组。
使用以下资源限制创建默认资源组admin_group和default_group:
限制类型 | admin_group | default_group |
---|---|---|
CONCURRENCY | 10 | 20 |
CPU_RATE_LIMIT | 10 | 30 |
CPUSET | -1 | -1 |
MEMORY_LIMIT | 10 | 30 |
MEMORY_SHARED_QUOTA | 50 | 50 |
MEMORY_SPILL_RATIO | 20 | 20 |
MEMORY_AUDITOR | vmtracker | vmtracker |
请记住,默认资源组admin_group和default_group的CPU_RATE_LIMIT和MEMORY_LIMIT值对分段主机上的总百分比有贡献。在创建Greenplum数据库部署并将新资源组添加到Greenplum数据库部署时,用户可能会发现需要为admin_group和/或default_group调整这些限制。
创建资源组
为角色创建资源组时可以提供名称,CPU资源分配模式和内存限制。用户可以选择提供并发事务限制和内存共享配额和溢出比率。使用CREATE RESOURCE GROUP命令创建新资源组。
为角色创建资源组时,必须提供CPU_RATE_LIMIT或CPUSET和MEMORY_LIMIT限制值。这些限制标识要分配给此资源组的Greenplum数据库资源的百分比。例如,要创建名为rgroup1的资源组,其CPU限制为20,内存限制为25:
=# CREATE RESOURCE GROUP rgroup1 WITH (CPU_RATE_LIMIT=20, MEMORY_LIMIT=25);
CPU限制为20由rgroup1分配到的每个角色共享。同样,内存限制为25由rgroup1分配到的每个角色共享。rgroup1使用默认的MEMORY_AUDITORvmtracker和默认的CONCURRENCY设置为20。
为外部组件创建资源组时,必须提供CPU_RATE_LIMIT或CPUSET和MEMORY_LIMIT限制值。用户还必须提供MEMORY_AUDITOR并将CONCURRENCY显式设置为零(0)。例如,要创建名为rgroup_extcomp的资源组,请为其保留CPU核心1并指定内存限制为15:
=# CREATE RESOURCE GROUP rgroup_extcomp WITH (MEMORY_AUDITOR=cgroup, CONCURRENCY=0,
CPUSET='1', MEMORY_LIMIT=15);
The ALTER RESOURCE GROUP 命令更新资源组的限制。要更改资源组的限制,请指定组所需的新值。例如:
=# ALTER RESOURCE GROUP rg_role_light SET CONCURRENCY 7;
=# ALTER RESOURCE GROUP exec SET MEMORY_LIMIT 25;
=# ALTER RESOURCE GROUP rgroup1 SET CPUSET '2,4';
Note: 用户无法将admin_group的CONCURRENCY值设置或更改为零(0)。
DROP RESOURCE GROUP命令会删除资源组。要删除角色的资源组,不能将该组分配给任何角色,也不能在资源组中激活或等待任何事务。删除正在运行的实例的外部组件的资源组会导致正在运行的实例。
删除资源组:
=# DROP RESOURCE GROUP exec;
将资源组分配给角色
使用默认MEMORY_AUDITORvmtracker创建资源组时,该组可用于分配给一个或多个角色(用户)。使用CREATE ROLE或ALTER ROLE命令的RESOURCE GROUP子句将资源组分配给数据库角色。如果未为角色指定资源组,则会为角色分配角色功能的默认组。SUPERUSER角色分配了admin_group,非管理员角色分配了名为default_group的组。
使用ALTER ROLE或CREATE ROLE命令将资源组分配给角色。例如:
=# ALTER ROLE bill RESOURCE GROUP rg_light;
=# CREATE ROLE mary RESOURCE GROUP exec;
用户可以将资源组分配给一个或多个角色。如果已定义角色层次结构,则将资源组分配给父角色不会向下传播到该角色组的成员。
Note: 用户无法将为外部组件创建的资源组分配给角色。
如果要从角色中删除资源组分配并将角色分配为默认组,请将角色的组名称分配更改为NONE。例如:
=# ALTER ROLE mary RESOURCE GROUP NONE;
监视资源组状态
监视资源组和查询的状态可能涉及以下任务:
查看资源组限制
The gp_resgroup_config gp_toolkit系统视图显示资源组的当前和建议限制。当用户更改限制时,建议的限制与当前限制不同,但不能立即应用新值。如果要查看所有资源组的限制:
=# SELECT * FROM gp_toolkit.gp_resgroup_config;
查看资源组查询状态和CPU/内存使用情况
gp_resgroup_status gp_toolkit系统视图可以查看资源组的状态和活动。该视图显示正在运行和排队的事务数。它还显示资源组的实时CPU和内存使用情况。要查看此信息:
=# SELECT * FROM gp_toolkit.gp_resgroup_status;
查看每个主机的资源组CPU/内存使用情况
通过gp_resgroup_status_per_host gp_toolkit系统视图,用户可以基于每个主机查看资源组的实时CPU和内存使用情况。要查看此信息:
=# SELECT * FROM gp_toolkit.gp_resgroup_status_per_host;
查看每个段的资源组CPU/内存使用情况
通过gp_resgroup_status_per_segment gp_toolkit系统视图,用户可以按每个段,每个主机查看资源组的实时CPU和内存使用情况。要查看此信息:
=# SELECT * FROM gp_toolkit.gp_resgroup_status_per_segment;
查看分配给角色的资源组
要查看资源组到角色分配,请对 pg_roles 和 pg_resgroup系统目录表执行以下查询:
=# SELECT rolname, rsgname FROM pg_roles, pg_resgroup
WHERE pg_roles.rolresgroup=pg_resgroup.oid;
查看资源组的运行和待定查询
要查看资源组的运行查询,挂起的查询以及挂起的查询排队的时间,请检查pg_stat_activity系统目录表:
=# SELECT current_query, waiting, rsgname, rsgqueueduration
FROM pg_stat_activity;
pg_stat_activity显示有关启动查询的用户/角色的信息。使用外部组件(如PL/Container)的查询由两部分组成:在Greenplum数据库中运行的查询运算符和在PL/Container实例中运行的UDF。Greenplum数据库处理分配给发起查询的角色的资源组下的查询运算符。在PL/Container实例中运行的UDF在分配给PL/Container运行时的资源组下运行。后者没有在pg_stat_activity中表示; Greenplum数据库无法深入了解PL/Container等外部组件如何在运行实例中管理内存。
取消资源组中的正在运行或已排队的事务
在某些情况下,用户可能希望取消资源组中的正在运行或排队的事务。例如,用户可能希望删除在资源组队列中等待但尚未执行的查询。或者,用户可能希望停止执行时间太长的正在运行的查询,或者在事务中处于空闲状态并占用其他用户所需的资源组事务插槽的查询。
要取消正在运行或排队的事务,必须首先确定与事务关联的进程ID(pid)。获得进程ID后,可以调用pg_cancel_backend()来结束该进程,如下所示。
例如,要查看与当前活动或在所有资源组中等待的所有语句关联的进程信息,请运行以下查询。如果查询未返回任何结果,则任何资源组中都没有正在运行或排队的事务。
=# SELECT rolname, g.rsgname, procpid, waiting, current_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;
示例部分查询输出:
rolname | rsgname | procpid | waiting | current_query | datname
---------+----------+---------+---------+-----------------------+---------
sammy | rg_light | 31861 | f | <IDLE> in transaction | testdb
billy | rg_light | 31905 | t | SELECT * FROM topten; | testdb
使用此输出来标识要取消的事务的进程ID(procpid),然后取消该进程。例如,要取消上面示例输出中标识的待处理查询:
=# SELECT pg_cancel_backend(31905);
用户可以在pg_cancel_backend()的第二个参数中提供可选消息,以向用户指示进程被取消的原因。
Note:
不要使用操作系统KILL命令取消任何Greenplum数据库进程。
资源组常见问题解答
CPU
为什么CPU使用率低于为资源组配置的CPU_RATE_LIMIT?
当资源组中运行的查询和片数较少时,您可能会遇到这种情况,并且这些进程未使用系统上的所有核心。
为什么资源组的CPU使用率高于配置的CPU_RATE_LIMIT?
在下列情况下可能会发生这种情况:
- 当其他资源组空闲时,资源组可以使用比其CPU_RATE_LIMIT更多的CPU。在这种情况下,Greenplum数据库将空闲资源组的CPU资源分配给更繁忙的资源组。此资源组功能称为CPU突发。
- 操作系统CPU调度程序可能导致CPU使用率出现峰值,然后下降。如果您认为可能发生这种情况,请计算给定时间段内的平均CPU使用率(例如,5秒),并使用该平均值来确定CPU使用率是否高于配置的限制。
内存
为什么我的查询返回“内存不足”错误?
在资源组中提交的事务失败并在内存使用超过其固定内存分配时退出,不存在可用资源组共享内存,并且事务请求更多内存。
为什么我的查询返回“达到内存限制”错误?
当您使用ALTER RESOURCE GROUP更改资源组的内存和/或并发限制时,Greenplum数据库会自动将事务和组内存调整为新设置。如果您最近更改了资源组属性并且当前正在运行的查询不再有足够的可用内存,则可能会出现“内存不足”错误。
为什么我的资源组的实际内存使用量超过为该组配置的数量?
当从组中运行的一个或多个查询从全局共享内存池分配内存时,资源组的实际内存使用量可能超过配置的量。(如果没有可用的全局共享内存,查询将失败,并且不会影响其他资源组的内存资源。)
当全局共享内存可用时,当事务溢出到磁盘时,内存使用量也可能超过配置的量。Greenplum数据库语句在开始溢出到磁盘时继续请求内存,因为:
- 溢出到磁盘需要额外的内存才能工作。
- 其他运营商可能会继续请求内存。
泄漏情况下内存使用量增加;当全局共享内存可用时,资源组最终可能最多使用其配置的组内存限制的200-300%。
并发
为什么运行事务的数量低于为资源组配置的CONCURRENCY限制?
Greenplum数据库在运行事务之前考虑内存可用性,如果没有足够的内存可供服务,它将对事务进行排队。如果使用ALTER RESOURCE GROUP增加资源组的CONCURRENCY限制但不调整内存限制,则当前正在运行的事务可能会占用该组的所有分配的内存资源。处于此状态时,Greenplum数据库会对资源组中的后续事务进行排队。
为什么资源组中正在运行的事务数高于配置的CONCURRENCY限制?
资源组可能正在运行SET和SHOW命令,这些命令会绕过资源组事务检查。