这是本节的多页打印视图。点击此处打印.

资源池架构

1: 定义辅助资源池
2: 查询资源池设置
3: 用户配置文件
4: 查询预算

资源管理器将资源处理为一个或多个资源池，这些池是使用关联队列预先分配的系统资源子集。

在企业模式下，有一组全局资源池适用于整个数据库中的所有子群集。在 Eon 模式下，您可以在全局或按子群集分配资源。全局级资源池适用于所有子群集。子群集级别的资源池允许您针对子群集执行的工作负载类型微调资源。如果您同时具有全局和子群集级别的资源池设置，则可以覆盖该子群集的任何与内存相关的全局设置。全局设置适用于没有子群集级别资源池设置的子群集。有关微调每个子群集的资源池的详细信息，请参阅管理 Eon 模式数据库中的工作负载资源。

Vertica 预配置了一组内置池，这些池将资源分配给不同请求类型，其中的 GENERAL 池根据计算机中的 RAM 和内核允许某种并发级别。

修改和创建资源池

可以根据实际的并发要求和性能要求配置内置的 GENERAL 池，如内置池中所述。也可以创建自定义池以处理各种类别的工作负载并可选择将用户请求限制在自定义池范围内。

您可以使用 CREATE RESOURCE POOL 创建用户定义的资源池，使用 ALTER RESOURCE POOL 修改用户定义的资源池。您可以针对内存使用、并发性和队列优先级配置这些资源池。您还可以将数据库用户或用户会话限制为使用特定的资源池。这样做可以让您控制内存、CPU 和其他资源的分配方式。

下图说明了在哪个资源池中执行了哪些数据库操作。仅显示了三个内置池。

1 - 定义辅助资源池

您可以定义正在运行的查询在超出初始资源池的 RUNTIMECAP 时可以级联到的辅助资源池。

确定辅助池

通过定义辅助资源池，您可以指定一个位置，超出正在运行查询的资源池的 RUNTIMECAP 的查询可以在该位置执行。这样，如果某个查询超出池的 RUNTIMECAP，该查询可级联至具有更大 RUNTIMECAP 的池，而不会导致错误。当查询级联到另一个池时，原始池将重新获得此查询使用的内存。

因为不考虑在辅助池上授予权限，所以您可以使用此功能为用户查询指定辅助资源池而无需为用户提供在该池上运行查询的明确权限。

您还可使用辅助池来存储长时间运行的查询，以便日后使用。使用 PRIORITY HOLD 选项，您可以指定一个对队列重新排队的辅助池，直至达到 QUEUETIMEOUT 或者池的优先级更改为非保留值。

在 Eon 模式下，为特定于子群集的资源池定义辅助资源池时，需遵循以下限制：

全局资源池只能级联到其他全局资源池。

特定于子群集的资源池可以级联到全局资源池，或级联到属于同一子群集的另一个特定于子群集的资源池。如果子群集特定资源池级联到全局和子群集级别中均具有的用户定义资源池，则优先子群集级别资源池。例如：

=> CREATE RESOURCE POOL billing1;
=> CREATE RESOURCE POOL billing1 FOR CURRENT SUBCLUSTER;
=> CREATE RESOURCE POOL billing2 FOR CURRENT SUBCLUSTER CASCADE TO billing1;
WARNING 9613:  Resource pool billing1 both exists at both subcluster level and global level, assuming subcluster level
CREATE RESOURCE POOL

查询级联路径

当达到初始池上的 RUNTIMECAP 时，Vertica 会将查询路由到辅助池。然后，Vertica 检查辅助池的 RUNTIMECAP 值。如果辅助池的 RUNTIMECAP 大于初始池的值，查询将在辅助池上执行。如果辅助池的 RUNTIMECAP 小于或等于初始池的值，Vertica 将在链中的下一个池上重新尝试查询，直至找到一个 RUNTIMECAP 大于初始池值的池。如果此时辅助池没有足够的可用资源来执行查询，SELECT 查询可能会在该池上重新排队、重新计划和中止。其他类型的查询会因为资源不足而失败。如果查询不存在合适的辅助池，查询将出现错误。

下图演示了执行查询时采用的路径。

查询执行时间分配

在 Vertica 找到用于运行查询的相应池之后，它会继续不间断地执行该查询。现在，查询在用于完成查询的两个池的 RUNTIMECAP 限制方面存在一些差异：

query execution time allocation = rp2 RUNTIMECAP - rp1 RUNTIMECAP

使用 CASCADE TO 参数

作为超级用户，您可以使用 CREATE RESOURCE POOL 或 ALTER RESOURCE POOL 语句中的 CASCADE TO 参数来识别辅助池。辅助池必须已作为用户定义的池或 GENERAL 池存在。使用 CASCADE TO 时，不能创建资源池循环。

此示例说明了一个场景，其中管理员希望 user1 的查询在 user_0 资源池上启动，但在查询过长时级联到 userOverflow 池。


=> CREATE RESOURCE POOL userOverflow RUNTIMECAP '5 minutes';
=> CREATE RESOURCE POOL user_0 RUNTIMECAP '1 minutes' CASCADE TO userOverflow;
=> CREATE USER "user1" RESOURCE POOL user_0;

在此场景中，user1 无法在 userOverflow 资源池上启动他或她的查询，但由于不考虑为辅助池授予权限，因此如果辅助池超出 user_0 池的 RUNTIMECAP，user1 的查询可以级联到 userOverflow 池。使用辅助池会释放主要池中的空间，因此可以运行简短的查询。

此示例显示了一个场景，即管理员想要长时间运行的查询在辅助池上保持排队状态。

=> CREATE RESOURCE POOL rp2 PRIORITY HOLD;
=> CREATE RESOURCE POOL rp1 RUNTIMECAP '2 minutes' CASCADE TO rp2;
=> SET SESSION RESOURCE_POOL = rp1;

在此场景中，在 rp1 上运行超过 2 分钟的查询将在 rp2 上排队，直至达到 QUEUETIMEOUT，此时查询将被拒绝。

如果您尝试删除的资源池是另一个资源池的辅助池，则 Vertica 会返回一个错误。该错误会列出与您尝试删除的辅助池有关的资源池。要删除辅助资源池，首先在主要资源池上将 CASCADE TO 参数设置为 DEFAULT，然后再删除辅助池。

例如，可以删除资源池 rp2，它是 rp1 的辅助池，如下：

=> ALTER RESOURCE POOL rp1 CASCADE TO DEFAULT;
=> DROP RESOURCE POOL rp2;

参数注意事项

当查询进入辅助池时，该池的 CPUAFFINITYSET 和 CPUAFFINITYMODE 会应用于该查询。

查询会根据以下情况在不同时间采用辅助池的 RUNTIMEPRIORITY：

如果当查询在主要池中运行时未启动 RUNTIMEPRIORITYTHRESHOLD 计时器，查询会在级联时采用辅助池的 RUNTIMEPRIORITY。当未设置主要池的 RUNTIMEPRIORITYTHRESHOLD 时或者将主要池的 RUNTIMEPRIORITY 设置为 HIGH 时，即会发生上述情况。
如果达到主要池的 RUNTIMEPRIORITYTHRESHOLD，查询会在级联时采用辅助池的 RUNTIMEPRIORITY。
如果未达到主要池的 RUNTIMEPRIORITYTHRESHOLD 并且辅助池没有阈值，查询会在级联时采用新池的 RUNTIMEPRIORITY。
如果未达到主要池的 RUNTIMEPRIORITYTHRESHOLD 并且辅助池设置了一个阈值：
- 如果主要池的RUNTIMEPRIORITYTHRESHOLD 大于或等于辅助池的 RUNTIMEPRIORITYTHRESHOLD，查询在达到主要池的 RUNTIMEPRIORITYTHRESHOLD 之后会采用辅助池的 RUNTIMEPRIORITY。
  
  例如： RUNTIMECAP （主要池）为 5 秒
  RUNTIMEPRIORITYTHRESHOLD （主要池）为 8 秒
  RUNTIMTPRIORITYTHRESHOLD （辅助池）为 7 秒
  
  在这种情况下，查询会在主要池上运行 5 秒，然后级联到次要池。再过去 3 秒（总共 8 秒）后，查询会采用次要池的 RUNTIMEPRIORITY。
- 如果主要池的 RUNTIMEPRIORITYTHRESHOLD 小于辅助池的 RUNTIMEPRIORITYTHRESHOLD，查询在达到辅助池的 RUNTIMEPRIORITYTHRESHOLD 之后将采用辅助池的 RUNTIMEPRIORITY。
  
  例如，主要池的
  RUNTIMECAP = 5 秒
  RUNTIMEPRIORITYTHRESHOLD （主要池）为 8 秒
  RUNTIMTPRIORITYTHRESHOLD （辅助池）为 12 秒
  
  在这种情况下，查询会在主要池上运行 5 秒，然后级联到次要池。再过去 7 秒（总共 12 秒）后，查询会采用次要池的 RUNTIMEPRIORITY。

2 - 查询资源池设置

您可以使用以下内容来获取有关资源池的信息：

RESOURCE_POOLS 从 Vertica 数据库编录中返回由 CREATE RESOURCE POOL 和 ALTER RESOURCE POOL 设置的资源池设置。
SUBCLUSTER_RESOURCE_POOL_OVERRIDES 显示全局资源池设置的所有子群集级别覆盖。

有关资源池的运行时信息，请参阅监控资源池。

查询资源池设置

以下示例查询两个内部资源池 GENERAL 和 TM 的各种设置：

=> SELECT name, subcluster_oid, subcluster_name, maxmemorysize, memorysize, runtimepriority, runtimeprioritythreshold, queuetimeout
   FROM RESOURCE_POOLS WHERE name IN('general', 'tm');
  name   | subcluster_oid | subcluster_name | maxmemorysize | memorysize | runtimepriority | runtimeprioritythreshold | queuetimeout
---------+----------------+-----------------+---------------+------------+-----------------+--------------------------+--------------
 general |              0 |                 | Special: 95%  |            | MEDIUM          |                        2 | 00:05
 tm      |              0 |                 |               | 3G         | MEDIUM          |                       60 | 00:05
(2 rows)

查看对全局资源池的覆盖

在 Eon 模式下，您可以在系统表中查询 SUBCLUSTER_RESOURCE_POOL_OVERRIDES 以查看对各个子群集的全局资源池的任何覆盖。以下查询显示了一个覆盖在 analytics_1 子群集中将内置资源池 TM 的 MEMORYSIZE 和 MAXMEMORYSIZE 设置为 0% 的覆盖。这些设置阻止子群集执行 Tuple Mover 合并任务。

=> SELECT * FROM SUBCLUSTER_RESOURCE_POOL_OVERRIDES;
     pool_oid      | name |  subcluster_oid   | subcluster_name | memorysize | maxmemorysize | maxquerymemorysize
-------------------+------+-------------------+-----------------+------------+---------------+--------------------
 45035996273705058 | tm   | 45035996273843504 | analytics_1     | 0%         | 0%            |
(1 row)

3 - 用户配置文件

用户配置文件是与某个用户相关联的属性，用于控制该用户对多个系统资源的访问权限。这些资源包括：

分配给用户的资源池 (RESOURCE POOL)
用户会话可以使用的最大内存量 (MEMORYCAP)
用户会话可以使用的最大临时文件存储量 (TEMPSPACECAP)
用户查询可以运行的最长时间 (RUNTIMECAP)

可使用 CREATE USER 语句设置这些属性，之后可以使用 ALTER USER 修改这些属性。

可使用两种策略来限制用户对资源的访问权限：直接为用户设置属性来控制资源使用，或将用户分配到一个资源池。第一种方法允许您对单个用户进行微调，而第二种方法可以轻松将许多用户分到一组，然后设置他们的共同资源使用量。

如果要通过资源池分配来统一限制用户资源，请考虑以下事项：

除非用户拥有 GENERAL 池的权限或者已分配给默认资源池，否则他们无法登录 Vertica。
如果删除了用户的默认资源池，则用户的查询将使用 GENERAL 池。
如果用户没有 GENERAL 池的权限，则在您尝试删除为他们分配的资源池时，DROP 操作将失败。

在 Eon 模式数据库中，您可以将用户的默认资源池设置为特定于子群集的资源池。如果是这种情况，Vertica 将使用以下方法之一来确定在用户连接到子群集时使用哪个资源池进行查询：

如果子群集使用为用户分配的默认资源池，那么用户的查询将使用为用户分配的资源池。
如果子群集不使用用户分配的默认资源池，但用户有权访问 GENERAL 池，则用户的查询使用 GENERAL 池。
如果子群集不使用为用户分配的资源池，并且用户对于 GENERAL 池没有权限，则用户无法从该子群集的任何节点进行查询。

以下示例说明了何设置用户的资源池属性。有关其他示例，请参阅将用户定义的池和用户配置文件用于工作负载管理中描述的场景。

示例

设置用户的 RESOURCE POOL 属性以将该用户分配到一个资源池。若要创建一个名为 user1 的用户，并且该用户具有对资源池 my_pool 的访问权限，请使用以下命令：

=> CREATE USER user1 RESOURCE POOL my_pool;

若要不通过指定池的方式来限制用户的内存量，可将该用户的 MEMORYCAP 设置为一个特定单位或占总可用内存的百分比。例如，若要创建一个名为 user2 的用户，并且将其会话限制为每个会话使用 200 MB 内存，请使用以下命令：

=> CREATE USER user2 MEMORYCAP '200M';

若要限制允许用户查询运行的时间，可设置 RUNTIMECAP 属性。若要阻止 user2 的查询运行超过五分钟，可使用以下命令：

=> ALTER USER user2 RUNTIMECAP '5 minutes';

若要限制用户会话可以使用的临时磁盘空间量，可将 TEMPSPACECAP 设置为一个特定大小或占可用临时磁盘空间的百分比。例如，下一个语句将创建 user3，并将其限制为使用 1 GB 的临时空间：

=> CREATE USER user3 TEMPSPACECAP '1G';

可以将不同属性组合到一个命令中：例如，若要为 user3 限制 MEMORYCAP 和 RUNTIMECAP，可将这两个属性包含在一个 ALTER USER 语句中：

=> ALTER USER user3 MEMORYCAP '750M' RUNTIMECAP '10 minutes';
ALTER USER
=> \x
Expanded display is on.
=> SELECT * FROM USERS;
-[ RECORD 1 ]-----+------------------
user_id           | 45035996273704962
user_name         | release
is_super_user     | t
resource_pool     | general
memory_cap_kb     | unlimited
temp_space_cap_kb | unlimited
run_time_cap      | unlimited
-[ RECORD 2 ]-----+------------------
user_id           | 45035996273964824
user_name         | user1
is_super_user     | f
resource_pool     | my_pool
memory_cap_kb     | unlimited
temp_space_cap_kb | unlimited
run_time_cap      | unlimited
-[ RECORD 3 ]-----+------------------
user_id           | 45035996273964832
user_name         | user2
is_super_user     | f
resource_pool     | general
memory_cap_kb     | 204800
temp_space_cap_kb | unlimited
run_time_cap      | 00:05
-[ RECORD 4 ]-----+------------------
user_id           | 45035996273970230
user_name         | user3
is_super_user     | f
resource_pool     | general
memory_cap_kb     | 768000
temp_space_cap_kb | 1048576
run_time_cap      | 00:10

另请参阅

4 - 查询预算

在执行查询之前，Vertica 会设计一个查询计划，并将其发送到将参与执行查询的每个节点。资源管理器评估每个节点上的计划，并估算节点执行其查询部分需要的内存量和并发程度。这是查询预算，Vertica 将其存储在系统表 V_MONITOR.RESOURCE_POOL_STATUS 的 query_budget_kb 列中。

查询预算基于查询将执行的资源池的几个参数设置：

MEMORYSIZE
MAXMEMORYSIZE
PLANNEDCONCURRENCY

您可以使用 ALTER RESOURCE POOL 修改 GENERAL 资源池的 MAXMEMORYSIZE 和 PLANNEDCONCURRENCY。此资源池通常执行未分配给用户定义资源池的查询。您可以在使用 CREATE RESOURCE POOL 或者稍后使用 ALTER RESOURCE POOL 创建任何由用户定义的资源池时设置所有三个参数。

重要

您还可以通过在该池上设置 MAXQUERYMEMORYSIZE 参数来限制池在运行时可以为其查询分配的内存量。有关详细信息，请参阅 CREATE RESOURCE POOL。

计算 GENERAL 池查询预算

Vertica 使用以下公式计算 GENERAL 池中的查询预算：

queryBudget = queuingThresholdPool / PLANNEDCONCURRENCY

注意

Vertica 将 GENERAL 池的排队阈值计算为其 MAXMEMORYSIZE 设置的 95%。

计算用户定义的资源池的查询预算

对于用户定义的资源池，Vertica 使用以下算法：

如果 MEMORYSIZE 设置为 0 并且 MAXMEMORYSIZE 未设置：

queryBudget = queuingThresholdGeneralPool / PLANNEDCONCURRENCY

如果 MEMORYSIZE 设置为 0 并且 MAXMEMORYSIZE 设置为非默认值：
```
query-budget = queuingThreshold / PLANNEDCONCURRENCY
```
注意
Vertica 将用户定义的池的排队阈值计算为其 MAXMEMORYSIZE 设置的 95%。

如果 MEMORYSIZE 设置为非默认值：

queryBudget = MEMORYSIZE / PLANNEDCONCURRENCY

通过仔细调整资源池的 MEMORYSIZE 和 PLANNEDCONCURRENCY 参数，可以控制能够为查询预算多少内存。

当心

查询预算通常不需要调整，但是，如果由于其他目的需要内存而减少 MAXMEMORYSIZE，请注意这样做也会减少查询预算。减少查询预算会对查询性能产生负面影响，尤其是在查询很复杂的情况下。

为了保持资源池的原始查询预算，一定要一起减小参数 MAXMEMORYSIZE 和 PLANNEDCONCURRENCY。

另请参阅

您是否需要在预算范围内查询？在 Vertica 用户社区中。