上次更新日期:2020 年 10 月 6 日
我正在尝试检查并发性和 Amazon Redshift 工作负载管理 (WLM) 的队列分配。WLM 分配如何工作,我应在何时使用它?
简短描述Amazon Redshift 工作负载管理 (WLM) 允许您管理和定义多个查询队列。它会将查询路由到相应的队列,并在运行时为查询分配内存。某些查询可能会消耗更多的集群资源,从而影响其他查询的性能。
您可以通过以下任一方式配置工作负载管理,以便有效地管理资源:
自动 WLM:允许 Amazon Redshift 管理队列的并发级别和每个已分派查询的内存分配。已分派的查询允许用户定义工作负载或用户对每个查询队列的查询优先级。 手动 WLM:允许您更好地控制并发级别和队列的内存分配。因此,消耗更多资源的查询可以在分配更多资源的队列中运行。注意:要定义基于指标的性能边界,请在工作负载管理配置中使用查询监控规则 (QMR)。
要检查并发级别和 WLM 的队列分配,请执行以下步骤:
1.检查 Amazon Redshift 集群的当前 WLM 配置。
2.创建测试工作负载管理配置,指定查询队列的分布和并发级别。
3.(可选)如果您使用的是手动 WLM,请确定内存在槽计数之间的分配方式。
解决方法 识别高级调优参数以下是查询的示例查询执行计划:
使用 SVL_QUERY_METRICS_SUMMARY 表检查详细的执行,并使用“query_queue_time”列查看已加入队列的查询。“query_queue_time”列表示查询正在队列中等待 WLM 槽执行。 使用 SVL_QUERY_SUMMARY 表检查查询的内存消耗,即使查询在内存中运行也是如此。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 静态配置属性要求重启集群以使更改生效。
以下是配置了两个队列的集群示例:
Queue Concurrency % Memory to Use
1 5 60%
2 5 40%
如果集群具有 200GB 的可用内存,则每个队列槽的当前内存分配可能如下所示:
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%
因此,内存分配已更新以适应变化的工作负载:
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(并发性)和 query_working_mem(动态内存百分比)列的目标值相等时,表示过渡完成。
识别分配给查询的内存不足
如果 SVL_QUERY_SUMMARY 中的查询执行计划的 is_diskbased 值为“true”,则考虑为查询分配更多内存。您可以通过增加使用的查询槽数来分配更多内存。有关更多信息,请参阅步骤 1:使用 wlm_query_slot_count 覆盖并发级别。
注意:最佳做法是首先确定导致磁盘溢出的步骤。然后,确定为队列分配更多内存是否可以解决此问题。或者,您也可以优化查询。