使用 Resource Groups 管理资源
Resource Group(资源组)可用来管理和保护 Apache Cloudberry 中 CPU、内存、并发事务限制和磁盘 I/O 的资源分配。定义资源组后,可将该组分配给一个或多个 Apache Cloudberry 用户角色(Role),或分配给外部组件(如 PL/Container),以控制其使用的资源。
一个资源组所定义的限制条件适用于所有被分配该资源组的用户角色。例如,资源组定义的最大内存使用量限制会应用于所有该组用户所提交的运行事务上。
Apache Cloudberry 使用基于 Linux 的控制组来管理 CPU 资源,并使用 Runaway Detector 进行统计、跟踪和内存管理。
理解角色和组件资源组
Apache Cloudberry 支持两种类型的资源组:用于管理角色资源的组,及用于管理外部组件(如 PL/Container)资源的组。
资源组的最常见应用是管理不同角色在 Apache Cloudberry 集群中可以并发运行的活动查询数量。也可以用来管理 Apache Cloudberry 为每个查询分配的 CPU、内存资源和磁盘 I/O 的数量。
当用户运行查询时,Apache Cloudberry 会根据为资源组定义的一组限制评估该查询。如果该组的资源限制尚未达到,并且该查询不会导致该组超过并发事务限制,Apache Cloudberry 会立即运行该查询。如果这些条件不满足,Apache Cloudberry 会将查询进行队列排序。例如,如果资源组的最大并发事务数已经达到,后续查询将被排序等待,必须等待其他 查询完成后才能运行。当资源组的并发性和内存限制调整到足够大的值时,Apache Cloudberry 也可能运行待处理的查询。
在角色的资源组内,事务是按照先进先出 (First-in-first-out) 原则进行评估的。Apache Cloudberry 定期评估系统的活动工作负载,根据需要重新分配资源,并启动作业或将其放入队列。
您还可以使用资源组来管理外部组件(如 PL/Container)的 CPU 和内存资源。外部组件的资源组使用 Linux cgroups 来管理该组件的总 CPU 资源。
资源组属性和限制
当创建资源组时,需提供一组参数,以确定该组可用的 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_LIMIT | 为资源组指定的内存限制值。 | Integar (MB) | -1(未设置,使用 statement_mem 作为单个查询的内存限制) |
MIN_COST | 查询计划被包含在资源组中的最小成本。 | Integar | 0 |
对于 SET
、 RESET
和 SHOW
命令,不强制执行资源限制。
事务并发限制
CONCURRENCY
限制控制资源组允许的最大并发事务数。
每个资源组在逻辑上分为与 CONCURRENCY
限制相等的固定数量的 slot。Apache Cloudberry 为这些 slot 分配固定百分比的内存资源。
角色资源组的默认 CONCURRENCY
限制值为 20
。值为 0
表示该资源组不允许运行任何查询。
Apache Cloudberry 将任何在资源组达到 CONCURRENCY
限制后提交的事务排队。当运行的事务完成时,如果存在足够的内存资源,Apache Cloudberry 会取 消排队并运行排队中最早的事务。请注意,如果事务处于 idle in transaction
状态,即使没有语句在运行,并发 slot 仍然处于使用中。
您可以设置服务器配置参数 gp_resource_group_queuing_timeout
来指定事务在 Apache Cloudberry 取消之前在队列中保持的时间。默认超时值为 0
,Apache Cloudberry 会无限期地排队事务。
绕过和解除资源组分配
通过设置服务器配置参数 gp_resource_group_bypass
,可使查询不受资源组并发设置的限制。此参数将启用或禁用资源组的并发事务限制,因此查询可以立即运行。默认值为 false
,这将强制执行 CONCURRENCY
限制。此参数只可在单个会话中设置,无法在事务或函数内设置。如将 gp_resource_group_bypass
设置为 true
,查询不再强制执行分配给其资源组的 CPU 或内存限制。相反,该查询分配的内存限制为每个查询的 statement_mem
。如果没有足够的内存满足内存分配请求,查询将失败。
你可绕过仅 catalogue tables 的查询,例如数据库图形用户界面(GUI)客户端运行的获取元数据的 catalogue 查询。如果服务器配置参数 gp_resource_group_bypass_catalog_query
设置为 true
(默认),Apache Cloudberry 的资源组调度器会绕过所有仅从系统目录读取的查询,或查询文本中仅包含 pg_catalog
模式表的查询。这些查询会自动解除分配其当前资源组;它们不强制执行资源组的限制,也不计算资源使用。查询资源会从资源组中分配并立即运行。 内存限制为每个查询的 statement_mem
。
可使用服务器配置参数 gp_resource_group_bypass_direct_dispatch
绕过直接调度查询。直接调度查询是一种特殊类型的查询,仅需要一个分段参与执行。为了提高效率,Apache Cloudberry 优化了此类型的查询,使用直接调度优化。系统将查询计划发送到需要执行该计划的单个分段,而不是将其发送到所有分段进行执行。如果将 gp_resource_group_bypass_direct_dispatch
设置为 true
,该查询不再强制执行分配给其资源组的 CPU 或内存限制,因此立即运行。相反,该查询分配的内存限制为每个查询的 statement_mem
。如果没有足够的内存满足内存分配请求,查询将失败。您只能在单个会话中设置此参数,而不能在事务或函数内。
计划成本低于限制 MIN_COST
的查询会自动解除分配其资源组,不强制执行其任何限制。查询使用的资源不会计算为资源组的资源。查询的内存限制为 statement_mem
。 MIN_COST
的默认值为 0
。
CPU 限制
Apache Cloudberry 利用 Linux 控制组实现 CPU 资源管理。Apache Cloudberry 通过以下两种方式分配 CPU 资源:
- 通过将 CPU 资源的百分比分配给资源组
- 通过将特定的 core 分配给资源组
当为资源组设置其中一种分配模式时,Apache Cloudberry 会停用另一种分配模式。可同时为同一 Apache Cloudberry 集群的不同资源组使用两种 CPU 资源分配模式。还可以在运行时更改资源组的 CPU 资源分配模式。
Apache Cloudberry 使用服务器配置参数 gp_resource_group_cpu_limit
来识别要分配给每个 Apache Cloudberry 分段节点的资源组的最大系统 CPU 资源百分比。剩余未保留的 CPU 资源用于操作系统内核和 Apache Cloudberry 守护进程。每个主机上可用于 Apache Cloudberry 查询的 CPU 量随后平均分配给 Apache Cloudberry 节点上的每个分段。
默认的 gp_resource_group_cpu_limit
值可能无法在 Apache Cloudberry 集群节点上留下足够的 CPU 资源,因此请确保相应地调整此服务器配置参数。
应避免将 gp_resource_group_cpu_limit
设置为高于 0.9 的值。这样做可能导致高负载查询占用几乎所有 CPU 资源,导致数据库辅助进程的资源紧 张。
按核心分配 CPU 资源
可通过 CPUSET
属性识别要为资源组保留的 CPU 核。指定的 CPU 核必须在系统中可用,并且不能与为其他资源组保留的任何 CPU 核重叠。尽管 Apache Cloudberry 数据库将分配给资源组的核专用于该组,但这些 CPU 核也可能被系统中的非 Apache Cloudberry 进程使用。当为资源组配置 CPUSET
时,Apache Cloudberry 数据库会停用该组的 CPU_MAX_PERCENT
和 CPU_WEIGHT
,并将它们的值设置为 -1。
分别为 Coordinator 和 Segment 指定 CPU 核,用分号分隔。配置 CPUSET
的核时,使用以逗号分隔的单核数字或数字区间。必须用单引号括起核心数字/区间,例如,‘1;1,3-4’ 在 Coordinator 上使用核 1,在分段主机上使用核 1、3 和 4。
当将 CPU 核心分配给 CPUSET
组时,请考虑以下几点:
- 使用
CPUSET
创建的资源组将独占指定的核。如果组中没有正在运行的查询,则保留的核处于空闲状态,无法被其他资源组中的查询使用。考虑最小化CPUSET
组的数量,以避免浪费系统 CPU 资源。 - 考虑保持 CPU 核 0 不分配。CPU 核 0 在以下情况下用作后备机制:
admin_group
和default_group
至少需要一个 CPU 核。当所有 CPU 核都被保留时,Apache Cloudberry 数据库将 CPU 核 0 分配给这些默认组。在这种情况下,为其分配 CPU 核 0 的资源组与admin_group
和default_group
共享该核。- 如以替换节点的方式重启 Apache Cloudberry 数据库集群,并且该节点没有足够的核来服务所有
CPUSET
资源组,则这些组会自动分配 CPU 核 0,以避免系统启动失败。
- 在为资源组分配核时,请使用尽可能低的核数字。如果替换 Apache Cloudberry 数据库节点,而新节点的 CPU 核少于原始节点,或者备份数据库并希望在核较少的集群中恢复,操作可能会失败。例如,如果的 Apache Cloudberry 数据库集群有 16 个核,分配核 1-7 是最佳选择。如果创建一个资源组并将 CPU 核心 9 分配给该组,则恢复到 8 核节点的数据库将失败。
使用 CPUSET
配置的资源组在 CPU 资源上具有更高的优先级。在 Segment 主机上为所有配置了 CPUSET
的资源组设置的最大 CPU 资源使用百分比为保留的 CPU 核数除以所有 CPU 核数,再乘以 100。
在为 Apache Cloudberry 数据库集群启用基于资源组的资源管理后,必须为资源组配置 CPUSET
,该参数是 gp_resource_manager
服务器配置参数。