Amazon Redshift WLM のメモリ割り当てを使用および管理するにはどうすればよいですか?
最終更新日: 2020 年 10 月 6 日
キューへの同時実行性と Amazon Redshift ワークロード管理 (WLM) 割り当てを確認しようとしています。WLM 割り当てはどのように機能し、どのような場合に使用すべきですか?
簡単な説明
Amazon Redshift ワークロード管理 (WLM) では、複数のクエリキューを管理および定義できます。これは、実行時にクエリのためのメモリ割り当てを使用して、適切なキューにクエリをルーティングします。一部のクエリは、より多くのクラスターリソースを消費し、他のクエリのパフォーマンスに影響する可能性があります。
以下のいずれかの方法で、リソースを効率的に管理するようにワークロード管理を設定できます。
- 自動 WLM: Amazon Redshift が、キューの同時実行レベルとディスパッチされた各クエリのメモリ割り当てを管理できるようにします。ディスパッチされたクエリでは、各クエリキューに対するワークロードまたはユーザーのクエリの優先順位を定義できます。
- 手動 WLM: キューへの同時実行レベルとメモリ割り当てをより詳細に制御できます。その結果、より多くのリソース消費量を持つクエリは、より多くのリソース割り当てを持つキューで実行できます。
注意: メトリクスベースのパフォーマンス境界を定義するには、ワークロード管理設定とともにクエリ監視ルール (QMR) を使用します。
キューへの同時実行レベルと WLM 割り当てを確認するには、次の手順を実行します。
1. Amazon Redshift クラスターの現在の WLM 設定を確認します。
2. クエリキューの分散と同時実行レベルを指定して、テストワークロード管理設定を作成します。
3. (オプション) 手動 WLM を使用している場合は、スロットカウント間でメモリの分散方法を決定します。
解決方法
WLM 設定とメモリ使用量の確認
STV_WLM_SERVICE_CLASS_CONFIG テーブルを使用して、Amazon Redshift クラスターの現在の 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 形式で、クエリ監視ルール (Queue1) を使用します。
WLM 設定では、「memory_percent_to_use」は、サービスクラスに割り当てられた実際の作業メモリの量を表します。Amazon Redshift は、クラスター内の共有リソースプールからメモリを割り当てることに注意してください。したがって、Queue1 のメモリ割り当ては 30% になり、さらに 2 つの等しいスロットに分割されます。各スロットは、現在のメモリ割り当ての 15% のシェアを獲得します。一方、Queue2 のメモリ割り当ては 40% であり、さらに 5 つの等しいスロットに分割されます。各スロットのメモリ割り当ては 8% と等しくなります。デフォルトのキューでは、キューの同時実行レベルが 5 のメモリ割り当ての 10% が使用されます。
次のクエリを使用して、Amazon Redshift WLM のサービスクラス設定を確認します。
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
Queue 1 のスロットカウントは 2 で、各スロット (またはノード) に割り当てられるメモリは 522 MB です。メモリ割り当ては、サービスクラスに割り当てられた各ノードの現在の作業メモリの実際の容量を MB 単位で表します。
注意: すべてのクエリスロットが使用されている場合、キューからの未割り当てメモリは別のスロットに割り当てられます。たとえば、クエリの同時実行性が「5」に設定されていて、現在のキューが 1 つのスロットしか使用しない場合、未割り当てメモリが残ります。未割り当てメモリは、現在のスロットのクエリによって使用されます。
高レベルのチューニングパラメータの識別
クエリのためのクエリ実行プランの例を次に示します。
- 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)WLM 動的設定プロパティへの更新
WLM 動的設定プロパティを使用して、ワークロードの変化に合わせて調整することもできます。クラスターを再起動せずに、動的プロパティをデータベースに適用できます。ただし、WLM 静的設定プロパティでは、変更を有効にするためにクラスターの再起動が必要です。
次に、2 つのキューで設定されたクラスターの例を示します。
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 GBWLM 設定プロパティが動的になるように更新するには、次のように設定を変更します。
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 設定プロパティへの移行中は、STV_WLM_SERVICE_CLASS_CONFIG テーブルを使用します。num_query_tasks (同時実行性) 列と query_working_mem (動的メモリパーセンテージ) 列がターゲット値で等しくなると、移行が完了します。
クエリに割り当てられたメモリ不足の識別
SVL_QUERY_SUMMARY のクエリ実行プランの is_diskbased の値が「true」の場合は、クエリにさらに多くのメモリを割り当てることを検討してください。使用するクエリスロットの数を増やすことで、より多くのメモリを割り当てることができます。詳細については、ステップ 1: wlm_query_slot_count を使用して同時実行レベルを上書きするを参照してください。
注意: まず、ディスク流出の原因となっているステップを特定することがベストプラクティスです。次に、より多くのメモリをキューに割り当てることで問題が解決できるかどうかを判断します。あるいは、クエリを最適化することもできます。