原 GreenPlum 7中的资源组
简介
在GPDB7中的资源组中,和GPDB6的限制发生了很大变化。
gpcc变化
在GP7中:
在GP6中:
对比
指标 | Greenplum 6中的资源组 | Greenplum 7中的资源组 |
---|---|---|
并发性 | 在事务级别管理 | 在事务级别管理 |
CPU | 指定CPU资源的百分比或CPU核心的数量;使用Linux控制组 | 指定CPU资源的百分比或CPU核心的数量,并为每个资源组设置上限;使用Linux控制组 |
内存 | 在事务级别管理,具有增强的分配和跟踪;用户无法超额订阅 | 在事务级别管理,具有增强的分配和跟踪;用户可以超额订阅;配置更简单方便 |
磁盘I/O | 无 | 限制最大读/写磁盘I/O吞吐量和每秒最大读/写I/O操作数 Disk I/O limits are only available when you use Linux Control Groups v2. |
用户 | 限制适用于超级用户和非管理员用户 | 限制适用于超级用户、非管理员用户以及非用户类的系统进程 |
排队 | 当没有可用的插槽或没有足够的可用内存时排队 | 当没有可用的插槽时排队 |
查询失败 | 当达到事务固定内存限制且没有共享资源组内存时,查询可能会失败,并且事务请求更多内存 | 如果查询分配的内存超过系统可用内存和溢出限制,查询可能会失败 |
限制绕过 | 对SET、RESET和SHOW命令不强制执行限制 | 对SET、RESET和SHOW命令不强制执行限制。此外,某些查询可以配置绕过并发限制 |
外部组件 | 管理PL/Container的CPU和内存资源 | 管理PL/Container的CPU资源 |
资源组属性的变化
可以使用 CREATE RESOURCE GROUP
和 ALTER RESOURCE GROUP
SQL 命令配置四个新的资源组属性:
- CPU_MAX_PERCENT:配置资源组可以使用的最大CPU资源量。
- CPU_WEIGHT:配置资源组的调度优先级。
- MIN_COST:配置查询的查询计划成本的最小值,以便查询能够保持在资源组中。
- IO_LIMIT:配置设备I/O使用情况,以在资源组级别管理最大读/写操作吞吐量和每秒最大读/写操作数。
以下资源组属性已被移除:
- CPU_RATE_LIMIT
- MEMORY_AUDITOR
- MEMORY_SPILL_RATIO
- MEMORY_SHARED_QUOTA
参数的变化
Greenplum 7 资源组管理引入了以下服务器配置参数的更改:
- gp_resource_manager 服务器配置参数的可设置值发生了变化。现在包括以下选项:
- none:配置 Greenplum Database 不使用任何资源管理器。这是默认设置。
- group:配置 Greenplum Database 使用资源组,并基于 cgroup v1 版本的 Linux cgroup 功能进行资源组行为管理。
- group-v2:配置 Greenplum Database 使用资源组,并基于 cgroup v2 版本的 Linux cgroup 功能进行资源组行为管理。
- queue:配置 Greenplum Database 使用资源队列。
- 新的服务器配置参数 gp_resgroup_memory_query_fixed_mem 允许您在会话级别覆盖为资源组中所有查询保留的固定内存量。
- 新的服务器配置参数 gp_resource_group_move_timeout 如果 pg_resgroup_move_query() 函数(用于将正在运行的查询从一个资源组移动到另一个资源组)等待超过指定的毫秒数,则会取消该操作。
- 新的服务器配置参数 gp_resource_group_bypass_direct_dispatch 绕过资源组的限制,使得直接调度查询可以立即运行。直接调度查询是一种特殊类型的查询,只需要一个段参与执行。
- 服务器配置参数 gp_resource_group_cpu_ceiling_enforcement 已被移除。
- 服务器配置参数 gp_resource_group_enable_recalculate_query_mem 已被移除。
- 服务器配置参数 gp_resource_group_memory_limit 已被移除。
系统视图变化
系统视图的更改
以下系统视图发生了更改:
- 在 gp_resgroups_config 系统视图中,字段 cpu_rate_limit、memory_shared_quota、memory_spill_ratio 和 memory_auditor 已被 cpu_max_percent、cpu_weight、cpuset、min_cost 和 io_limit 替代。
- 在 gp_resgroup_status 系统视图中,字段 rsgname 已重命名为 groupname。
- 在 gp_resgroup_status 系统视图中,字段 cpu_usage 和 memory_usage 已移除,转移至 gp_resgroup_status_per_host 系统视图。
- 在 gp_resgroup_status_per_host 系统视图中,字段 hostname、cpu、memory_used、memory_available、memory_quota_used、memory_quota_available、memory_shared_used 和 memory_shared_available 已移除。新增字段 segment_id、cpu_usage 和 memory_usage。
- 在 gp_resgroup_status_per_segment 系统视图中,字段 rsgname、hostname、cpu、memory_used、memory_available、memory_quota_used、memory_quota_available、memory_shared_used 和 memory_shared_available 已移除。新增字段 groupname 和 vmem_usage。
- 新增了 gp_resgroup_iostats_per_host 系统视图。
Disk I/O Limits
Greenplum Database 利用 Linux 控制组(control groups)来实现磁盘 I/O 限制。参数 IO_LIMIT 用于限制分配到特定资源组的查询的最大读写磁盘 I/O 吞吐量,以及最大读写 I/O 操作每秒数(IOPS)。它可以分配带宽,确保高优先级资源组的使用,并避免磁盘带宽的过度消耗。该参数的值是基于每个表空间进行设置的。
磁盘 I/O 限制仅在使用 Linux 控制组 v2 时可用。有关详细信息,请参阅 Configuring and Using Resource Groups for more information.
Greenplum Database 的资源组使用 Linux 控制组(cgroups)来管理 CPU 资源和磁盘 I/O。cgroups 有两个版本:cgroup v1 和 cgroup v2。Greenplum Database 7 支持这两个版本,但参数 IO_LIMIT 仅支持 cgroup v2。 Linux 发行版默认提供的控制组版本取决于操作系统版本。对于 Enterprise Linux 8 及更早版本,默认版本为 v1;对于 Enterprise Linux 9 及更新版本,默认版本为 v2。
可以通过检查系统启动时默认挂载的文件系统来验证环境中配置的 cgroup 版本:
1 | stat -fc %T /sys/fs/cgroup/ |
对于 cgroup v1,输出为 tmpfs。
对于 cgroup v2,输出为 cgroup2fs。
从 cgroup v1 切换到 v2,请以 root 用户运行以下命令:
Red Hat 8/Rocky 8/Oracle 8 systems:
1 | grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="systemd.unified_cgroup_hierarchy=1" |
详情请参考官方文档。
资源组属性和限制
在创建资源组时,需要提供一组限制,决定该组可以使用的 CPU 和内存资源量。以下表格列出了资源组的可用限制:
限制类型 | 描述 | 值范围 | 默认值 |
---|---|---|---|
CONCURRENCY | 资源组中允许的最大并发事务数,包括活动事务和空闲事务。 | [0 - max_connections] | 20 |
CPU_MAX_PERCENT | 该资源组可以使用的最大 CPU 资源百分比。 | [1 - 100] | -1(未设置) |
CPU_WEIGHT | 资源组的调度优先级。 | [1 - 500] | 100 |
CPUSET | 为该资源组保留的特定 CPU 逻辑核心(或超线程中的逻辑线程)。 | 取决于系统核心配置 | -1(未设置) |
IO_LIMIT | 最大读/写磁盘 I/O 吞吐量限制,以及每秒最大读/写 I/O 操作数。基于每个表空间设置值。 | [2 - 4294967295 或 max] | -1(未设置) |
MEMORY_QUOTA | 为资源组指定的内存限制值。 | 整数(MB) | -1(未设置,使用 statement_mem 作为单个查询的内存限制) |
MIN_COST | 查询计划包含在资源组中的最低成本。 | 整数 | 0 |
- SET、RESET 和 SHOW 命令不强制执行资源限制。
事务并发限制CONCURRENCY
CONCURRENCY 限制控制了资源组允许的最大并发事务数。
每个资源组在逻辑上被划分为与 CONCURRENCY 限制相等的固定数量的槽。Greenplum 数据库为这些槽分配相等的固定比例内存资源。
资源组的默认 CONCURRENCY 限制值为 20。值为 0 表示该资源组不允许任何查询运行。
当资源组达到其 CONCURRENCY 限制后,Greenplum 数据库会将提交的事务排队。当一个正在运行的事务完成后,如果有足够的内存资源,Greenplum 数据库将从队列中取出最早的事务并执行。请注意,即使没有运行语句,如果事务处于“空闲事务”状态,事务槽仍然被占用。
您可以设置服务器配置参数 gp_resource_group_queuing_timeout
来指定事务在队列中等待的时间,超过该时间后,Greenplum 数据库将取消该事务。默认超时时间为零,表示 Greenplum 会无限期地排队事务。
绕过和取消分配资源组
绕过和取消分配资源组
如果您设置服务器配置参数 gp_resource_group_bypass
,查询将绕过资源组的并发限制。此参数启用或禁用资源组的并发事务限制,使查询能够立即执行。默认值为 false
,表示强制执行 CONCURRENCY
限制。您只能为单个会话设置此参数,不能在事务或函数中设置。如果将 gp_resource_group_bypass
设置为 true
,则查询将不再强制执行分配给其资源组的 CPU 或内存限制。相反,该查询的内存配额为每个查询的 statement_mem
。如果没有足够的内存来满足内存分配请求,查询将失败。
您可以绕过仅使用目录表的查询,例如数据库图形用户界面(GUI)客户端,该客户端运行目录查询以获取元数据。如果服务器配置参数 gp_resource_group_bypass_catalog_query
设置为 true
(默认值),Greenplum 数据库的资源组调度器将绕过所有仅从系统目录读取的查询,或仅包含 pg_catalog
架构表的查询。这些查询将自动取消分配当前资源组;它们不会强制执行资源组的限制,也不计算资源使用。查询资源将被从资源组中分配并立即运行。该查询的内存配额为 statement_mem
。
您可以使用服务器配置参数 gp_resource_group_bypass_direct_dispatch
绕过直接调度查询。直接调度查询是一种特殊类型的查询,只需要一个段参与执行。为了提高效率,Greenplum 对这种类型的查询进行了优化,使用直接调度优化。系统将查询计划发送到需要执行该计划的单个段,而不是将其发送到所有段进行执行。如果将 gp_resource_group_bypass_direct_dispatch
设置为 true
,查询将不再强制执行分配给其资源组的 CPU 或内存限制,因此它将立即运行。相反,该查询的内存配额为每个查询的 statement_mem
。如果没有足够的内存来满足内存分配请求,查询将失败。您只能为单个会话设置此参数,不能在事务或函数中设置。
计划成本小于 MIN_COST
限制的查询将自动取消分配其资源组,并且不强制执行任何限制。查询使用的资源不会计入资源组的资源。该查询的内存配额为 statement_mem
。MIN_COST
的默认值为 0。
CPU 限制
Greenplum 数据库利用 Linux 控制组实现 CPU 资源管理。Greenplum 数据库以两种方式分配 CPU 资源:
- 将一定比例的 CPU 资源分配给资源组。
- 将特定的 CPU 核心分配给资源组。
当您为资源组设置其中一种分配模式时,Greenplum 数据库将停用另一种分配模式。您可以在同一个 Greenplum 数据库集群中为不同的资源组同时使用这两种 CPU 资源分配模式。您还可以在运行时更改资源组的 CPU 资源分配模式。
Greenplum 数据库使用服务器配置参数 gp_resource_group_cpu_limit
来确定为每个 Greenplum 数据库段节点分配的系统 CPU 资源的最大百分比。剩余的未保留 CPU 资源将用于操作系统内核和 Greenplum 数据库守护进程。每个主机上可供 Greenplum 数据库查询使用的 CPU 资源将均匀分配给 Greenplum 节点上的每个段。
- 默认的
gp_resource_group_cpu_limit
值可能无法为您在 Greenplum 数据库集群节点上运行的其他工作负载留出足够的 CPU 资源,因此请根据需要相应地调整此服务器配置参数。 - 避免将
gp_resource_group_cpu_limit
设置为高于 0.9 的值。这样做可能导致高工作负载查询几乎占用所有 CPU 资源,可能会导致 Greenplum 数据库的辅助进程无法获得足够的 CPU 资源。
通过核心分配 CPU 资源
您可以使用 CPUSET
属性指定要为资源组保留的 CPU 核心。您指定的 CPU 核心必须在系统中可用,并且不能与您为其他资源组保留的 CPU 核心重叠。尽管 Greenplum 数据库将您分配给资源组的核心专门用于该组,但请注意,这些 CPU 核心也可能被系统中的非 Greenplum 进程使用。当您为资源组配置 CPUSET
时,Greenplum 数据库将停用该组的 CPU_MAX_PERCENT
和 CPU_WEIGHT
设置,并将其值设置为 -1。
为协调主机和段主机单独指定 CPU 核心,并用分号分隔。配置 CPUSET
的核心时,请使用逗号分隔的核心编号或编号区间列表。您必须将核心编号/区间用单引号括起来,例如,'1;1,3-4'
使用协调主机的核心 1,以及段主机上的核心 1、3 和 4。
为 CPUSET
组分配 CPU 核心时,请考虑以下事项:
- 使用
CPUSET
创建的资源组会专门使用指定的核心。如果组内没有正在运行的查询,则保留的核心处于空闲状态,不能被其他资源组中的查询使用。考虑减少CPUSET
组的数量,以避免浪费系统的 CPU 资源。 - 考虑将 CPU 核心 0 保留为空闲状态。CPU 核心 0 作为以下情况的回退机制:
admin_group
和default_group
至少需要一个 CPU 核心。当所有 CPU 核心都被保留时,Greenplum 数据库会将 CPU 核心 0 分配给这些默认组。在这种情况下,您为其分配了 CPU 核心 0 的资源组将与admin_group
和default_group
共享该核心。- 如果您使用一个节点替换重启 Greenplum 数据库集群,且新节点的核心数不足以为所有
CPUSET
资源组提供服务,则这些组会自动分配 CPU 核心 0 以避免系统启动失败。
- 为资源组分配核心时,使用尽可能低的核心编号。如果您替换 Greenplum 数据库节点,且新节点的 CPU 核心比原节点少,或者如果您备份数据库并希望在一个核心数较少的集群中恢复,操作可能会失败。例如,如果您的 Greenplum 数据库集群有 16 个核心,分配核心 1-7 是最优的。如果您创建了一个资源组并将 CPU 核心 9 分配给该组,在一个 8 核心节点上恢复数据库时将会失败。
为 CPUSET
配置的资源组优先级较高。配置了 CPUSET
的所有资源组在段主机上的最大 CPU 资源使用百分比为保留的 CPU 核心数量除以所有 CPU 核心的数量,再乘以 100。
- 在为 Greenplum 数据库集群启用基于资源组的资源管理后,您必须为资源组配置
CPUSET
,该操作由服务器配置参数gp_resource_manager
控制。
按百分比分配 CPU 资源
您可以通过配置 CPU_MAX_PERCENT
来按百分比分配 CPU 资源。当您为资源组配置 CPU_MAX_PERCENT
时,Greenplum 数据库会停用该组的 CPUSET
。
参数 CPU_MAX_PERCENT
设置了资源管理中段 CPU 的硬性上限百分比。您可以为资源组指定的最小 CPU_MAX_PERCENT
百分比是 1,最大值为 100。您为 Greenplum 数据库集群中定义的所有资源组指定的 CPU_MAX_PERCENT
的总和可以超过 100。它指定了资源组中所有任务可以在给定的 CPU 时间段内运行的总时间比例。一旦资源组中的任务使用完分配的配额时间,它们将在该时间段的剩余时间内被限制,不允许在该时间段内运行,直到下一个时间段。
当资源组中的任务处于空闲状态并且没有使用任何 CPU 时间时,剩余的时间会被收集到一个全球未使用 CPU 周期的池中。其他资源组可以从这个池中借用 CPU 周期。资源组可用的实际 CPU 时间可能会有所不同,这取决于系统中存在的资源组数量。
参数 CPU_MAX_PERCENT
强制实施 CPU 使用的硬性上限。例如,如果设置为 40%,则表示虽然资源组可以临时使用来自其他组的空闲 CPU 资源,但它所能使用的最大值是 Greenplum 可用的 40% 的 CPU 资源。
您可以设置参数 CPU_WEIGHT
来分配当前组的调度优先级。默认值为 100,取值范围为 1 到 500。该值指定了资源组中任务可用的 CPU 时间的相对份额。例如,如果一个资源组的相对份额为 100,而另外两个组的相对份额为 50,当所有资源组中的进程试图使用 100% 的 CPU(即所有组的 CPU_MAX_PERCENT
值设置为 100)时,第一个资源组将获得 50% 的所有 CPU 时间,另外两个组将分别获得 25%。然而,如果您再添加一个相对份额为 100 的组,第一个组只能使用 33% 的 CPU,剩余的组分别获得 16.5%、16.5% 和 33%。