本文档面向 Vertica 管理员，提供了几个有关创建自定义资源池以处理明确定义和临时工作负载的示例。
您的 Vertica 环境可能需要同时运行多种查询。在系统上运行多个查询时，查询会共享资源。因此，每个查询的运行时间可能比单独运行更长。资源管理器可帮助您确定资源使用的优先级，并通过资源池处理资源。资源池是系统资源的预分配子集，具有关联队列。本文档详细介绍了一些建议的用例，以帮助您为数据库创建资源池。
1、创建自定义资源池
创建自定义资源池时，您可以考虑设置许多参数。有关其他参数的更多信息，请参阅 Vertica 文档中的 ALTER RESOURCE POOL。本文档重点介绍以下五个参数：
- MEMORYSIZE：分配给资源池的独占内存。但是，如果该独占内存未使用，也无法用于来自其他池的查询。
- MAXMEMORYSIZE：该资源池中执行SQL所能使用的总内存上限。通常该参数设置比 MEMORYSIZE 大。
- MAXCONCURRENCY：该资源池运行的最大并发查询数。
- PLANNEDCONCURRENCY：该资源池运行的并发查询数的估计值。此参数用于计算资源池的查询预算。查询预算是分配给查询的初始内存。根据查询的复杂性和查询预算的值，Vertica 会为每个影响查询性能的运算符分配并行线程。有关更多信息，请参阅此博客文章。
- EXECUTIONPARALLELISM：限制用于处理资源池中发出的任何单个查询的线程数。
2、了解工作负载
您可以根据业务场景（ETL 与 SELECT）、应用程序、用户组和查询复杂性对工作负载进行分类。有关更多详细信息，请参阅本文档末尾的附录，其中有两个视图定义可进一步解释工作负载。
3、示例：创建并分配资源池
此示例使用了两个不同的业务场景：
- fastAnalytics，一个具有明确定义的工作负载的业务场景
- quickAnalytics，一个具有临时工作负载的业务场景
我们选择了这两个常见示例来展示如何为不同的业务场景创建自定义资源池。
场景 fastAnalytics 全天候运行 ETL 作业，并且必须满足预定义的数据加载 SLA。有一个 10 节点集群，每个节点有 256GB 内存和 48 个核心。首先，分别为 ETL 和 SELECT 两个业务场景创建两个名为 etl_pool 和 select_pool 的用户资源池，在 ETL 和 SELECT 查询之间分配资源。下表显示了两个新池的资源池定义：
| Resource Pool | MEMORYSIZE | MAXMEMORYSIZE | PLANNEDCONCCURENCY | MAXCONCURRENCY | EXECUTIONPARALLELISM | query_budget |
|---|---|---|---|---|---|---|
| general | Special: 95% | 120 | AUTO(number of core) | (256*95%)/120=2G |
||
| etl_pool | 40% | 48 | 4 | ((256*95%)*40%)/48=2G |
||
| short_pool | 40% | 48 | 6 | ((256*95%)*40%)/48=2G |
||
| medium_pool | 30% | 18 | 12 | ((256*95%)*30%)/18=4G |
||
| large_pool | 10% | 3 | 24 | ((256*95%)*10%)/3=8G |
此表显示我们为不同池设置了 EXECUTIONPARALLELISM，因为默认值为 AUTO。此值与主机上的核心数相同。对于 fastAnalytics，48 对于并发工作负载来说太高了。
我们为每个用户定义的资源池设置了 MAXMEMORYSIZE 和 PLANNEDCONCURRENCY，以限制每个用户池的内存消耗，并根据大小为每个池设置 2GB、4GB 和 8GB 的查询预算。etl_pool 的查询预算设置为 3GB，EXECUTIONPARALLELISM 值为 4，因为我们没有实时聚合预测或扁平化表。如果您有实时聚合预测或扁平化表，请将 EXECUTIONPARALLELISM 值设置得更高，例如 16。
在进行这些初始更改几个月后，fastAnalytics 的数据库管理员对这些查询进行了另一轮工作负载分析。管理员发现，将数据加载到宽表中的一些批量处理 ETL 作业消耗了更多内存，并且运行时间更长。他们的团队决定将 ETL 作业再拆分为两个：一个用于涓流加载，一个用于批量加载到宽表中。这意味着 etl_pool 将被每个工作负载的两个不同池取代，即 trickle_pool 和 bulk_pool。有了这些单独的池，长时间运行的 ETL 作业就不会阻塞涓流作业。
在 fastAnalytics，高级管理层正在使用报告应用程序。数据库管理员发现需要一个可以分配给高级管理层的独立资源池，这样他们的查询就不必在队列中等待。独立资源池的配置使其无法从通用池借用内存。独立资源池的 MEMORYSIZE 等于 MAXMEMORYSIZE。
下表显示了创建两个新池来替换 etl_pool 以及创建新的管理池之后的资源池定义：
| Resource Pool | MEMORYSIZE | MAXMEMORYSIZE | PLANNEDCONCCURENCY | MAXCONCURRENCY | EXECUTIONPARALLELISM | query_budget |
|---|---|---|---|---|---|---|
| general | Special: 95% | 120 | AUTO(number of cores) | (256*95%)/120=2G |
||
| trickle_pool | 30% | 28 | 4 | ((256*95%)*30%)/28=2.5G |
||
| bulk_pool | 10% | 4 | 4 | ((256*95%)*10%)/4=6G |
||
| etl_pool | 40% | 48 | 4 | ((256*95%)*40%)/48=2G |
||
| short_pool | 40% | 48 | 6 | ((256*95%)*40%)/48=2G |
||
| medium_pool | 30% | 18 | 12 | ((256*95%)*30%)/18=4G |
||
| large_pool | 10% | 3 | 24 | ((256*95%)*10%)/3=8G |
||
| management_pool | 6G | 6G | 6 | 6 | 6/6=1G |
在上表中，我们将 management_pool 的 MEMORYSIZE 和 MAXMEMORYSIZE 设置为 6GB，以确保该池始终有足够的内存用于其查询。但是，fastAnalytics 的团队应定期检查此池的使用情况，以确保此独立池不会阻塞多余的内存。
替换 etl_pool 的 trickle_pool 和 bulk_pool 的查询预算分别为 2.5GB 和 6GB。bulk_pool 用于加载宽表（具有超过 250 列的表）。您可以使用更高的查询预算来提高宽表的加载性能。
虽然 fastAnalytics 具有明确定义的工作负载，但有些组织却没有。例如，quickAnalytics 组织的工作负载完全是临时的。quickAnalytics 的数据库管理员决定使用 Vertica 级联资源池功能来处理临时工作负载。
4、资源池级联
创建自定义资源池时，可以使用 CASCADE TO 选项指定辅助资源池，用于执行超出其分配的资源池的 RUNTIMECAP 设置的查询。
使用级联资源池时，查询可能会遇到以下情况：
- 辅助资源池没有可用内存来移动查询。在这种情况下，查询将被终止，针对辅助池重新规划，并在辅助资源池上排队等待资源。
- 正在移动的查询已获取大于辅助池的 MAXMEMORYSIZE 的内存。在这种情况下，查询的执行将被终止并针对辅助池重新规划。
- 在辅助池上正在运行查询数量已经等于 MAXCONCURRENCY。在这种情况下，即使超出 RUNTIMECAP，查询也不会移动到辅助资源池，并继续在主池中运行。数据收集器表 DC_RESOURE_POOL_MOVE 将出现错误消息，例如“目标池没有足够的资源”。
quickAnalytics 的数据库用户运行了小型、中型或大型的临时查询。接下来，我们将讨论可用于实现级联资源池的两种不同模式。
4.1 资源池设置A
在设置模式 A 中，您有三个不同的资源池，它们的查询预算完全相同，但运行时上限（RUNTIMECAP）不同。在这种情况下，当查询从一个池级联到另一个池时，查询的执行不会中断，但内存会计入新池。此设置最适合大多数查询较短的工作负载。优点是查询不会在级联期间重新计划，因此不会浪费执行周期。但是，针对预算较小的池的罕见复杂查询可能会比预期运行时间长得多。
假设我们决定创建具有相同查询预算和不同运行时间上限的慢速、中速和快速池：
- 快速池的运行时间上限为 5 秒。任何超出此上限的查询都会级联到中速池。
- 中速池的运行时间上限为 1 分钟。任何超出此上限的查询都会级联到慢速池。
- 慢速池的运行时间上限为 5 分钟。任何超出此上限的查询都会被终止。
| Resource Pool | MEMORYSIZE | MAXMEMORYSIZE | PLANNEDCONCCURENCY | MAXCONCURRENCY | EXECUTIONPARALLELISM | RUNTIMECAP | CASCADE TO | query_budget |
|---|---|---|---|---|---|---|---|---|
| general | Special: 95% | AUTO (number of cores) | AUTO (number of cores) | (256*95%)/48=5G |
||||
| etl_pool | 40% | 32 | 32 | 4 | ((256*95%)*40%)/32=3G |
|||
| fast | 50% | 120 | 60 | 6 | 00:00:05 | medium | ((256*95%)*50%)/120=1G |
|
| medium | 20% | 45 | 15 | 12 | 00:01:00 | slow | ((256*95%)*20%)/45=1G |
|
| slow | 10% | 20 | 5 | 24 | 00:05:00 | ((256*95%)*10%)/20=1G |
在上表中，快速、中速和慢速池的查询预算都为 1GB。可以通过调整 PLANNEDCONCCURENCY 参数来控制 query_budget 。
由于所有查询都是针对快速资源池进行规划的，并且在级联后不会重新规划，因此它们以 1GB 的查询预算运行。
在资源池上设置 MAXCONCURRENCY 以限制针对池的并发查询数。
4.2 资源池设置B
在设置模式 B 中，您有三个不同的资源池，它们的查询预算、最大并发性和运行时上限非常不同。在此设置中，当查询从一个池级联到另一个池时，查询的执行将终止，并针对具有更高预算的新池重新规划查询。此设置在相同用户提交具有简单、中等和复杂查询的混合工作负载的情况下效果最佳。通过将资源池的运行时上限设置为较小的值，我们可以最大限度地减少由于资源池移动而丢失的执行周期。查询将在具有更合适预算的池上重新规划，并运行得更快，以弥补重新规划所损失的时间。
quickAnalytics 的数据库用户运行了小型、中型或大型的临时查询。管理员分别创建了查询预算为 1GB、2GB 和 5GB 的快速、中型和慢速池。他们按如下方式设置池的运行时上限：
- 快速池的 RUNTIMECAP 为 3 秒。任何超出此上限的查询都会级联到中等池。
- 中等池的 RUNTIMECAP 为 15 秒。任何超出此上限的查询都会级联到慢速池。
- 慢速池的 RUNTIMECAP 为 1 分钟。任何超出此上限的查询都会终止。
每个运行 SELECT 查询的用户都被分配到快速池。配置参数 CascadeResourcePoolAlwaysReplan 必须设置为 1。当值为 1 时，查询将在移动到新资源池时重新规划。用户还必须拥有所有三个资源池的使用权限。
select * from configuration_parameters where parameter_name ilike 'CascadeResourcePoolAlwaysReplan';
-[ RECORD 1 ]-----------------+-------------------------------------------------------------------------------------------------------
node_name | ALL
parameter_name | CascadeResourcePoolAlwaysReplan
current_value | 0
restart_value | 0
database_value | 0
default_value | 0
current_level | DEFAULT
restart_level | DEFAULT
is_mismatch | f
groups |
allowed_levels | SESSION, USER, DATABASE
superuser_visible_only | f
change_under_support_guidance | t
change_requires_restart | f
description | If true, cascade to a target resource pool will always lead to replanning the query on the target pool
| Resource Pool | MEMORYSIZE | MAXMEMORYSIZE | PLANNEDCONCCURENCY | MAXCONCURRENCY | EXECUTIONPARALLELISM | RUNTIMECAP | CASCADE TO | query_budget |
|---|---|---|---|---|---|---|---|---|
| general | Special: 95% | AUTO (number of cores) | AUTO (number of cores) | (256*95%)/48=5G |
||||
| etl_pool | 40% | 32 | 32 | 4 | ((256*95%)*40%)/32=3G |
|||
| fast | 50% | 120 | 60 | 6 | 00:00:03 | medium | ((256*95%)*50%)/120=1G |
|
| medium | 20% | 20 | 10 | 12 | 00:00:15 | slow | ((256*95%)*20%)/20=2.4G |
|
| slow | 10% | 5 | 5 | 24 | 00:05:00 | ((256*95%)*10%)/5=4.8G |
上表显示，快速、中速和慢速池的查询预算分别为 1GB、2GB 和 5GB。级联后，所有查询都会重新规划，因此它们在级联后会以不同的查询预算运行。我们应该监视数据收集器表 DC_RESOURCE_POOL_MOVE，以查看级联到新池的查询百分比。Vertica 管理员应调整资源池的运行时上限，以使移动到新池的查询百分比保持在 10% 以下。
5、资源管理分析
在规划资源池时，我们需要做到以下几点：
- 确保查询在资源队列中等待资源的时间不长或很少。您可以使用以下查询来识别资源队列的当前状态以及各个历史查询在队列中花费的时间：
SELECT* FROM resource_acquisitions; - 微调资源池预算以提高查询性能。以下查询显示每个池的查询预算以及其他重要的资源池参数：
SELECT pool_name, memory_size_kb, max_memory_size_kb, planned_concurrency, max_concurrency, query_budget_kb FROM resource_pool_status WHERE node_name ilike '%0001%' ORDER BY query_budget_kb desc; - 注意偶尔出现的差查询，这些查询会消耗大量内存或运行时间异常长，从而影响其他并发查询。以下示例显示了消耗超过 25GB 的事务：
SELECT * FROM user_workload WHERE mem_kb > '25*1024^2' ORDER BY query_duration_us desc;
您还可以使用管理控制台监控资源池。有关更多信息，请参阅 Vertica 文档。
6、附录
要分析工作负载，请使用以下两个视图以数据库管理员身份创建和运行查询。
USER_WORKLOAD 视图关联数据收集器表 dc_resource_acquisitions、dc_requests_issued 和 dc_requests_completed 表以获取查询类型、使用的资源池、查询使用的内存以及数据库用户执行的查询的查询持续时间（以微秒为单位）。此视图还具有事务和语句 ID，可用于识别消耗大量内存的查询和发出该查询的用户。
USER_WORKLOAD_BY_HOUR 是 USER_WORKLOAD 视图之上的视图，按小时汇总。它包含用户运行的多个短查询、中查询和快查询，以及每个用户每小时汇总的平均持续时间、最小、最大和平均内存（以千字节为单位）。我们假设执行时间少于 10 秒为短，超过 5 分钟为长，而 10 秒到 5 分钟之间的为中等。
CREATE OR REPLACE VIEW USER_WORKLOAD
AS
SELECT ri.user_name,
ri.time,
ri.request_type,
ra.pool_name,
ra.transaction_id,
ra.statement_id,
(memory_kb) mem_kb,
extract(epoch from rc.time - ri.time) * 1e6 as query_duration_us
FROM
(SELECT transaction_id,
statement_id,
pool_name,
max(memory_kb) memory_kb
FROM dc_resource_acquisitions
WHERE request_type!='Acquire' and pool_name <> 'sysquery'
GROUP BY 1,2,3)ra
JOIN dc_requests_issued AS ri ON ra.transaction_id=ri.transaction_id
AND ra.statement_id=ri.statement_id
JOIN dc_requests_completed as rc on rc.session_id=ri.session_id
AND rc.request_id=ri.request_id
AND rc.node_name=ri.node_name;
select * from USER_WORKLOAD;
user_name | time | request_type | pool_name | transaction_id | statement_id | mem_kb | query_duration_us
-----------+-------------------------------+--------------+-----------+-------------------+--------------+--------+-------------------
dbadmin | 2024-07-26 11:21:09.289068+08 | QUERY | general | 45035996273708763 | 1 | 466001 | 8382.000000
dbadmin | 2024-07-22 17:04:37.993645+08 | QUERY | general | 45035996273708326 | 1 | 466001 | 5366.000000
dbadmin | 2024-07-29 16:34:47.705815+08 | QUERY | general | 45035996273717517 | 1 | 14983 | 37665.000000
dbadmin | 2024-07-10 17:39:16.47495+08 | QUERY | general | 45035996273707889 | 1 | 466001 | 4230.000000
dbadmin | 2024-07-10 17:39:16.480453+08 | QUERY | general | 45035996273707889 | 1 | 466001 | 5073.000000
dbadmin | 2024-07-26 11:21:09.127052+08 | QUERY | general | 45035996273708732 | 1 | 466001 | 35724.000000
dbadmin | 2024-07-26 11:21:09.256083+08 | QUERY | general | 45035996273708757 | 1 | 466001 | 7211.000000
dbadmin | 2024-07-22 17:04:37.975982+08 | QUERY | general | 45035996273708320 | 1 | 466001 | 2890.000000
...
CREATE OR REPLACE VIEW USER_WORKLOAD_BY_HOUR
AS
SELECT
TIME::varchar(13),
user_name,
pool_name,
CASE
WHEN avg(query_duration_us) > 300000000 THEN 'LONG_QUERY'
WHEN avg(query_duration_us) < 10000000 THEN 'SHORT_QUERY'
ELSE 'MEDIUM_QUERY'
END AS query_size,
count(*) query_count,
avg(query_duration_us)::int avg_qd_us,
min(mem_kb)::int min_mem_kb,
avg(mem_kb)::int avg_mem_kb,
max(mem_kb)::int max_mem_kb
FROM USER_WORKLOAD
GROUP BY 1,2,3
ORDER BY 1,2,3,4;
select * from USER_WORKLOAD_BY_HOUR;
TIME | user_name | pool_name | query_size | query_count | avg_qd_us | min_mem_kb | avg_mem_kb | max_mem_kb
---------------+-----------+-----------+-------------+-------------+-----------+------------+------------+------------
2024-06-19 11 | dbadmin | general | SHORT_QUERY | 1 | 7894 | 4738 | 4738 | 4738
2024-07-10 17 | dbadmin | general | SHORT_QUERY | 19 | 5613 | 5729 | 441777 | 466004
2024-07-22 17 | dbadmin | general | SHORT_QUERY | 16 | 8135 | 466001 | 466001 | 466001
2024-07-26 11 | dbadmin | general | SHORT_QUERY | 16 | 10751 | 466001 | 466001 | 466001
...
