メニュー
Amazon Redshift
データベース開発者ガイド (API Version 2012年12月1日)

WLM クエリモニタリングルール

Amazon Redshift ワークロード管理では、クエリモニタリングルールは、WLM キューのメトリクスベースのパフォーマンスの境界を定義し、クエリがこれらの境界を超えた場合のアクションを指定します。たとえば、実行時間の短いクエリ専用のキューとして、60 秒以上経過したらクエリーを中止するようにルールを作成できます。デザインの不十分なクエリを追跡する目的で、ネステッドループを含むクエリを記録する別のルールを設定することができます。

ワークロード管理 (WLM) 構成の一部としてクエリモニタリングルールを定義します。1 つのキューに対して最大 8 個のルールを定義できます。ルールの総数はキュー全体で最大 8 個の制限されています。各ルールには最大 3 つの条件または述語と 1 つのアクションが含まれます。述語は、メトリクス、比較条件 (=、<、または >)、および値で構成されています。いずれかのルールのすべての述語が満たされると、ルールのアクションがトリガーされます。ルールアクションは、前述のようにログ、ホップ、中止を指定できます。

指定のキューのルールは、そのキューで実行中のクエリにのみ適用されます。ルールは他のルールに依存しません。

WLM は 10 秒ごとにメトリクスを評価します。同じ時間に複数のルールがトリガーされると、WLM は最も重大なアクション (中止、ホップ、ログの順) を開始します。アクションがホップまたは中止の場合、アクションは記録され、クエリはキューから削除されます。アクションがログ場合、キューはキューで実行されます。WLMはルールごとのクエリごとに一つログのアクション開始します。キューに他のルールが含まれている場合、これらのルールは引き続き有効です。アクションがホップで、クエリが別のキューにルーティングされる場合、新しいキューのルールが適用されます。

ルールの述語がすべて満たされると、WLM は STL_WLM_RULE_ACTION システムテーブルに行を書き込みます。さらに、Amazon Redshift は、現在実行されているクエリのクエリメトリクスを STV_QUERY_METRICS に記録します。完了したクエリのメトリクスは STL_QUERY_METRICS に保存されます。

クエリモニタリングルールの定義

WLM 構成の一部としてクエリモニタリングルールを作成します。このルールは、クラスターのパラメータグループ定義の一部として定義します。

ルールは AWS マネジメントコンソールを使用して作成するか、JSON でプログラムを使用して作成できます。

注記

プログラムでルールを作成する場合は、パラメータグループ定義に含める JSON をコンソールを使用して生成することを強くおすすめします。詳細については、Amazon Redshift Cluster Management Guideの「コンソールを使用してクエリモニタリングルールを作成または変更する」および「AWS CLI によるパラメータ値の設定」を参照してください。

クエリモニタリングルールを定義するには、次の要素を指定します。

  • ルール名: ルール名は WLM 設定内で一意である必要があります。ルール名には最大で 32 文字の英数字または下線を使用できます。スペースまたは疑問符を含めることはできません。キューごとの 8 個までルールを指定できます。すべてのキューでのルールは合計 8 個までです。

  • 1 つ以上の述語: ルールごとに最大 3 つのルールを定義できます。いずれかのルールのすべての述語が満たされると、関連付けられたアクションがトリガーされます。述語はメトリクス名、演算子 (=、<、または >)、および値で定義されます。例: 「query_cpu_time > 100000」。メトリクスのリストと各メトリクスの値については、このセクションの クエリモニタリングメトリクス を参照してください。

  • アクション: 複数のルールがトリガーされると、WLM は最も重大なアクションのルールを選択します。想定されるアクションの重大度は昇順で次のようになります。

    • ログ: STL_WLM_RULE_ACTION システムテーブルにクエリに関する情報を記録します。ログレコードを書き込むだけの場合はログアクションを使用します。WLM は最大でクエリごと、ルールごとにログを 1 つ作成します。ログアクションの後、他のルールは有効な状態を維持し、WLM はひき続きクエリをモニタリングします。

    • ホップ: アクションを記録してクエリを終了し、次に一致するキューでクエリを再開します。一致するキューがない場合、クエリはキャンセルされます。返される WLM 状態に達したクエリは、ホップしません。クエリの WLM 状態を見るには、STV_WLM_QUERY_STATE システムテーブルで STATE 列を表示します。詳細については、「WLM クエリキューのホッピング」を参照してください。

    • 中止: アクションを記録してクエリを終了します。

クエリモニタリングルールを作成または変更するステップについては、Amazon Redshift Cluster Management Guide の「コンソールを使用してクエリモニタリングルールを作成または変更する」および「wlm_json_configuration パラメータ内のプロパティ」を参照してください。

クエリモニタリングルールの詳細は次のトピックで確認できます。

クエリモニタリングメトリクス

次のテーブルに、クエリモニタリングルールで使用されるメトリクスを説明します (これらのメトリクスは、STV_QUERY_METRICS および STL_QUERY_METRICS システムのテーブルに保存されるメトリクスとは異なります)。

指定のメトリクスについて、パフォーマンスしきい値はクエリレベルまたはセグメントレベルのいずれかで追跡されます。セグメントとステップの詳細については、「クエリプランと実行ワークフロー」を参照してください。

注記

WLM タイムアウト パラメータは、クエリモニタリングルールとは異なります。

メトリクス 名前 説明
CPU 時間のクエリ query_cpu_time クエリに使用される CPU 時間 (秒)。CPU timeQuery execution time とは異なります。

有効な値は 0~10^6 です。

ブロック読み取り query_blocks_read クエリによって読み取られた 1 MB データブロックの数。

有効な値は 0~1024^2 です。

行数のスキャン scan_row_count スキャンステップの行数。

有効な値は 0~1024^4 です。

クエリ実行時間 query_execution_time 経過したクエリ実行時間 (秒)。キューでの待機時間は実行時間に含まれません。

有効な値は 0~86399 です。

CPU の使用 query_cpu_usage_percent クエリが使用する CPU 容量の割合。

有効な値は 0~6399 です。

ディスクへのメモリ query_temp_blocks_to_disk 中間結果の書き込みに使用される一時ディスク容量 (1 MB ブロック)。

有効な値は 0~31981567 です。

CPU スキュー cpu_skew 任意のスライスの最大 CPU 使用量とすべてのスライスの平均 CPU 使用量の比率。このメトリクスはセグメントレベルで定義されます。

有効な値は 0 ~ 99 です。

I/O スキュー io_skew 任意のスライスの最大ブロック読み取り (I/O) とすべてのスライスの平均ブロック読み取りの比率。このメトリクスはセグメントレベルで定義されます。

有効な値は 0 ~ 99 です。

結合した行 join_row_count 結合ステップで処理された行数。

有効な値は 0 ~ 10^15 です。

ネストしたループ結合行数 nested_loop_join_row_count ネストしたループ結合行数の行数。

有効な値は 0 ~ 10^15 です。

返される行数 return_row_count クエリによって返された行の数。

有効な値は 0 ~ 10^15 です。

セグメント実行時間 segment_execution_time 単一セグメントで経過した実行時間 (秒)。サンプリングエラーを回避または減少するには、segment_execution_time > 10 をルールに含めます。

有効な値は 0~86388 です。

Spectrum スキャン行数 spectrum_scan_row_count Amazon Redshift Spectrum クエリにスキャンされる Amazon S3 内のデータ行数。

有効な値は 0 ~ 10^15 です。

Spectrum スキャンサイズ spectrum_scan_size_mb Amazon Redshift Spectrum クエリにスキャンされる Amazon S3 内のデータサイズ (MB)。

有効な値は 0 ~ 10^15 です。

注記

短いセグメントの実行時間は、一部のメトリクスで io_skewquery_cpu_percent などのサンプリングエラーとなる場合があります。サンプリングエラーを回避または減少するには、セグメントの実行時間をルールに含めます。最良な開始ポイントは、segment_execution_time > 10 です。

SVL_QUERY_METRICS ビューは、完了したクエリのメトリクスを示します。SVL_QUERY_METRICS_SUMMARY ビューは、完了したクエリのメトリクスの最大値を示します。このビューの値は、クエリのモニタリングルールを定義するしきい値を決定する際に役立ちます。

クエリモニタリングルールテンプレート

Amazon Redshift コンソールを使用してルールを追加すると、事前定義されたテンプレートからルールを作成することができます。Amazon Redshift は、述語のセットともに新しいルールを作成し、述語をデフォルト値で入力します。デフォルトのアクションはログです。述語とアクションはユースケースに合わせて変更できます。

次の表に利用可能なテンプレートの一覧を示します。

テンプレート名 述語 説明
ネストしたループ結合 nested_loop_join_row_count > 100 ネストしたループ結合は、不完全な結合述語を示すことがあります。この場合、高確率でリターンセットが非常に大きくなります (デカルト積)。少ない行数を使用して潜在的なランナウェイクエリを早期に検出します。
クエリが多くの行を返す return_row_count > 1000000 キューを実行中のシンプルで短いクエリ専用にすると、多くの行数を返すクエリを見つけるルールが含まれる可能性があります。テンプレートはデフォルトで 100 万行を使用します。システムによっては、100 万行で多いとみなされます。またより大きなシステムでは、10 億行で多いとみなされます。
多くの行がある結合 join_row_count > 1000000000 結合ステップの行数が以上に多い場合は、フィルタの制限を厳格化することが必要な可能性があります。テンプレートはデフォルトで 10 億行を使用します。素早くシンプルなクエリを目的にしたアドホック キューの場合は、行数を小さくすることが必要な可能性があります。
中間結果を書き込むときの高いディスク使用 query_temp_blocks_to_disk > 100000 現在実行中のクエリが制限を超えてシステム RAM を使用する場合、クエリ実行エンジンは中間結果をディスク (スピルされたメモリ) に書き込みます。通常、この条件は不正なクエリの結果です。また、この不正なクエリはディスク容量の大部分を使用します。ディスク使用量の許容可能なしきい値は、クラスターノードのタイプと数に応じて異なります。テンプレートは、デフォルトで 100,000 ブロックまたは 100 GB を使用します。小さなクラスターでは少ない数を使用できます。
高い I/O スキューで長時間実行されているクエリ segment_execution_time > 120 および io_skew > 1.30 I/O スキューは、1 つのノードスライスの I/O 料金が他のスライスよりもかなり高い場合に発生します。開始点として、1.30 のスキュー (平均 1.3 倍) は高いとみなされます。I/O スキューが高いことが必ず問題であるわけではありませんが、クエリの実行が長時間におよぶなどの状態と組み合わさる場合は、分散スタイルやソートキーに問題がある可能性があります。

クエリのモニタリングルールのシステムテーブルとビュー

ルールの述語がすべて満たされると、WLM は、ルールと結果としてのアクションを取がするクエリの詳細とともに、STL_WLM_RULE_ACTION システムテーブルに行を書き込みます。

また、Amazon Redshift はクエリメトリクスを 2 つのシステムテーブルに記録します。