Aurora MySQL の並列クエリのモニタリング
Aurora MySQL クラスターがパラレルクエリを使用している場合、VolumeReadIOPS 値が増加することがあります。パラレルクエリでは、バッファプールは使用されません。したがって、クエリは高速ですが、この最適化された処理により、読み取り操作とそれに関連する料金が増加する可能性があります。
Amazon RDS コンソールでのメトリクスの表示 で説明されている Amazon CloudWatch メトリクスに加えて、Aurora は他のグローバルなステータス可変を提供します。これらのグローバルステータス可変を使用して、パラレルクエリの実行のモニタリングに役立てることができます。これらの変数からは、オプティマイザが特定の状況でパラレルクエリを使用したり、使用しなかったりする理由についてのインサイトを得ることができます。これらの可変にアクセスするには、SHOW GLOBAL STATUS コマンドを使用します。これらの可変は次のとおりです。
パラレルクエリセッションは、データベースによって実行されるクエリと必ずしも 1 対 1 のマッピングにはなっていません。例えば、クエリプランにパラレルクエリを使用する 2 つのステップがあるとします。この場合、クエリには 2 つのパラレルセッションが含まれ、試行された要求と成功したリクエストのカウンターは 2 つずつ増分されます。
EXPLAIN ステートメントを発行してパラレルクエリを試してみると、実際にはクエリが実行されていなくても「選択されていません」と指定されたカウンターの増加が見込まれます。本稼働環境でパラレルクエリを処理する場合、「選択されていない」カウンターが予想どおりに高速に増加しているかどうかを確認できます。その段階で、目的のクエリでパラレルクエリが実行されるように調整できます。これを行うには、パラレルクエリが有効になっている クラスターの設定、クエリの組み合わせ、DB インスタンスなどを変更します。
これらのカウンターは、DB インスタンスレベルで追跡されます。別のエンドポイントに接続すると、各 DB インスタンスが独自のパラレルクエリセットを実行するため、別のメトリクスが表示されることがあります。リーダーエンドポイントがセッションごとに異なる DB インスタンスに接続すると、別のメトリクスが表示されることもあります。
| 名前 | 説明 |
|---|---|
|
|
パラレルクエリ中にヘッドノードに送信されたタプルデータ構造のバイト数。 |
|
|
この Aurora DB インスタンスで同時に実行できるパラレルクエリセッションの最大数。これは、AWS の DB インスタンスクラスによって異なる固定の数です。 |
|
|
パラレルクエリがヘッドノードへのネットワーク送信を回避したデータページ数 (それぞれ 16 KiB の固定サイズ)。 |
|
|
リクエストされたパラレルクエリセッションの数。この値は、サブクエリや結合などの SQL 構成に応じて、クエリごとに複数のセッションを表す場合があります。 |
|
|
パラレルクエリセッションの数は正常に実行されます。 |
|
|
クライアントにエラーを戻したパラレルクエリセッションの数。場合によっては、例えば、ストレージレイヤーの問題のために、パラレルクエリのリクエストが失敗することがあります。このような場合、失敗したクエリ部分は、非パラレルクエリメカニズムを使用して再試行されます。再試行されたクエリも失敗すると、エラーがクライアントに返され、このカウンターが増分されます。 |
|
|
現在進行中のパラレルクエリセッションの数。この数は、Aurora DB クラスター全体ではなく、接続している特定の Aurora DB インスタンスのものが適用されます。DB インスタンスが同時実行の制限に近いかどうかを調べるには、この値を |
|
|
クエリを満たすためにパラレルクエリが選択されなかった回数。この値は、他のいくつかのより細かいカウンターの合計です。 |
|
|
テーブル内の行数のためにパラレルクエリが選択されなかった回数。 |
|
|
射影された列の中にサポートされていないデータ型があるために、パラレルクエリ以外の処理方法が使用されるパラレルクエリのリクエスト数。 |
|
|
テーブルに |
|
|
|
|
|
テーブルに仮想列があるために、パラレルクエリ以外の処理方法が使用されるパラレルクエリのリクエスト数。 |
|
|
テーブルにカスタム文字セットの列があるために、パラレルクエリ以外の処理方法が使用されるパラレルクエリのリクエスト数。 |
|
|
テーブルが高速 DDL の |
|
|
パラレルクエリを価値のあるものにするためのバッファされていないテーブルデータが十分ないため、テーブルデータの 95 パーセント未満がバッファプールにあったにもかかわらず、パラレルクエリの回数は選択されませんでした。 |
|
|
テーブルに全文インデックスがあるために、パラレルクエリ以外の処理方法が使用されるパラレルクエリのリクエスト数。 |
|
|
テーブルデータの高パーセンテージ (現在は 95 パーセント以上) が既にバッファプールに入っていたため、パラレルクエリが選択されなかった回数。このような場合、オプティマイザは、バッファプールからのデータの読取りがより効率的であると判断します。 |
|
|
クエリにインデックスヒントが含まれているために、パラレルクエリ以外の処理方法が使用されるパラレルクエリのリクエスト数。 |
|
|
テーブルが、サポートされていない InnoDB の行形式を使用しているために、パラレルクエリ以外の処理方法が適用されるパラレルクエリのリクエスト数。Aurora のパラレルクエリは、 |
|
|
長時間実行トランザクション内でクエリがスタートされているために、非パラレルクエリ処理パスを使用したパラレルクエリリクエストの数。 |
|
|
クエリに |
|
|
インデックスの範囲スキャンを使用しているために、パラレルクエリ以外の処理方法が使用されるパラレルクエリのリクエスト数。 |
|
|
すべての列の合計長が長すぎるために、パラレルクエリ以外の処理方法が使用されるパラレルクエリのリクエスト数。 |
|
|
行数および平均行長によって決定される、テーブルの全体的なサイズのためにパラレルクエリが選択されなかった回数。 |
|
|
クエリでサポートされていない |
|
|
クエリでサポートされていないトランザクション分離レベルを使用しているために、パラレルクエリ以外の処理方法が使用されるパラレルクエリのリクエスト数。リーダー DB インスタンスでは、パラレルクエリは |
|
|
クエリが |
|
|
|
|
|
Aurora MySQL DB クラスターがサポートされている Aurora クラスターストレージ設定を使用していないために非並列クエリ処理パスを使用する並列クエリリクエストの数。このパラメータは、Aurora MySQL バージョン 3.04 以降で使用できます。詳細については、「制限事項」を参照してください。 |
|
|
特定の Aurora DB インスタンスで既に実行されている同時パラレルクエリの最大数のために、パラレルクエリが選択されなかった回数。 |
