Complete a 3 Question Survey and Earn a re:Post Badge
Help improve AWS Support Official channel in re:Post and share your experience - complete a quick three-question survey to earn a re:Post badge!
如何使用和管理 Amazon Redshift WLM 内存分配?
我想检查队列的并发性和 Amazon Redshift 工作负载管理 (WLM) 分配情况。
简短描述
使用以下方法之一配置 WLM 以有效管理资源:
- 自动 WLM: Amazon Redshift 管理队列的并发级别以及每个分派查询的内存分配。分派查询允许您为每个查询队列定义工作负载或用户的查询优先级。
- 手动 WLM: 您可以更好地控制队列的并发级别和内存分配。因此,消耗更多资源的查询可以在分配更多资源的队列中运行。
最佳做法是使用自动 WLM,因为它使用机器学习来预测分配查询的内存量。如果您使用手动 WLM 并且想要迁移到自动 WLM,请参阅从手动 WLM 迁移到自动 WLM。
**注意:**要定义基于指标的性能边界,请将查询监控规则 (QMR)用于您的 WLM 配置。
解决方法
要检查队列的并发级别和 WLM 分配,请执行以下操作:
- 检查您的 Amazon Redshift 集群的当前 WLM 配置。
- 创建测试 WLM 配置,并指定查询队列的分配和并发级别。
- (可选)如果您使用手动 WLM,请确定内存在槽数之间的分配方式。
检查当前 WLM 配置和内存使用情况
使用 STV_WLM_SERVICE_CLASS_CONFIG 表来检查您的 Amazon Redshift 集群的当前 WLM 配置。
WLM 配置示例:
[ { "query_concurrency": 2, "memory_percent_to_use": 30, "query_group": [], "query_group_wild_card": 0, "user_group": [ "user_group1" ], "user_group_wild_card": 0, "rules": [ { "rule_name": "BlockstoDiskSpill", "predicate": [ { "metric_name": "query_temp_blocks_to_disk", "operator": ">", "value": 50 } ], "action": "abort" } ] }, { "query_concurrency": 5, "memory_percent_to_use": 40, "query_group": [], "query_group_wild_card": 0, "user_group": [ "user_group2" ], "user_group_wild_card": 0 }, { "query_concurrency": 5, "memory_percent_to_use": 10, "query_group": [], "query_group_wild_card": 0, "user_group": [], "user_group_wild_card": 0, "rules": [ { "rule_name": "abort_query", "predicate": [ { "metric_name": "scan_row_count", "operator": ">", "value": 1000 } ], "action": "abort" } ] }, { "query_group": [], "query_group_wild_card": 0, "user_group": [], "user_group_wild_card": 0, "auto_wlm": false }, { "short_query_queue": false } ]
**注意:**前面的示例 WLM 配置采用 JSON 格式,使用 QMR,队列 1。在示例中,memory_percent_to_use 是分配给服务类的实际运行内存量。
Amazon Redshift 会从集群中的共享资源池中分配内存。队列 1 的内存分配为 30%,由于并发性设置为 2,因此分成两个相等的槽。每个槽均等获得 15% 的当前内存分配。
Queue2 的内存分配为 40%,由于并发性设置为 5,因此分成了五个相等的槽。每个槽均等获得 8% 的内存分配。默认队列使用 10% 的内存分配,队列并发级别为 5。
使用以下查询检查服务类配置:
select rtrim(name) as name, num_query_tasks as slots, query_working_mem as mem, max_execution_time as max_time, user_group_wild_card as user_wildcard, query_group_wild_card as query_wildcard from stv_wlm_service_class_config where service_class > 4;
输出示例:
name | slots | mem | max_time | user_wildcard | query_wildcard ----------------------------------------------------+-------+-----+----------+---------------+---------------- Service class for super user | 1 | 297 | 0 | false | false Queue 1 | 2 | 522 | 0 | false | false Queue 2 | 5 | 278 | 0 | false | false Default queue | 5 | 69 | 0 | false | false Service class for vacuum/analyze | 0 | 0 | 0 | false | false
队列 1 的槽数为 2,分配给每个槽或节点的内存为 522 MB。分配给服务类的内存分配是每个节点每个槽的当前实际运行内存量,以 MB 为单位。
**注意:**如果使用了所有查询槽,则 Amazon Redshift 会管理未分配的内存。当队列请求额外内存时,系统会临时向该队列提供未分配的内存。
有关未分配内存管理的详细信息,请参阅要使用的 WLM 内存百分比。
确定高级调整参数
使用 SVL_QUERY_METRICS_SUMMARY 表检查详细执行情况,使用 query_queue_time 列查看排队的查询。query_queue_time 列显示该查询已在队列中等待要运行的 WLM 槽。
表示例:
dev=# select userid, query, service_class, query_cpu_time, query_blocks_read, query_execution_time, query_cpu_usage_percent, query_temp_blocks_to_disk, query_queue_time from SVL_QUERY_METRICS_SUMMARY where query=29608; userid | query | service_class | query_cpu_time | query_blocks_read | query_execution_time | query_cpu_usage_percent | query_temp_blocks_to_disk | query_queue_time --------+-------+---------------+----------------+-------------------+----------------------+-------------------------+---------------------------+------------------ 100 | 29608 | 8 | 18 | 942 | 64 | 10.05 | | (1 row) ev=# select query, step, rows, workmem, label, is_diskbased from svl_query_summary where query = 29608 order by workmem desc; query | step | rows | workmem | label | is_diskbased -------+------+----------+----------+-----------------------------------------+-------------- 29608 | 3 | 49999 | 54263808 | hash tbl=714 | f 29608 | 2 | 49999 | 0 | project | f 29608 | 0 | 49999 | 0 | scan tbl=255079 name=part | f 29608 | 1 | 49999 | 0 | project | f 29608 | 6 | 1561938 | 0 | return | f 29608 | 4 | 1561938 | 0 | project | f 29608 | 5 | 1561938 | 0 | project | f 29608 | 2 | 29995220 | 0 | project | f 29608 | 1 | 1561938 | 0 | return | f 29608 | 1 | 29995220 | 0 | project | f 29608 | 0 | 1561938 | 0 | scan tbl=4893 name=Internal Worktable | f 29608 | 3 | 1561938 | 0 | hjoin tbl=714 | f 29608 | 0 | 29995220 | 0 | scan tbl=255087 name=lineorder | f (13 rows)
使用 SVL_QUERY_SUMMARY 表检查查询每个步骤中的资源分配。
检查 is_diskbased 和 workmem 列以查看资源使用情况。有关详细信息,请参阅分析查询摘要。
更新 WLM 动态配置属性
使用 WLM 动态配置属性来适应不断变化的工作负载。无需重新启动集群即可将动态属性应用于数据库。但是,自动 WLM 和手动 WLM 之间的更改是静态的,需要重新启动集群才能生效。
有关详细信息,请参阅 STV_WLM_SERVICE_CLASS_CONFIG。
以下是配置了两个队列的集群示例:
Queue Concurrency % Memory to Use 1 5 60% 2 5 40%
如果集群有 200 GB 的可用内存,则每个队列槽的当前内存分配与以下示例类似:
Queue 1: (200 GB * 60% ) / 5 slots = 24 GB Queue 2: (200 GB * 40% ) / 5 slots = 16 GB
要将您的 WLM 配置属性更新为动态,请修改您的设置。请参阅以下修改示例:
Queue Concurrency % Memory to Use 1 3 75% 2 4 25%
修改 WLM 配置后,内存分配将更新以适应更改的工作负载。请参阅以下更新示例:
Queue 1: (200 GB * 75% ) / 3 slots = 50 GB Queue 2: (200 GB * 25% ) / 4 slots = 12.5 GB
**注意:**如果在动态配置更新期间,WLM 队列中有查询,则 Amazon Redshift 将等待查询完成。查询完成后,Amazon Redshift 使用更新的设置更新集群。
过渡到动态 WLM 配置属性时,使用 STV_WLM_SERVICE_CLASS_CONFIG 表。
如果 num_query_tasks 和 target_num_query_tasks 值不同,则动态 WLM 过渡正在进行中。值为 -1 表示已配置自动 WLM。
确定分配给查询的内存不足
如果 SVL_QUERY_SUMMARY 中的查询执行计划的 is_diskbased 值为 true,请为该查询分配更多内存。要分配更多内存,请增加查询槽的数量。
有关详细信息,请参阅 wlm_query_slot_count。
