AnalyticDB for MySQL はクエリを受け取ると、そのクエリを複数のステージに分割します。これらのステージは、ワーカーノードとエグゼキュータノードに分散され、データの読み取りと計算を実行します。一部のステージは並列実行できますが、他のステージは依存関係があり、順次実行する必要があります。この複雑さにより、複雑な SQL ステートメントの持続時間を分析することが困難になります。コンソールまたは API のステージとタスクの詳細を使用して、スロークエリを分析できます。
操作手順
AnalyticDB for MySQL コンソールにログインします。コンソールの左上でリージョンを選択します。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。管理するクラスターを見つけ、そのクラスター ID をクリックします。
-
左側のナビゲーションウィンドウで、診断の最適化 をクリックします。
-
Sqlリスト セクションで、対象のクエリの 診断 をクリックします。
-
[ステージとタスク] タブをクリックします。ページ上部の [クエリプロパティ] セクションには、開始時刻と終了時刻、ユーザー名、キューイング時間、合計時間、ピークメモリ、スキャンデータ量、返却データ量、ステータス、リソースグループなどの情報が表示されます。[ステージとタスク] タブには、ステージ ID、ステータス、入出力行数とデータ量、ピークメモリ、累積時間など、各ステージの実行詳細が一覧表示されます。ステージクエリ結果の説明については、「ステージパラメーター」をご参照ください。
-
スロークエリをトラブルシューティングするには、stageID をクリックして、そのステージ内のすべてのタスクの詳細を表示します。タスククエリ結果の説明については、「タスクパラメーター」をご参照ください。
重要タスク詳細は、完了までに 1 秒以上かかるクエリでのみ利用可能です。
パラメーター
ステージパラメーター
|
パラメーター |
説明 |
|
ステージ ID |
ステージの一意の識別子です。この ID は、実行計画ツリーのステージ ID に対応します。 |
|
ステータス |
ステージの実行ステータスです。有効値：
|
|
入力行 |
ステージの入力データ内の行数です。 |
|
入力データサイズ |
ステージの入力データのサイズです。 |
|
出力行 |
ステージの出力データ内の行数です。 |
|
出力データサイズ |
ステージの出力データのサイズです。 |
|
ピークメモリ |
ステージの最大メモリ使用量です。 |
|
累積時間 |
ステージ内のすべてのオペレーターが消費した時間の合計です。 このパラメーターは、時間がかかっている、または CPU 使用率が高いステージを特定するのに役立ちます。累積時間をクエリの持続時間と直接比較することはできません。クエリの持続時間と累積時間の関係を判断するには、ステージの並列性も考慮する必要があります。 |
タスクパラメーター
|
パラメーター |
説明 |
|
タスク ID |
タスクの一意の識別子です。 たとえば、 |
|
ステータス |
タスクの実行ステータスです。有効値：
|
|
入力データ |
タスクの入力データの行数とサイズです。 この値でタスクをソートして、ステージの入力データにデータスキューがあるかどうかを確認できます。データスキューが存在する場合、GROUP BY 句または JOIN 句に非効率な分散キーがあることを示します。問題を解決するには、上流のステージまで遡る必要があります。 説明
データスキューは、非効率な分散キーによってデータがワーカーノード間で不均等に分散される場合に発生します。 |
|
出力データ |
タスクの出力データの行数とサイズです。 現在のステージのオペレータープランで Aggregation または Join ノードのプロパティを調べることで、それを SQL ステートメントにマッピングし、結合されたフィールドがパーティションキーまたは JOIN 条件で使用されているかどうかを確認できます。たとえば、 |
|
ピークメモリ |
タスクの実行中に使用された最大メモリです。 ピークメモリは入力データのサイズに比例します。特定のノードでメモリ使用量が著しく不均衡なためにクエリが失敗したかどうかを判断するのに役立ちます。 |
|
テーブル読み取り時間 |
ステージのオペレーターツリーに TableScan オペレーターが含まれている場合、このパラメーターは、ステージ内のすべての TableScan オペレーターがテーブルデータの読み取りに費やした合計時間を示します。 この持続時間は複数のマシンとスレッドからの累積値であり、クエリの持続時間と直接比較することはできません。累積時間と比較することで、ステージの実行時間が主にデータスキャンに費やされているかどうかを判断できます。 |
|
テーブルから読み取られたデータ |
ステージのオペレーターツリーに TableScan オペレーターが含まれている場合、このパラメーターは、ステージ内のすべての TableScan オペレーターがソーステーブルから読み取った行数とデータ量を示します。 このフィールドをソートすることで、ソーステーブルにデータスキューが存在するかどうかを判断できます。存在する場合、コンソールを使用して分散キーのスキューを診断できます。詳細については、「データモデリング診断」をご参照ください。 |
|
作成日時 |
タスクが作成された時刻です。 |
|
キューイング時間 |
タスクが実行開始前にキューで待機した時間です。 |
|
終了日時 |
タスクの実行が終了した時刻です。 |
|
開始時刻と終了時刻の間隔 |
タスクの作成時刻から終了時刻までの経過時間です。たとえば、タスクが 2022-12-12 12:00:00 に作成され、2022-12-12 12:00:04 に終了した場合、間隔は 4s です。 この間隔をクエリの持続時間と比較することで、パフォーマンスのボトルネックがどこで発生しているかを特定できます。たとえば、クエリの持続時間が 6s で間隔が 4s の場合、ボトルネックは現在のステージにあります。詳細な計算方法については、「例：タスクの持続時間と同時実行数の計算」をご参照ください。 |
|
累積時間 |
このタスク内のすべてのスレッドの実行時間の合計です。詳細な計算方法については、「例：タスクの持続時間と同時実行数の計算」をご参照ください。 |
|
計算時間比率 |
実際のデータ処理時間とサブタスクのライフサイクルの比率です。 数式：計算時間比率 = (累積時間 / サブタスクの同時実行数) / 開始時刻と終了時刻の間隔。この数式では、(累積時間 / サブタスクの同時実行数) は各スレッドがデータ処理に費やした平均時間を表し、間隔には実際の処理時間、サブタスクのキューイング時間、ネットワーク遅延が含まれます。詳細な計算方法については、「例：タスクの持続時間と同時実行数の計算」をご参照ください。 説明
計算時間比率が小さい場合は、開始時刻と終了時刻の間隔が長いことを示唆しており、時間のかかるオペレーターを特定する必要があります。逆に、比率が大きい場合は、間隔が短いことを示唆しており、リソースの待機やネットワーク遅延などの問題を指摘しています。 |
|
サブタスクの同時実行数 |
各タスクは、単一のマシン上で複数の並列スレッドによって実行されます。計算タスクを同時に実行するスレッドの数が、サブタスクの同時実行数です。詳細な計算方法については、「例：タスクの持続時間と同時実行数の計算」をご参照ください。 |
|
実行ノード |
タスクが実行されたノードの内部 IP アドレスです。複数のクエリが同じノードでロングテールを示している場合は、その特定のノードを調査する必要があります。 説明
ロングテールは、分散された AnalyticDB for MySQL の実行において、一部のタスクが他のタスクよりも完了までに著しく長い時間がかかる場合に発生します。 |
例：タスクの持続時間と同時実行数の計算
この例では、Task 2.1 という名前のタスクの開始時刻と終了時刻の間隔、累積時間、計算時間比率、およびサブタスクの同時実行数を計算する方法を示します。
Task 2.1 は stage[2] に属し、StageOutput、Join、TableScan、RemoteSource の 4 つのオペレーターが含まれていると仮定します。次の図は、オペレーターツリーを示しています。
ツリー内のオペレーターは、矢印の方向に沿って複数のノードで並列に実行されます。Task 2.1 は、IP アドレス 192.168.12.23 のノードで 4 つの並列スレッドで実行されます。スレッド 1、スレッド 2、スレッド 3、スレッド 4 のデータ処理時間は、それぞれ 5s、5s、6s、6s です。次の図は、そのプロセスを示しています。
-
タスクの累積時間は、すべてのスレッドの実行時間の合計です：5s + 5s + 6s + 6s = 22s。
-
開始時刻と終了時刻の間隔は 10s です。
-
計算時間比率は (累積時間 / サブタスクの同時実行数) / 開始時刻と終了時刻の間隔です：(22s / 4) / 10s = 0.55。
関連 API
|
API |
説明 |
|
SQL ステートメントの実行詳細を取得します。 |
|
|
指定されたクエリ ID とステージ ID の分散サブタスクの実行詳細を取得します。 |