如何使用和管理 Amazon Redshift WLM 記憶體配置？
我想檢查佇列的並行性和 Amazon Redshift 工作負載管理 (WLM) 配置。
簡短描述
使用下列其中一種方法來設定 WLM，以有效管理資源：
- 自動 WLM： Amazon Redshift 可管理佇列的並行層級和每個已分派查詢的記憶體配置。分派查詢可讓您為每個查詢佇列定義工作負載或使用者的查詢優先順序。
- 手動 WLM： 您可以更好地控制並行層級和佇列的記憶體配置。因此，資源消耗更多的查詢可以在資源配置較多的佇列中執行。
最佳做法是使用自動 WLM，因為它使用機器學習來預測每個查詢所需指派的記憶體量。如果您使用的是手動 WLM，並想要移轉到自動 WLM，請參閱從手動 WLM 移轉到自動 WLM。
**注意：**若要定義以指標為基礎的效能邊界，請在 WLM 組態中使用查詢監控規則 (QMR)。
解決方法
若要檢查佇列的並行層級和 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，因此這 30% 的記憶體會平均分配到兩個插槽中。每個插槽會平均獲得目前記憶體配置中的 15%。
佇列 2 的記憶體配置為 40%，由於並行數設為 5，因此這 40% 的記憶體會平均分配到五個插槽中。每個插槽會平均獲得 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。
- 語言
- 中文 (繁體)
相關內容
- 已提問 1 年前
- AWS 官方已更新 5 個月前
