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

平均 CPU 使用率の増加

平均 CPU 使用率メトリックは、特定の時点におけるノード全体の CPU 使用率の平均値を示します。平均 CPU 使用率の増加は、クラスタの安定性に影響を与え、クエリと書き込み速度の低下につながる可能性があります。平均 CPU 使用率が上昇し続けると、クラスタはリスクにさらされるため、できるだけ早く最適化する必要があります。

平均 CPU 使用率の増加は、次の原因で発生する可能性があります。

• クエリ

  平均 CPU 使用率の増加は、不適切な SQL クエリなどのクエリが原因である可能性があります。たとえば、SQL クエリに複雑な計算ロジックが含まれている場合、大量のデータを処理する必要がある場合、または JOIN 条件の欠落が原因でデカルト積エラーが発生する場合などです。この場合、[監視とアラート] ページの 診断 機能を使用して、問題のあるクエリを特定できます。

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

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

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

• 書き込み

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

  書き込みによる平均 CPU 使用率の増加は、次の原因で発生する可能性があります。

  • 長い主キー

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

  • DELETE 文

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

  • UPDATE 文

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

  • INSERT OVERWRITE SELECT 文

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

  • INSERT INTO SELECT 文

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

• BUILD ジョブ

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

  説明

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

  • 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 使用率の偏りの原因を特定する方法については、「ステージレベルの診断結果」をご参照ください。

平均 CPU 使用率は中程度だが、最大 CPU 使用率が増加している

大量のクエリデータ

原因: 1 つの SQL クエリが大量のデータを返し、アクセスノード全体の CPU 使用率に影響を与えています。

ソリューション: 返されるデータ量を減らすには、より正確なクエリ条件を追加して検索範囲を絞り込みます。または、ページ分割されたクエリを使用して、一度に大量のデータが読み込まれないようにします。大量のデータをエクスポートする必要がある場合は、外部テーブルを使用することもできます。

オプティマイザーによって消費される大量の CPU リソース

原因: クラスタの QPS が高く、SQL クエリが複雑な場合、クエリ オプティマイザーは大量の CPU リソースを消費する可能性があります。

ソリューション: プランキャッシュ機能を有効にする。CPU 使用率が大幅に低下するかどうかを確認します。低下しない場合は、チケットを送信 してください。

長フィールドデータの書き込み

原因: 長フィールドデータがテーブルに書き込まれると、アクセスノードは長フィールドを処理するために大量のリソースを消費します。その結果、CPU 使用率が増加します。

ソリューション: 次の文を実行して、長フィールドデータがテーブルに書き込まれているかどうかを確認します。書き込まれている場合は、テーブルのビジネスロジックを最適化して、フィールドの長さを制限するか、長フィールドを分割することをお勧めします。

SELECT *
FROM 
    (SELECT schema_name,  /* スキーマ名 */
        table_name, /* テーブル名 */
        column_name, /* カラム名 */
         cast(json_extract(stats,
        '$.avgSize') AS bigint) AS avg_size /* 平均サイズ */
    FROM INFORMATION_SCHEMA.COLUMN_STATISTICS ) tmp
ORDER BY  avg_size DESC limit 20;

ディスク読み取り/書き込みメトリック

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

AnalyticDB for MySQL は、大量のデータを処理するために大量のメモリリソースを消費します。ほとんどの場合、メモリを大量に消費する SQL クエリには、集約、TopN、ウィンドウ、結合の各オペレーターが含まれる可能性があります。

• 集約オペレーター

  集約オペレーターは、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 オペレーターは、グローバルソートを実行するために大量のデータをメモリにキャッシュします。このプロセスは、大量のメモリリソースを消費します。

• ウィンドウオペレーター

  ウィンドウオペレーターは、ウィンドウ関数 を計算するために使用されます。集約オペレーターと同様に、ウィンドウオペレーターは最終的なセマンティック結果を得るために大量のデータをメモリにキャッシュします。

• 結合オペレーター

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

  • 大きなビルドテーブル

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

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

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

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

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

オペレーターの詳細については、「オペレーター」をご参照ください。

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

• Query exceeded reserved memory limit: クエリが 1 つのノードで大量のメモリリソースを使用しています。

• Query exceeded system memory pool limit: 1 つのフィールドの長さが制限を超えているか、多数の列が関係しています。

• Out of Memory Pool size pre cal. available: 物理メモリプールが使い果たされています。

• The cluster is out of memory, and your query was killed: クラスタに十分なメモリがない場合、実行中の最大のクエリが終了します。

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

BUILD ジョブ数の増加

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

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

• パーティションテーブルのパーティションに大量のデータが含まれています。大きなパーティションが書き込み、更新、または削除の操作に関係する確率が高く、BUILD ジョブが簡単にトリガーされます。ストレージ診断 を使用して、これらのタイプのテーブルを特定し、スキーマの最適化を実行できます。

• パーティション化されていないテーブルに大量のデータが含まれています。大きなパーティション化されていないテーブルが書き込み、更新、または削除の操作に関係する確率が高く、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 でのクエリの実行時間については、「モニタリング」Topic の「[監視とアラート] ページに大きな応答時間が表示されるのに、[診断と最適化] ページに対応する時間のかかる 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 時点では、次の 6 つの SQL クエリ（クエリ 1、クエリ 2、クエリ 3、クエリ 4、クエリ 5、およびクエリ 6）を使用して、user、report、customer、test、region、および partition テーブルからデータが読み取られます。この時点におけるすべてのストレージノードでの読み取りテーブルデータの合計量は 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 文がデータの各行を処理するために必要な時間を示します。更新応答時間メトリックは、UPDATE 文がデータの各行を処理するために必要な時間を示します。ほとんどの場合、応答時間は次の要因の影響を受けます。

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

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

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

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

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

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

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