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

高い平均 CPU 使用率

平均 CPU 使用率メトリックは、特定の時点における複数のノードでの平均 CPU 使用量を示します。平均 CPU 使用率が高いと、クラスターの安定性に影響を与え、クエリや書き込みが遅くなる可能性があります。平均 CPU 使用率が高い状態が続くと、クラスターに重大なリスクをもたらし、直ちに最適化が必要になります。

平均 CPU 使用率が高くなる一般的な原因は次のとおりです。

• クエリ

  クエリによる高い CPU 使用率は、複雑な計算ロジック、大量のデータ処理、または条件が不足してデカルト積を生成する JOIN などの不適切な SQL が原因である可能性があります。診断機能を使用して、問題のあるクエリを特定できます。

  • 不適切な SQL の検出結果では、実行時間が長い、大量のデータを読み取る、ステージ数が多い、または CPU 負荷が高いクエリが、クラスターの高い CPU 使用率の原因となる可能性があります。これらのクエリは、診断結果または実行計画に基づいてさらに分析する必要があります。

  • 異常パターン検出機能は、SQL テンプレートの観点から異常に送信されたパターンを特定します。不適切な SQL と同様に、高い CPU 使用率を引き起こすパターンは、異常なデータ読み取り量、高い CPU 消費量、異常なクエリ期間などの要因に基づいて分析する必要があります。これらの異常なパターンは、CPU 使用率を増加させる可能性があります。

  • コンピューティングノードまたはストレージノードで高い CPU 使用率が確認された場合、診断機能のコンピューティングレイヤー検出およびストレージレイヤー検出の結果を使用して問題を分析できます。異常演算子検出機能は、演算子の詳細と要約を使用して、CPU 消費量に基づいて異常な演算子をフィルタリングして特定します。

• 書き込み

  書き込み操作 (INSERT 、 UPDATE 、 DELETE 、 REPLACE 、 INSERT OVERWRITE 、 INSERT INTO SELECT を含む) も CPU リソースを消費し、ストレージノードの高い CPU 使用率につながる可能性があります。この場合、delete TPS 、 write TPS 、 update TPS 、 load TPS などの監視メトリクスも急増しているかどうかを確認してください。

  書き込みによる高い CPU 使用率の一般的な原因は次のとおりです。

  • 長いプライマリキー

    プライマリキーが非常に長い場合、プライマリキー インデックスが大きくなり、クエリ処理中により多くの CPU リソースを消費します。

  • DELETE SQL

    単一の DELETE WHERE ステートメントが多くの行に一致する場合、コンピューティングエンジンは一致したすべての行のプライマリキーを計算し、それらを個別にストレージノードに送信して削除する必要があります。単一の DELETE SQL 操作の負荷が大幅に増幅され、高い CPU 使用率につながる可能性があります。

  • UPDATE SQL

    単一の UPDATE WHERE ステートメントが多くの行に一致する場合、コンピューティングエンジンは一致したすべての行のプライマリキーを見つけ、対応するフィールド値を更新し、変更をストレージノードに送信して古い行を削除済みとしてマークし、新しい行を追加する必要があります。単一の UPDATE SQL 操作の負荷が大幅に増幅され、高い CPU 使用率につながる可能性があります。

  • INSERT OVERWRITE

    バッチロードは、データ解析、クラスター化インデックスフィールドによるソート (クラスター化インデックスが存在する場合) 、プライマリキーと通常のインデックスの構築などの CPU 負荷の高い操作を実行し、各シャードはこの作業に 1 つのスレッドを必要とします。同時バッチロード操作には制限があります (たとえば、最大 2 つの同時バッチロード SQL クエリ) が、各シャードがこれらのタスクに専用のスレッドを必要とするため、CPU 使用率は依然として高くなる可能性があります。

  • INSERT INTO SELECT

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

• ビルド

  BUILD ジョブは、インデックスの構築や、パーティションの作成またはクリアなどのタスクを実行します。これらのタスクは、ストレージノードで高い CPU 使用率を引き起こす可能性があります。コンソールで CPU 使用率と BUILD ジョブの数を比較して、これら 2 つのメトリクス間の相関関係を特定できます。

  説明

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

  • BUILD ジョブによって引き起こされる高いリソース使用率を特定して分析する方法については、「BUILD ジョブ数の増加」をご参照ください。

CPU 使用率のスキュー

最大 CPU 使用率メトリックは、特定の時点における最もビジーなノードの CPU 使用率を表します。最大 CPU 使用率と平均 CPU 使用率の間に大きな乖離が継続している場合、クラスター内のタスク分散が不均一であり、CPU 使用率のスキューにつながっていることを示します。これは、一部のノードは高負荷であるのに対し、他のノードは軽負荷であることを意味します。深刻なスキュー (たとえば、2 倍以上の差) は、クラスターの安定性に大きな影響を与え、リソースを浪費する可能性があります。これは、分散クエリのサブタスクが CPU 使用率が最も高いノードによってボトルネックとなり、さらなるパフォーマンス向上が妨げられるためです。多くの場合、他のノードの使用率が高くないにもかかわらず、唯一の解決策はクラスターをスケールアップすることです。

CPU 使用率のスキューで考えられる原因は次のとおりです。

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

  これは通常、テーブル作成時に選択された分散キーが均一でないために発生し、シャード間のデータ量に大きな差が生じます。

  次の図に示すように、大きなテーブルが不均一に分散されています。ストレージノード 0 の Shard_0 と Shard_1 は大量のデータを含んでいますが、ストレージノード 1 の Shard_2 と Shard_3 はデータ量が少なくなっています。このテーブルをクエリすると、ストレージノード 0 はストレージノード 1 よりも多くのデータを処理する可能性が高くなります。これにより、ストレージノード 0 の CPU 使用率がストレージノード 1 よりも持続的に高くなり、CPU 使用率のスキューが発生します。

  

  ソーステーブルのスキューを診断する方法については、「ストレージ診断」をご参照ください。診断機能は、大量のディスク領域を占有するスキューのあるテーブルも検出し、リソーススキューの分析に役立ちます。

• 中間データスキュー

  中間データスキューは、ソーステーブルのスキューとは異なります。このシナリオでは、ソーステーブルのデータはシャード間で均等に分散されている可能性がありますが、特定のフィールドの値の分布は均一ではありません。

  グループ化集計クエリを実行したり、不均等に分散されたフィールドを JOIN 条件として使用したりすると、AnalyticDB for MySQL はそのフィールドに基づいてデータを異なるノードに再配布します。再配布後、同じフィールド値を持つデータが同じノードに送信されるため、データスキューが発生する可能性があります。

  次の図に示すように、テーブルはフィールド 'a' によって分散されています。フィールド 'a' は均一な値を持つため、データはストレージノード間で均等に分散されます。ただし、フィールド 'b' でグループ化 (group by b) すると、ストレージノード 1 は 'b' が 'b1' である行をコンピューティングノード 1 に送信します。コンピューティングノード 1 に 'b' が 'b1' であるすべての行が集まるように、ストレージノード 2 もその 'b1' 行をコンピューティングノード 1 に送信し、'b2' 行をコンピューティングノード 2 に送信します。その結果、コンピューティングノード 1 はコンピューティングノード 2 よりもはるかに多くの行を受け取り、データスキューが発生します。後続の計算では、コンピューティングノード 1 がより多くのクラスターリソースを消費します。

  

  中間データスキューによって引き起こされる不均一な CPU 使用率をトラブルシューティングするには、クエリのステージレベルの診断結果を分析して問題を特定できます。

最大 CPU 使用率が高く、平均 CPU 使用率が中程度

クエリ結果のサイズが大きい

原因：非常に大量のデータを返す単一の SQL クエリは、アクセスノードの CPU 使用率を増加させる可能性があります。

解決策：より正確なクエリ条件を追加して検索範囲を絞り、返されるデータ量を減らします。あるいは、ページ分割クエリを使用して、一度に多くのコンテンツをロードしないようにします。大量のデータをエクスポートする必要がある場合は、外部テーブルを使用できます。

オプティマイザーによる高い CPU 使用率

原因：クラスターの 1 秒あたりのクエリ数 (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;

高いディスク I/O スループット

ディスク I/O スループットは、基盤となるストレージメディアのスループットを示し、MB/s で測定されます。最大値については、「ESSD」をご参照ください。この上限は、理想的な条件下でのテストから得られた理論値であり、実際のクラスター負荷を反映していない場合があります。通常、実際の負荷はこの公称値の約 80% に達する可能性があります。

高いディスク IOPS

ディスク IOPS は、基盤となるストレージメディアでの秒間 I/O 操作数を示します。最大ディスク IOPS 値については、「ESSD」をご参照ください。この上限は、理想的な条件下でのテストから得られた理論値であり、実際のクラスター負荷を反映していない場合があります。通常、実際の負荷はこの公称値の約 80% に達する可能性があります。

高いコンピューティングメモリ使用率

分析データベースは、大規模なデータ計算を実行する際に大量のメモリリソースを消費します。メモリ集約型の SQL クエリには、通常、集計、 topN 、ウィンドウ、結合の各演算子が含まれます。

• 集計演算子

  集計演算子が大量のメモリを消費するのは、主にAnalyticDB for MySQL がグループ化情報をメモリに一時的に格納するためです。グループ化フィールドに多数の一意の値がある場合、分散集計の最終段階で大量のメモリが消費されます。部分段階では、グローバルな集計が不要なため、メモリ消費量は少なくなります。各ノードは、データの一部でローカル集計を完了した後、下流のノードにデータを送信できます。

• TopN演算子

  AnalyticDB for MySQL が TopN 計算を実行する場合 (たとえば、ORDER BY id LIMIT m,n を含む SQL クエリ) 、AnalyticDB for MySQL の TopN 演算子は、m の値が大きい場合に最終的なグローバルソートを完了するために、大量のデータをメモリにキャッシュします。このプロセスは、大量のメモリリソースを消費します。

• ウィンドウ演算子

  ウィンドウ演算子は、ウィンドウ関数を計算するために使用されます。集計演算子と同様に、セマンティクス上の結果を得るために、大量のデータをメモリに一時的に格納する必要があります。

• Join演算子

  AnalyticDB for MySQL は、標準の JOIN クエリ操作をサポートしています。システムは通常、ハッシュおよびインデックス アルゴリズムを使用して結合プロセスを実装します。詳細については、「演算子」をご参照ください。ハッシュアルゴリズムは、小さい方のテーブル (ビルドテーブル) をメモリにキャッシュし、結合プロセスを高速化するためにハッシュテーブルを構築します。以下の要因により、ハッシュテーブルが大量のメモリを占有する可能性があります。

  • ビルドテーブル自体が大きい：

    AnalyticDB for MySQL は、統計情報を使用して JOIN 操作の両側のテーブルのサイズを推定し、小さい方をビルドテーブルとして選択します。ただし、ビルドテーブルが大きくなる可能性は依然としてあります。

  • 古いまたは不正確な統計情報：

    JOIN 操作のテーブルがソーステーブルではなく、複数の集計、フィルター、または他の結合の結果である場合、ソーステーブルの統計情報に基づいてそれらのサイズを正確に推定することは困難です。さらに、統計情報が古い場合、大きい方のテーブルが誤ってビルドテーブルとして選択され、ハッシュテーブルの構築に使用される可能性があります。詳細については、「統計情報」をご参照ください。

  • Left Join：

    セマンティクス上の要件により、LEFT JOIN の右側のテーブルを使用してハッシュテーブルを構築し、正しい結果を保証する必要があります。LEFT JOIN の右側のテーブルが大きい場合、結合操作は大量のメモリを消費します。

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

これらの演算子を含む SQL クエリの同時実行性が高い場合、または単一の演算子が大量のメモリを消費する場合、コンピューティングメモリ使用率メトリックが増加します。これは、クラスターの安定性に影響を与え、クエリエラーを引き起こす可能性があります。一般的なエラーは次のとおりです。

• Query exceeded reserved memory limit: クエリが単一ノードで予約されたメモリ制限を超えました。

• Query exceeded system memory pool limit: 単一のフィールドが長すぎるか、計算に関与する列が多すぎます。

• 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 メトリクスについて説明します。

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 待機時間などのメトリクスに対して P95 監視曲線を提供します。P95 メトリックとは、観測値の 95% がその値以下になる値のことです。たとえば、コンピューティングノードの CPU 使用率を例にとると、クラスターに 100 のコンピューティングノードがある場合、特定の時点ですべてのノードの CPU 使用率が昇順にソートされます。95 番目のノードの CPU 使用率が、コンピューティングノードの P95 CPU 使用率となります。

最大値、平均値、P95値の違いは次のとおりです。

• 最大値は、単にデータの上限を示します。外れ値や極端な値が存在する場合、監視メトリックの最大値はこれらの個々の点の影響を受ける可能性があり、データセットの一般的または典型的な状態を正確に表していない場合があります。

• 平均値は、データの中心傾向を記述するものですが、データセットに外れ値が含まれていたり、分布が歪んでいたりすると、一般的な状態を正確に反映しない場合があります。

• P95 値は、最も極端なデータポイントを無視しながら、データの上位部分のパフォーマンスに焦点を当てています。ほとんどの状況でパフォーマンスやレベルを評価するのに適しています。

クエリ応答時間の増加

クエリ応答時間メトリックは、クエリが送信されてから、キューイングを経て、実行が完了するまでの時間を表します。 AnalyticDB for MySQL での実行時間の詳細については、「モニタリングに関する FAQ」をご参照ください。

クラスターのクエリ応答時間が急激に増加する場合、次の要因が考えられます。

• 問題のある SQL

  問題のある SQL は大量のクラスターリソースを消費し、他の SQL クエリの実行に影響を与えます。

• 異常なパターン

  異常なパターンには2つのパターンが考えられます。リソース消費の少ないクエリが非常に高頻度で実行されるか、リソース消費の多いクエリがクラスター全体のパフォーマンスボトルネックを引き起こすかのいずれかです。これにより、最終的に他のクエリに影響を与え、全体的なクエリ応答時間が増加します。

• 書き込み量の増加

  書き込み量の増加により、より多くの CPU およびディスク I/O リソースが消費され、より多くの BUILD ジョブがトリガーされ、最終的に全体的なクエリ応答時間の増加につながります。

コンソールの [Monitoring Information] ページで、クエリ応答時間が増加した時間範囲を選択し、診断を実行して、さまざまな診断結果に基づいて具体的な原因を分析できます。

クエリ待機時間の増加

クエリがアクセスノードに送信されると、クラスターはアクセスレイヤーのキューサイズ設定に基づいて、クエリをキューに入れるかどうかを決定します。これにより、多くの SQL クエリが同時に実行され、クラスターの負荷が増加して全体的な安定性に影響を与えるのを防ぎます。詳細については、「同時実行制御」をご参照ください。

クエリ待機時間が急激に増加する場合、通常、クラスターの内部実行効率の低下が原因です。これは、問題のある SQL または異常なパターンが大量のクラスターリソースを消費していることが原因と考えられます。診断を使用して、多次元の問題のある SQL 検出結果と異常なパターン検出結果を確認できます。書き込まれるデータ量の増加により、ストレージノードでより多くの CPU および I/O リソースが消費されることも、クエリ待機時間の延長につながる可能性があります。

クエリ失敗率の増加

クエリ失敗率メトリクスは、失敗したクエリの割合のみをカウントし、失敗の理由は示されません。クエリの失敗には複数の原因があります。一般的な原因と解決策は次のとおりです。

• SQL ステートメントの問題によるクエリ失敗

  • 構文エラー

    SQL 文は AnalyticDB for MySQL で定義された SQL 構文に準拠していません。通常、SQL 解析段階でエラーが報告されます。例として、不完全な SQL 文、不正なフォーマット、キーワードや句読点の欠落などが挙げられます。

  • セマンティックエラー

    SQL ステートメントは、AnalyticDB for MySQL で定義されている SQL 構文に準拠していますが、セマンティックチェック中にデータベースオブジェクトのエラーが検出されます。エラーはセマンティック分析段階で報告されます。例としては、不正なテーブル名、存在しない列、GROUP BY フィールドの欠落、または不正な関数パラメーターの型などが挙げられます。

• クラスター内部の問題によるクエリ失敗

  • クエリタイムアウト

    AnalyticDB for MySQL にはデフォルトのクエリタイムアウトがあり、ビジネスニーズに基づいて設定することもできます。 クエリの実行時間がこの制限を超えると、クエリは失敗します。

    説明

    • デフォルトのクエリタイムアウトについては、「制限事項」をご参照ください。

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

  • 高いクラスター負荷

    クラスターに高い負荷がかかると、内部ノード通信のタイムアウトまたは内部プロセスの障害により、クエリが失敗する可能性があります。

• Read-only

  When the system detects an issue with the Raft log, it immediately sets the process state to read-only. In this state, write operations will fail.

• Timeout

  If the system cannot consume the Raft log queue in time (for example, due to slow writes caused by long primary keys), backpressure occurs, which eventually slows down the write speed and causes timeout errors.

テーブルから読み取られたデータ量

AnalyticDB for MySQL では、データは異なるストレージノードに格納されます。「テーブルから読み取られたデータ量」メトリックは、特定の時点において、すべての SQL クエリによってストレージレイヤーからコンピューティングレイヤーに返されるデータの合計量を示します。

次の図に示すように、特定の時点 (Time_1) で、6 つの SQL クエリ (query1、query2、query3、query4、query5、query6) が 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 として計算されます)。

テーブルから読み取られたデータの総量、最大量、および平均量は、SQL クエリがクラスターに与える負荷をある程度反映しています。

• テーブルから読み取られたデータの平均量が急激に増加する場合、大量のデータがストレージレイヤーからコンピューティングレイヤーに送信されて処理されていることを示しており、これにより、より多くの CPU およびメモリリソースが消費されます。同時に、ストレージレイヤーから読み取られるデータ量の増加により、より多くのディスク I/O リソースも消費されます。

• テーブルから読み取られたデータの最大量と平均量の間に大きな差がある場合、ストレージノードごとに読み取られるデータ量が異なることを示します。このデータ処理負荷の差により、一部のノードがリソースのボトルネックに早期に達し、クラスター全体のパフォーマンスに影響を与える可能性があります。この状況は、多くの場合、最適でないテーブル設計によって引き起こされます。たとえば、一部のテーブルに不均一な分散キーを選択すると、複数のストレージノード間でデータ分散が不均一になります。

書き込み、削除、および更新の応答時間の増加

書き込み応答時間、削除応答時間、および更新応答時間メトリクスは、それぞれ INSERT INTO VALUES、DELETE、および UPDATE 操作の各行を処理するのにかかる時間を示します。応答時間は一般的に次の要因の影響を受けます。

• ストレージノードの高い CPU 使用率

  これは、問題のある SQL や書き込み、削除、または更新 TPS の増加など、他の要因によって引き起こされる可能性があります。

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

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

  • BUILD ジョブ数の増加。

  • システムによるバックアップまたはスケーリング操作の実行。

  これらの操作はすべてディスク書き込みを必要とするため、関連する応答時間に影響を与える可能性があります。

  データ処理中に書き込み応答時間が増加し続ける場合、大規模なデータ処理ジョブをオフピーク時間にスケジュールし、同時書き込みジョブ数を制限してディスク I/O 負荷を軽減することを推奨します。