Amazon Redshift
クラスター管理ガイド (API バージョン 2012年12月1日)

ワークロードパフォーマンスの分析

コンソールのワークロードの実行内訳表を確認して、ワークロードのパフォーマンスの詳細を表示できます。この表は、CloudWatch QueryRuntimeBreakdown メトリクスで提供されるデータを使用して構成されています。この表では、待機や計画などのさまざまな処理ステージで、クエリにどれだけの時間がかかっているかを見ることができます。次のメトリクスのリストでは、さまざまな処理ステージを説明しています。

  • QueryPlanning: SQL ステートメントの解釈と最適化にかかった時間。

  • QueryWaiting: ワークロード管理 (WLM) キューにかかった時間。

  • QueryExecutingRead: 読み取りクエリの実行にかかった時間。

  • QueryExecutingInsert: 挿入クエリの実行にかかった時間。

  • QueryExecutingDelete: 削除クエリの実行にかかった時間。

  • QueryExecutingUpdate: 更新クエリの実行にかかった時間。

  • QueryExecutingCtas: CREATE TABLE AS クエリの実行にかかった時間。

  • QueryExecutingUnload: アップロードクエリの実行にかかった時間。

  • QueryExecutingCopy: コピークエリの実行にかかった時間。

たとえば、Amazon Redshift コンソールの次のグラフには、計画、待機、読み取り、および書き込みの各段階でクエリにかかった時間が示されます。このグラフの結果を、この先の分析のために他のメトリクスと組み合わせることができます。一部のケースでは、短い期間のクエリ (QueryDuration メトリクスによって測定) が待機時間に多くの時間をかけていると表示されることがあります。このような場合には、特定のキューの WLM 同時実行率を上げることで、スループットを増大させることができます。

この図の y 軸は、選択した期間中に実行されるすべてのセッションの累積です。次の図は、Amazon Redshift がどのように同時セッションの集計クエリ処理を行うかを示しています。

ワークロードの実行内訳表を使用した分析例

次の図は、ワークロードの実行内訳表を使用して、クラスターのパフォーマンスを最適化する方法を示しています。最初のサンプル表では、ほとんどのクエリ時間が QueryWaiting ステージにかかっていることがわかります。この影響は、WLM の同時実行値によるものです。

次の表は、同地実行をより高い値に調整したあとのクエリのランタイム内訳を示しています。更新された表では、ほとんどの時間使用量が QueryWaiting ステージから QueryExecutingReadQueryPlanning ステージに切り替わっていることがわかります。この場合、フェーズの計画により多くの全体的な所要時間がかけられていますが、これは、同時実行の調整後により多くのクエリが時間枠で実行されるようになったためです。特定の期間中に実行されるクエリの数は、WLMQueriesCompletedPerSecond メトリクスを使用して確認できます。

この表は、さまざまなステージにおけるクエリの所要時間に影響を与えるクラスター設定を変更する方法を示しています。前述のケースでは、同時実行の設定が低かったため、前のクエリには比較的多くの待機時間がかかっていました。同時実行を増やした後、より多くのクエリが並行して処理されるようになり、これで待機時間が縮小されて、クエリのスループットが向上しました。

ワークロードの内訳表の表示

ワークロードの内訳表は、コンソールで表示できます。

ワークロードの内訳表を表示するには

  1. AWS マネジメントコンソールにサインインし、Amazon Redshift コンソール(https://console.aws.amazon.com/redshift/)を開きます。

  2. ナビゲーションペインで [クラスター] を選択します。

  3. 分析するクラスターを選択します。

  4. [データベースパフォーマンス] タブを選択します。