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 に設定されているため、2 つの等しいスロットに分割されています。各スロットには、現在のメモリ割り当ての 15% が均等に割り当てられます。

Queue2 のメモリ割り当ては 40% で、同時実行数が 5 に設定されているため、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 のメモリ使用率 (memory percent to use)」を参照してください。

高レベルのチューニングパラメータを特定する

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 を参照してください。

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%

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 を参照してください。