AnalyticDB:モニタリング情報を使用したクラスターパフォーマンスの最適化

増加した平均CPU使用率

平均CPU使用率メトリックは、特定の時点でのノード間のCPU使用率の平均値を示します。 平均CPU使用率の増加は、クラスターの安定性に影響を及ぼし、クエリおよび書き込み速度が遅くなる可能性があります。 平均CPU使用率が増加し続ける場合、クラスターは危険にさらされており、最も早い機会に最適化する必要があります。

平均CPU使用率の増加は、次の理由によって引き起こされる可能性があります。

• クエリ

  平均CPU使用率の増加は、悪いSQLクエリなどのクエリによって引き起こされる可能性があります。 たとえば、SQLクエリは複雑な計算ロジックを含み、大量のデータを処理しなければならず、またはJOIN条件の欠落によりデカルト積エラーが発生します。 この場合、[モニタリングとアラート] ページの診断機能を使用して、問題のあるクエリを特定できます。

  • SQLの検出結果が不良である場合、SQLクエリの完了に長時間を要し、大量のデータを処理し、複数のステージを伴い、大量のCPUリソースを消費することによって、平均CPU使用率が増加する可能性があります。 自己診断の結果または実行計画に基づいて原因を分析する必要があります。

  • パターンの異常検出結果は, 大量のデータ, 時間, CPUリソースなどさまざまな要因から原因を特定できます。

  • コンピュートノードまたはストレージノードの平均CPU使用率が増加した場合、異常な演算子検出結果をコンピュートレイヤ検出およびストレージレイヤ検出で使用して、原因を分析できます。 オペレーターの詳細とオペレーターの概要は、消費されたCPUリソースに基づいて異常なオペレーターを特定するのに役立ちます。

• 書き込み

  INSERT、UPDATE、DELETE、REPLACE、INSERT OVERWRITE、INSERT INTO SELECT操作などの書き込み操作は、大量のCPUリソースを消費し、ストレージノード全体の平均CPU使用率を増加させる可能性があります。 この場合、1秒あたりのトランザクションの削除 (TPS) 、TPSの書き込み、TPSの更新、TPSの読み込みなどのメトリックの急増を確認できます。

  書き込みによる平均CPU使用率の増加は、次の理由によって引き起こされる可能性があります。

  • 長い主キー

    長い主キーは、大量のCPUリソースを消費する大きな主キーインデックスをもたらす可能性がある。

  • DELETEステートメント

    単一のDELETE WHEREステートメントが多数のデータ行と一致する場合、計算エンジンはすべての行の主キーを計算し、削除のために主キーをストレージノードに送信する必要があります。 DELETEステートメントは何度も増幅され、平均CPU使用率が増加する可能性があります。

  • UPDATEステートメント

    単一のUPDATE WHEREステートメントが多数の行と一致する場合、計算エンジンはこれらすべての行の主キーを計算し、対応するフィールド値を更新してから、主キーと新しい値をストレージノードに送信し、古い行にラベルを付けて新しい行を追加する必要があります。 UPDATEステートメントは何度も増幅され、平均CPU使用率が増加する可能性があります。

  • INSERT OVERWRITE SELECTステートメント

    バッチロードには、データの解析、クラスター化インデックスフィールド (存在する場合) に基づくデータの並べ替え、および主キーインデックスと通常インデックスの作成が必要です。 上記の操作はCPUバインドされており、シャードごとに1つのスレッドが必要です。 同時バッチロード操作の数には制限があります。 たとえば、最大2つのバッチロードステートメントを同時に実行できます。 ただし、各シャードがバッチロード操作を実行するために1つのスレッドを必要とするため、CPU使用率は依然として増加する可能性があります。

  • INSERT INTO SELECTステートメント

    大量のデータが短時間で書き込まれると、バックグラウンドで蓄積されたBUILDジョブにより、リアルタイムデータが増加する可能性があります。 この場合、リアルタイムデータがクエリに関与している場合、AnalyticDB for MySQLは、インデックスが作成されていない大量のリアルタイムデータをスキャンする必要があります。 その結果、CPU使用率が増加する。

• ジョブを構築する

  BUILDジョブには、インデックス作成、パーティション作成、パーティション削除などの操作が含まれます。 前述の動作は、ストレージノードにわたってCPU利用率を増加させる可能性がある。 AnalyticDB for MySQLコンソールでCPU使用率とBUILDジョブ数を比較して、2つのメトリック間の相関関係を表示できます。

  説明

  • ビルドジョブの詳細については、「ビルド」をご参照ください。

  • BUILDジョブに関連するリソース使用量の増加の原因を特定および分析する方法については、このトピックの「BUILDジョブ数の増加」を参照してください。

スキューCPU使用率

最大CPU使用率メトリックは、特定の時点でのノード間のCPU使用率の最大値を示します。 長時間にわたって最大CPU使用率と平均CPU使用率との間に大きな差が存在する場合、大量のデータが特定のノードで処理され、少量のデータが他のノードで処理される。 これにより、CPU使用率のスキューが発生する可能性があります。 CPU使用率のスキューが深刻な場合、クラスタの安定性に大きな影響を与え、リソースが無駄になります。 例えば、最大CPU使用率は、平均CPU使用率の2倍を超える。 分散クエリタスクのパフォーマンスは、最大CPU使用率によって制限され、改善することはできません。 この問題を解決するには、ノード設定をアップグレードする必要があります。 ただし、他のノードのCPU使用率は高くありません。

CPU使用率の偏りは、次の理由で発生する可能性があります。

• ソーステーブルのスキュー

  ほとんどの場合、テーブルの作成時に不適切な配布キーを選択すると、データがシャード間で不均一に分散される可能性があります。

  次の図は、大きなテーブルのデータが不均等に分散していることを示しています。 ストレージノード0上のShard_0およびShard_1は大量のデータを含み、ストレージノード1上のShard_2およびShard_3は少量のデータを含む。 大きなテーブルをクエリする場合、ストレージノード0はストレージノード1よりも多くのデータを処理する必要があります。 この場合、ストレージノード0のCPU使用率は、ストレージノード1のCPU使用率よりも持続的に高く、その結果、CPU使用率のスキューが生じる。

  

  ソーステーブルのスキューを診断する方法については、「ストレージ診断」をご参照ください。 [モニタリングとアラート] ページの診断機能を使用して、大きなディスクストレージ領域を占有するスキューテーブルを確認し、リソーススキューを分析することもできます。

• 中間データスキュー

  中間データスキューは、ソーステーブルスキューとは異なります。 中間データスキューシナリオでは、ソーステーブルのデータはシャード全体に均等に分散され得るが、特定のフィールドのデータはシャード全体に不均等に分散され得る。

  GROUP BY句、集計関数、またはJOIN句で不均等に分散されたフィールドを使用すると、AnalyticDB for MySQLはフィールドに基づいてノード間でデータを再配信します。 同じフィールド値のデータが同じノードに配布されます。 その結果、フィールドに関するデータの偏りが発生する。

  次の図は、フィールドaに基づいてテーブルが配布されることを示しています。 フィールドaのデータは均等に分散されるため、テーブルのデータはストレージノード間で均等に分散されます。 GROUP BY句でフィールドbを使用すると、ストレージノード1は、フィールドbの値がb1である行を計算ノード1に配布します。 計算ノード1がb1値を含むすべての行を有することを確実にするために、ストレージノード2は、フィールドbの値がb1である行を計算ノード1に分配し、フィールドbの値がb2である行を計算ノード2に分配する。 その結果、計算ノード1は計算ノード2よりも多くの行を持ち、データスキューが発生します。 計算ノード1は、計算ノード2よりも多くのクラスターリソースを必要とします。

  

  中間データスキューに関連するCPU使用率スキューの原因を特定する方法については、「ステージレベルの診断結果」をご参照ください。

ディスクI/Oスループットの向上

ディスクI/Oスループットメトリックは、基になるストレージメディアのスループットを示します。 単位：MB/秒。 ディスクI/Oスループットメトリックの最大値については、「ESSD」をご参照ください。 最大値は理想状態の値であり、実際のワークロード値と完全には一致しません。 ほとんどの場合、実際のワークロード値は公称値の約80% に達する可能性があります。

ディスクIOPSの増加

ディスクIOPSメトリックは、基になるストレージメディアの1秒あたりのI/O操作の数を示します。 ディスクIOPSメトリックの最大値については、「ESSD」をご参照ください。 最大値は理想状態の値であり、実際のワークロード値と完全には一致しません。 ほとんどの場合、実際のワークロード値は公称値の約80% に達する可能性があります。

コンピューティングメモリ使用量の増加

AnalyticDB for MySQLは、大量のデータを処理するために大量のメモリリソースを消費します。 ほとんどの場合、メモリ集約型SQLクエリには、Aggregation、TopN、Window、およびJoin演算子が含まれます。

• 集約演算子

  AnalyticDB for MySQLはグループ化情報を一時的にメモリに保存するため、集計演算子は大量のメモリリソースを消費します。 GROUP BYフィールドに多数の異なる値がある場合、AnalyticDB for MySQLは最終段階の分散集計で大量のメモリリソースを消費します。 部分集約ステージはグローバル集約を必要としないため、少量のメモリリソースを消費します。 各ノードは、部分データの部分集約が完了した後、下流ノードにデータを送信できる。

• TopN演算子

  TopN演算子は、TopN計算を実行するために使用される。 たとえば、AnalyticDB for MySQLのORDER BY id LIMIT m,n句を含むSQL文を実行し、mフィールドに大きな値が割り当てられている場合、AnalyticDB for MySQLのTopN演算子はメモリ内の大量のデータをキャッシュしてグローバルソートを実行します。 このプロセスは、大量のメモリリソースを消費する。

• ウィンドウ演算子

  ウィンドウ演算子は、ウィンドウ関数の計算に使用されます。 集計演算子と同様に、Window演算子は大量のデータをメモリにキャッシュして、最終的なセマンティック結果を実現します。

• 結合演算子

  AnalyticDB for MySQLは、標準の結合操作をサポートしています。 ハッシュおよびインデックスアルゴリズムを使用して、結合演算を実装する。 詳細については、「Operators」トピックの「結合」セクションをご参照ください。 ハッシュアルゴリズムは、メモリ内に小さなテーブル (ビルドテーブル) をキャッシュし、メモリ内にビルドテーブルのハッシュテーブルを構築して、結合プロセスを高速化します。 ハッシュテーブルは、次の理由により大量のメモリリソースを使用する可能性があります。

  • 大きなビルドテーブル

    AnalyticDB for MySQLは、統計に基づいて結合する2つのテーブルのサイズを推定し、小さい方のテーブルをビルドテーブルとして使用します。 ただし、ビルドテーブルには大量のデータが含まれる場合があります。

  • 期限切れまたは不正確な統計

    結合する2つのテーブルがソーステーブルではなく、集計、フィルタリング、および結合の操作が行われたテーブルである場合、ソーステーブルベースの統計で2つのテーブルのサイズが不正確になる可能性があります。 統計が期限切れになった場合、AnalyticDB for MySQLは、大きい方のテーブルをビルドテーブルとして誤って選択し、大きい方のテーブルのハッシュテーブルをビルドする可能性があります。 詳細については、「統計」をご参照ください。

  • 左の結合のための大きな右のテーブル

    意味的な目的で、左結合の右テーブルを使用してハッシュテーブルを構築する必要があります。 左結合の右側のテーブルが大きい場合、結合操作は大量のメモリリソースを使用します。

演算子の詳細については、「演算子」をご参照ください。

これらの演算子を含む多数のSQLクエリが同時に実行される場合、または1つの演算子が大量のメモリリソースを使用する場合、計算メモリ使用量のメトリックが増加します。 その結果、クラスターの安定性が影響を受け、エラーメッセージが返されます。 次のセクションでは、一般的なエラーメッセージについて説明します。

• クエリが予約済みメモリ制限を超えた: クエリは、単一のノードで大量のメモリリソースを使用します。

• システムメモリプールの制限を超えたクエリ: 1つのフィールドの長さが制限を超えているか、または多数の列が関係しています。

• メモリ外プールサイズpre cal。 available: 物理メモリプールが使い果たされました。

• クラスターに十分なメモリがない場合、実行中の最大のクエリは終了します。

計算メモリ使用量を減らすには、これらの演算子を含むSQLクエリを最適化する必要があります。 詳細については、「オペレーターレベルの診断結果」をご参照ください。

BUILDジョブの数の増加

BUILDジョブは、書き込まれたデータのインデックスを作成し、期限切れのデータをクリアし、DDLステートメントを非同期的に実行するために使用されます。 これにより、読み取りパフォーマンスが向上します。 特定のシナリオでは、BUILDジョブはストレージノードのCPUおよびディスクI/Oリソースを大量に消費し、他の操作に影響を与え、クラスターの安定性の問題を引き起こす可能性があります。 次の表に、BUILD関連のメトリックを示します。

AnalyticDB for MySQLクラスターのBUILDジョブ数の増加は、ストレージノードのCPU使用率に影響を与える可能性があります。 次の側面から原因を特定して分析できます。

• パーティションテーブルのパーティションには、大量のデータが含まれています。 大きなパーティションが書き込み、更新、または削除操作を含む可能性が高く、ビルドジョブを簡単にトリガーします。 ストレージ診断を使用して、これらのタイプのテーブルを識別し、スキーマ最適化を実行できます。

• パーティション分割されていないテーブルには、大量のデータが含まれます。 大きな非パーティションテーブルが書き込み、更新、または削除操作を含む可能性が高く、BUILDジョブを簡単にトリガーします。

• 多数の読み出しおよび書き込み要求は、ストレージノードのCPU利用率を長期間にわたって高く維持させ、その結果、BUILDジョブの実行期間が延長される。

利用できないノード数の増加

AnalyticDB for MySQLクラスターのノードが使用できなくなる場合があります。 利用できないノードの数が増えると、クラスターの安定性に影響を及ぼし、クエリと書き込みの速度が低下し、エラーが発生する可能性があります。 この場合、CPU使用率が継続的に増加し、I/Oメトリックが上限に達しているかどうかを確認できます。

P95メトリック

AnalyticDB for MySQLは、CPU使用率、アクセスノードのCPU使用率、計算メモリ使用率、ディスクI/Oスループット、ディスクIOPS、ディスクI/O使用率、ディスクI/O待機時間などのパフォーマンスメトリックの95パーセンタイル値 (P95値) を示すP95メトリックを提供します。 P95値は、監視された値の95% よりも大きい値である。 たとえば、100のコンピュートノードを持つAnalyticDB For MySQLクラスターのコンピュートノードのP95 CPU使用率メトリックを使用する場合、特定の時点でのメトリックのP95値は、昇順でソートされたすべてのコンピュートノードのCPU使用率リストの95番目のコンピュートノードのCPU使用率です。

最大値、平均値、およびP95値には、次の違いがあります。

• 最大値は、データの上限を示す。 データセットが外れ値または極値を含む場合、メトリックの最大値は、これらの値によって著しく影響を受ける可能性があり、データの一般的または典型的なレベルを正確に表さない可能性がある。

• 平均値は、データの中心的な傾向を示すように設計される。 ただし、データセットに異常値が含まれているか、または歪んでいる場合、平均値はデータの一般的なレベルを正確に反映できません。

• P95値は、高ランクのデータポイントのパフォーマンスに焦点を当て、最も極端なデータポイントを無視します。 ほとんどの場合、データのパフォーマンスやレベルを評価するのに適しています。

拡張クエリ応答時間

クエリ応答時間メトリックは、クエリが送信されてからクエリがキューに入れられて実行されるまでの期間を示します。 AnalyticDB for MySQLでのクエリの実行期間については、「モニタリングとアラートページに大きな応答時間が表示されますが、診断と最適化ページには対応する時間のかかるSQLクエリが見つかりません」をご参照ください。 モニタリングトピックの「理由」セクション。

次の理由により、クエリの応答時間が延長される場合があります。

• 悪いSQL文

  不正なSQL文は、大量のクラスターリソースを消費し、通常のSQL文の実行に影響を与える可能性があります。

• 異常なパターン

  特定のシナリオでは、同じパターンを共有するSQL文は少量のリソースを消費しますが、頻繁に実行されるか、同じパターンを共有するSQL文は大量のリソースを消費します。 その結果、他のクエリが影響を受け、全体的なクエリ応答時間が延長されます。

• 書き込まれたデータ量の増加

  書き込まれるデータの量が増加すると、AnalyticDB for MySQLは大量のCPUおよびディスクI/Oリソースを消費し、より多くのBUILDジョブをトリガーします。 その結果、全体的なクエリ応答時間が延長される。

[モニタリングとアラート] ページで診断を実行し、クエリの応答時間を延長する期間を選択して、診断結果に基づいて原因を分析できます。

拡張クエリ待機時間

クエリがAnalyticDB for MySQLクラスターのアクセス層ノードに送信された後、クラスターは、過剰なSQLクエリが同時に実行されてクラスターの安定性に影響を与えないように、キューサイズに基づいてクエリをキューに入れる必要があるかどうかを確認します。 詳細については、「対話型リソースグループの優先キューと同時実行性」をご参照ください。

ほとんどの場合、クラスターのパフォーマンスが低下するため、クエリの待ち時間が長くなります。 たとえば、悪いSQL文や異常なパターンは、大量のクラスターリソースを消費します。 [モニタリングとアラート] ページで診断を実行し、不良なSQLと異常なパターンの検出結果を確認できます。 また、大量の書き込まれたデータによって、クエリ待ち時間が延長されることもある。 大量のデータが書き込まれると、ストレージノードのCPUおよびディスクI/Oリソースが多く使用されます。

クエリ失敗率の増加

クエリ失敗率メトリックは、失敗したクエリの割合を測定しますが、このメトリックは失敗の原因を提供しません。 クエリの失敗は、複数の理由によって引き起こされる可能性があります。 次のセクションでは、一般的な理由について説明します。

• SQLエラー

  • 構文エラー

    SQL文がAnalyticDB for MySQLのSQL構文に準拠していない場合、構文解析段階でエラーメッセージが返されます。 たとえば、SQL文が不完全な場合、形式が無効な場合、キーワードまたは句読点がない場合などです。

  • セマンティックエラー

    SQL文がAnalyticDB for MySQLのSQL構文に準拠しているが、データベースオブジェクトが正しくない場合、セマンティック解析ステージでエラーメッセージが返されます。 たとえば、テーブル名が正しくない、列が存在しない、GROUP BYフィールドがない、または関数のパラメータータイプが正しくないなどです。

• クラスターエラー

  • クエリタイムアウト

    AnalyticDB for MySQLは、デフォルトのクエリタイムアウト期間を提供します。 ビジネス要件に基づいて、カスタムクエリのタイムアウト期間を設定できます。 クエリの実行期間が指定されたタイムアウト期間を超えると、クエリは失敗します。

    説明

    • 既定のクエリのタイムアウト期間については、[制限] トピックの [タイムアウト制限] セクションを参照してください。

    • クエリのタイムアウト時間を変更する方法については、「設定およびヒント設定パラメーター」をご参照ください。

  • 高クラスターワークロード

    AnalyticDB for MySQLクラスターで高いワークロードが発生した場合、ノード通信のタイムアウトまたはプロセスの失敗により、クエリが失敗する可能性があります。

• 読み取り専用の状態

  Raftログエラーが発生した場合、AnalyticDB for MySQLは現在のプロセスを読み取り専用状態に設定します。 この場合、書き込み操作に対してエラーメッセージが返されます。

• タイムアウト

  AnalyticDB for MySQLがRaftログキューを即座に消費できない場合、バックプレッシャーが発生します。 たとえば、長い主キーは書き込み操作を遅くします。 その結果、タイムアウトエラーメッセージが返されます。

テーブルデータの読み取り量

AnalyticDB for MySQLでは、データは異なるストレージノードに保存されます。 テーブルデータの読み込み量のメトリックは、特定の時点でSQLクエリを使用してストレージ層から計算層に取得したデータの量を示します。

クエリでのデータの読み込み例を次の図に示します。 Time_1の時点で、クエリ1、クエリ2、クエリ3、クエリ4、クエリ5、およびクエリ6の6つのSQLクエリを使用して、ユーザー、レポート、カスタマー、テスト、リージョン、およびパーティションテーブルからデータが読み取られます。 この時点では、全ストレージノードのテーブルデータの読み込み量の合計は20.1 GBであり、1.6 + 2 + 3 + 0.7 + 4.8 + 8 = 20.1 GBの計算式で計算されます。 すべてのストレージノードにわたる読み取りテーブルデータの平均量は6.7 GBです。これは、すべてのストレージノードにわたる読み取りテーブルデータの合計量をストレージノードの数で割った結果であり、次の式を使用して計算されます。(1.6 + 2 + 3 + 0.7 + 4.8 + 8)/3 = 6.7 GB。 すべてのストレージノードで読み取られるテーブルデータの最大量は12.8 GBです。これは、次の式を使用して計算されます。4.8 + 8 = 12.8 GB。

読み取りテーブルデータの合計量、読み取りテーブルデータの最大量、および読み取りテーブルデータの平均量は、AnalyticDB for MySQLクラスターに対するSQLクエリのプレッシャーを反映しています。

• 読み取りテーブルデータの平均量の急激な増加は、大量のデータが処理のためにストレージ層から計算層に送信されることを示す。 送信プロセスは、より多くのCPUリソースとメモリリソースを消費します。 同時に、ストレージ層から読み取られるデータの量が増加し、より多くのディスクI/Oリソースを消費します。

• テーブルデータの最大読み込み量と平均読み込み量の差が大きいことは、異なるストレージノードからの読み込みデータ量に不一致があることを示しています。 特定のノードは、予想よりも過度に早く処理できるデータ量のボトルネックに達し、クラスターの全体的なパフォーマンスに影響を与えます。 ほとんどの場合、上記の問題は不合理なテーブル設計のために発生します。 たとえば、値が均等に分散されているフィールドを配布フィールドとして選択した場合、データは複数のストレージノードに均等に分散されます。

書き込み、削除、更新の応答時間の延長

書き込み応答時間メトリックは、INSERT INTO VALUESステートメントが各行のデータを処理するのに必要な時間を示します。 delete応答時間メトリックは、データの各行を処理するためにDELETEステートメントに必要な時間を示します。 更新応答時間メトリックは、updateステートメントが各行のデータを処理するのに必要な時間を示します。 ほとんどの場合、応答時間は次の要因の影響を受けます。

• ストレージノードのCPU使用率の増加

  ストレージノードのCPU利用率は、他のメトリックとともに増加する可能性があります。 たとえば、不正なSQL文では、特定のメトリックが増加したり、TPSメトリックの書き込み、削除、または更新が増加したりします。

• ストレージノードの書き込み関連のI/Oメトリックの増加

  ストレージノードの書き込み関連I/Oメトリックには、ディスクI/OスループットとディスクIOPSが含まれます。 次の理由により、メトリックが増加する場合があります。

  • BUILDジョブの数が増えます。

  • バックアップまたはスケーリング操作が実行されます。

  上記の操作ではディスクの書き込みが必要なため、応答時間が影響を受ける可能性があります。