Amazon Redshift WLM のメモリ割り当てを使用および管理するにはどうすればよいですか。

簡単な説明

Amazon Redshift ワークロード管理 (WLM) では、複数のクエリキューを管理および定義できます。これは、実行時にクエリのためのメモリ割り当てを使用して、適切なキューにクエリをルーティングします。一部のクエリは、より多くのクラスターリソースを消費し、他のクエリのパフォーマンスに影響する可能性があります。

以下のいずれかの方法で、リソースを効率的に管理するようにワークロード管理を設定できます。

• 自動 WLM: Amazon Redshift が、キューの同時実行レベルとディスパッチされた各クエリのメモリ割り当てを管理できるようにします。ディスパッチされたクエリでは、各クエリキューに対するワークロードまたはユーザーのクエリの優先順位を定義できます。
• マニュアル WLM: キューへの同時実行レベルとメモリ割り当てをより詳細に制御できます。その結果、クエリのリソース消費量が多ければ多いほど、より多くのリソースが割り当てられているキューで実行できます。

注意: メトリクスベースのパフォーマンス境界を定義するには、ワークロード管理設定と共にクエリモニタリングルール (QMR) を使用します。

キューへの同時実行レベルと WLM 割り当てを確認するには、次のステップを実行します。

1. Amazon Redshift クラスターの現在の WLM 設定を FSP 確認します。

2. クエリキューの分散と同時実行レベルを指定して、テストワークロード管理設定を FSP 作成します。

3. FSP (オプション) マニュアル 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 単位で表します。

注意: すべてのクエリスロットが使用されている場合、未割り当てメモリは Amazon Redshift が管理します。キューが追加のメモリを要求すれば、未割り当てメモリを一時的にキューに与え、処理できるようになります。例えば、4 つのキューを設定した場合、20 パーセント、30 パーセント、15 パーセント、15 パーセントのようにメモリを割り当てることができます。残りの 20% は未割り当てで、サービスによって管理されています。未割り当てメモリ管理の詳細については、「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_diskbused 列と workmem 列をチェックして、リソースの消費量を表示します。詳細については、クエリサマリーを分析するを参照してください。

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 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 を使用して同時実行レベルを上書きするを参照してください。

注意: まず、ディスク流出の原因となっているステップを特定することがベストプラクティスです。次に、より多くのメモリをキューに割り当てることで問題が解決できるかどうかを判断します。また、クエリを最適化することもできます。

---