:PolarDB for MySQL クラスタの高い CPU 使用率

高い CPU 使用率への対策

CPU 使用率の予期せぬ増加

CPU 使用率の予期せぬ増加には、多くの原因が考えられます。このトピックでは、スロークエリ、多数のアクティブスレッド、不適切なカーネル構成、およびシステムバグに焦点を当てます。

• スロークエリ

  CPU 使用率の増加は、一般的に、不適切な SQL 文が原因で発生し、スロークエリとアクティブスレッドの急増を引き起こします。ただし、高い CPU 使用率がスロークエリの結果であるのか、他のリソースの不足がスロークエリと高い CPU 使用率を引き起こしているのかを区別する必要があります。

  PolarDBコンソールの [スロー SQL クエリ] ページで、スロークエリに関する情報を表示します。詳細については、「スロー SQL クエリ」をご参照ください。

  スロークエリデータが表示されている場合は、スロークエリを分析できます。[スローログの詳細] タブの [スキャンされた行] 列の値が [返された行] 列の値よりもはるかに大きい場合、高い CPU 使用率はスロークエリが原因です。

  説明

  主に TP クエリを分析し、count クエリを除外する必要があります。一部の AP クエリでは、[スキャンされた行] 列の値が大きくなります。

  TP クエリでは少量のデータのみが読み書きされます。クエリが大量のデータをスキャンする場合、インデックスが作成されていない可能性が非常に高くなります。たとえば、次のクエリ文を実行した後にスキャンされた行数が 10,000 を超え、返された行数が 1 である場合、name 列のインデックスがありません。

  SELECT * FROM table1 WHERE name='testname';

  次の文を実行して、name 列にインデックスが作成されているかどうかを確認できます。

  SHOW index FROM table1;

  • name 列にインデックスがない場合は、次の文を実行してインデックスキー列を追加し、データスキャンの増加によって引き起こされるスロークエリを解消できます。

    ALTER TABLE table1 ADD KEY ix_name (name);

  • name 列にインデックスがある場合は、次の文を実行して SQL 文の実行計画を表示し、インデックスが使用されているかどうかを確認できます。

    EXPLAIN SELECT * FROM table1 WHERE name='testname';

    name 列にインデックスがあるにもかかわらずインデックスが使用されていない場合、考えられる原因は、統計が不正確なために誤った実行計画が生成されていることです。次の文を実行して、テーブルの統計を再生成し、実行計画を修正できます。次の文を実行して、テーブルの統計を再生成し、実行計画を修正できます。

    ANALYZE TABLE table1;

    上記の文を実行した後、次の文を実行して、正しいインデックスが使用されているかどうかを確認します。

    EXPLAIN SELECT * FROM table1 WHERE name='testname';

• 多数のアクティブスレッド

  多数のアクティブスレッドは、確実に高い CPU 使用率につながります。MySQL の実装では、各 CPU は一度に 1 つのリクエストしか処理できません。たとえば、16 コア仕様のクラスターは、一度に最大 16 リクエストを処理できます。ここでいうリクエストはカーネルレベルであり、アプリケーションの同時実行性ではないことに注意してください。[診断と最適化] > [クイック診断] > [セッション管理] ページでセッションの詳細を表示するには、PolarDBコンソール を使用します。

  スロークエリによって引き起こされる例外的なリクエストを除くと、アクティブスレッドはネットワークトラフィックの増加に伴って急増します。全体的なトラフィックとリクエストのトレンドがアクティブスレッドの累積トレンドと一致する場合は、すべてのクラスタリソースが使用されています。この場合、クラスタに読み取り専用ノードを追加するか、クラスタをスケールアップする必要があります。

  アクティブスレッドがクリティカルレベルに達すると、CPU 競合が発生します。カーネルに多数のミューテックスロックが生成されます。この場合、パフォーマンス曲線の特性は、高い CPU 使用率、高いアクティブスレッド、低い I/O または低い QPS です。ビジネストラフも発生する可能性があります。接続は非常に高速で確立されます。CPU 競合により、リクエストが累積されます。 thread_pool 機能をクラスタで有効にすることで、この問題を軽減できます。詳細については、「スレッドプール」をご参照ください。アクティブスレッド数が減少した場合は、アプリケーション側でリクエストが累積しているかどうかを確認してください。高い CPU 負荷とアクティブスレッドの急増が同時に発生する場合は、クラスタをスケールアップするかどうかを検討する必要があります。

  フロントエンドでの接続ストームが原因でクラスタ側でリクエストが突然累積する場合は、異常なトラフィックが発生します。これは一般的にデータクローリングに由来します。この場合、SQL 速度制限を有効にしてリクエストを拒否できます。詳細については、「セッション管理」をご参照ください。

• 不適切なカーネル構成

  PolarDB パラメータのデフォルト値は、一般的なシナリオ向けです。特別なビジネスには適さない場合があります。PolarDB パラメータの値を変更できます。データ量が少量の場合、初期段階では一部の問題が発生しない場合がありますが、データ量の増加に伴い発生します。

  一般的な問題はメモリ競合です。MySQL では、メモリは主にデータキャッシュに使用されます。メモリ内のデータは継続的に反復されます。通常、buffer pool と innodb_adaptive_hash_index がメモリを消費します。データベースシステム全体で、キャッシュエリアは最も頻繁なデータ交換を処理します。メモリ不足とメモリページの競合により、データの累積とスロークエリが発生する可能性があります。典型的な症状は、CPU が枯渇し、スロークエリが発生することです。この問題がインデックスの欠落によって引き起こされていない場合は、メモリ競合が原因です。

  たとえば、truncate table 文を実行すると、MySQL は buffer pool をスキャンして、切り捨てる テーブルのすべてのデータページをエビクトします。高仕様のクラスタで、innodb_buffer_pool_instances パラメータが 1 に設定されており、同時実行性が比較的高い場合、競合が発生する可能性があります。この問題は初期段階で見つかる場合があります。解決策には、innodb_buffer_pool_instances パラメータを CPU コア数に設定し、buffer pool をバケットに分割することが含まれます。

  別のシナリオは、innodb_adaptive_hash_index のメモリ競合です。症状は、次の文を実行するときに多数の hash0hash.cc 待機が発生することです。

  SHOW ENGINE innodb STATUS;

  AHI フィールドでは、明らかなデータスキューが発生します。

  この問題については、innodb_adaptive_hash_index パラメータを off に設定して AHI 機能を無効にすることができます。AHI 機能は、読み取りと書き込みのシナリオでパフォーマンスを低下させる可能性もあります。AHI 機能を無効にしても、ビジネス全体への影響はほとんどありません。

• システムバグ

  システムバグは非常にまれです。たとえば、プロセスのデッドロックや、テーブル統計のリセットによって引き起こされる全表スキャンにより、CPU 使用率が高くなる可能性があります。サービスの迅速な反復により、システムバグが原因の CPU 問題はますます少なくなっています。カーネル情報が関係しているため、問題のトラブルシューティングが困難な場合があります。 チケットを起票して、Alibaba Cloud テクニカルサポートに連絡してトラブルシューティングを行うことをお勧めします。