Amazon RDS for MySQL、MariaDB、または MySQL 用 Aurora インスタンスでの高い CPU 使用率をトラブルシューティングおよび解決する方法を教えてください。

問題

MySQL 用の Amazon Relational Database Service (Amazon RDS)、MariaDB、または MySQL 用 Amazon Aurora インスタンスで CPU 使用率が高くなっています。高い CPU 使用率をトラブルシューティングおよび解決する方法を教えてください。

簡単な説明

CPU 使用率の上昇が起こる要因はいくつかあります。たとえば、ユーザーによる大量のワークロード、分析クエリ、長時間のデッドロックとロック待機、複数の同時トランザクション、長期実行トランザクション、または他プロセスによるCPU リソースの使用などです。

まず、CPU 使用率上昇の原因を特定します。

拡張モニタリングの使用
Performance Insights の使用
クエリを使用して、ワークロードでの CPU 使用率上昇の原因を検出する
ログの分析と、モニタリングの有効化

送信元を特定したら、ワークロードを分析、および最適化し、CPU 使用率を低減します。

解決方法

拡張モニタリングの使用

拡張モニタリングは、毎分ごとに統計情報を提供する Amazon CloudWatch メトリクスに加えて、確認が可能な詳細なリアルタイムメトリクスを提供します。詳細については、「CloudWatch と拡張モニタリングのメトリクスの相違点」をご参照ください。

拡張モニタリングのオペレーティングシステム (OS) プロセスリストセクションで、OS でのプロセスと RDS でのプロセスを調べ、mysqld または Aurora でのプロセスの CPU 使用率を確認します。これらのメトリクスは、CPU 使用率の増加が OS または RDS でのプロセスに起因するかどうかを確認するのに役立ちます。これらのメトリクスを使用して、mysqld または Aurora が使用率増加を引き起こしているかどうかを確認することもできます。これがあてはまる場合、ユーザーが開始したワークロードが CPU 使用率上昇の原因であることを示しています。詳細については、「拡張モニタリング」をご参照ください。cpuUtilization のメトリクスを確認することで、CPU 使用率の分岐も調べることができます。詳細については、「使用可能な OS メトリクス」をご参照ください。

使用されていないタスク (スリーブ中のタスク) の数を確認することもできます。これらのタスクは、メモリリソース (RAM、キャッシュ、およびプロセッサ) の消費量の増加につながり、サーバーの速度を低下させる可能性があります。使用していない接続を適切に閉じるよう、アプリケーションを調整することをお勧めします。wait_timeout および interactive_timeout パラメータの値を変更して、設定した値に基づいた接続を閉じることもできます。詳細については、「wait_timeoutの MySQL のドキュメント」および「interactive_timeout の MySQL のドキュメント」をご参照ください。

Performance Insights の使用

Performance Insights を使用すれば、CPU 使用率が高い原因となっているインスタンス上で実行中のクエリを正しく識別できます。まず、MySQL 用 Performance Insights を有効にします。次に、Performance Insights を使用して、DBA と相談した後、ワークロードを最適化します。

Performance Insights で使用できるデータベースエンジンを確認するには、「Amazon RDS Performance Insights の使用」をご参照ください。

クエリを使用して、ワークロードでの CPU 使用率上昇の原因を検出する

ワークロードを最適化する前に、問題のあるクエリを特定する必要があります。CPU 使用率が高くなる問題が発生しているとき、次のクエリを実行すると、CPU 使用率の根本的な原因を特定できます。次に、ワークロードを最適化して、CPU 使用率を低減します。

SHOW PROCESSLIST コマンドは、どのスレッドが MySQL インスタンスで現在実行中であるかを表示します。同じステートメントのセットが実行中で、完了していないことがたまにあります。このような状況が発生した場合、後続のステートメントは、最初のステートメントのセットが終了するのを待つ必要があります。InnoDB の行レベルのロックが、同じ行を更新している可能性があるためです。詳細については、「SHOW PROCESSLIST 構文の MSQL ドキュメント」をご参照ください。

SHOW FULL PROCESSLIST;

注: SHOW PROCESSLIST クエリをマスターユーザーとして実行します。マスターユーザーでない場合、このコマンドを実行する MySQL ユーザーは、MySQL インスタンスで実行中のすべてのスレッドを表示するには、MySQL PROCESSサーバー管理権限を持っている必要があります。管理権限がない場合、SHOW PROCESSLIST は、お使いの MySQL アカウントに関連付けられているスレッドのみを表示します。

INNODB_TRX テーブルは、読み取り専用トランザクションではない、現在実行中のすべての InnoDB トランザクションに関する情報を提供します。詳細については、「INFORMATION_SCHEMA INNODB_TRX テーブルの MySQL ドキュメント」をご参照ください。

SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;

INNODB_LOCKS テーブルは、InnoDB トランザクションがリクエストしたが受信していないロックについての情報を提供します。詳細については、「INFORMATION_SCHEMA INNODB_LOCKS テーブルの MySQL ドキュメント」をご参照ください。

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;

INNODB_LOCK_WAITS テーブルは、ブロックされた InnoDB トランザクションごとに 1 つまたは複数の行を提供します。詳細については、「INFORMATION_SCHEMA INNODB_LOCK_WAITS テーブルの MySQL ドキュメント」をご参照ください。

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;

以下のようなクエリを実行して、どのトランザクションが待機中で、どのトランザクションが待機中のトランザクションをブロックしているかを確認できます。詳細については、「InnoDB のトランザクションモデルおよびロックの MySQL ドキュメント」をご参照ください。

SELECT
  r.trx_id waiting_trx_id,
  r.trx_mysql_thread_id waiting_thread,
  r.trx_query waiting_query,
  b.trx_id blocking_trx_id,
  b.trx_mysql_thread_id blocking_thread,
  b.trx_query blocking_query
FROM       information_schema.innodb_lock_waits w
INNER JOIN information_schema.innodb_trx b
  ON b.trx_id = w.blocking_trx_id
INNER JOIN information_schema.innodb_trx r
  ON r.trx_id = w.requesting_trx_id;

SHOW ENGINE INNODB STATUS クエリは、InnoDB 標準モニターから InnoDB ストレージエンジンの状態に関する情報を提供します。詳細については、「SHOW ENGINE 構文のの MySQL ドキュメント」をご参照ください。

SHOW ENGINE INNODB STATUS;

SHOW GLOBAL SESSION STATUS は、サーバーのステータスに関する情報を提供します。詳細については、「SHOW STATUS 構文の MySQL ドキュメント」をご参照ください。

SHOW GLOBAL STATUS;

注: このようなクエリは、Aurora 2.02.5 (MySQL 5.7)、Aurora 1.17.8 (MySQL 5.6)、MySQL 5.6.x および 5.7.x、および MariaDB 10.0.x、10.1.x、10.2.x でテストされています。

ログの分析と、モニタリングの有効化

MySQL 一般クエリログを分析して、mysqld が特定の時間に何を行っているかを確認できます。クライアントがいつ接続または切断したかに関する情報を含む、特定の時間にインスタンスで実行されているクエリも表示できます。詳細については、「一般クエリーログの MySQL ドキュメント」をご参照ください。

注: 一般クエリログを長期間有効にすると、ログがストレージを消費し、パフォーマンスのオーバーヘッドを増加させる可能性があります。

MySQL スロークエリログを分析して、long_query_time に設定された秒数よりも実行時間が長いクエリを見つけます。ワークロードを確認し、クエリを分析して、パフォーマンスとメモリ消費を改善することも可能です。詳細については、「スロークエリーログの MySQL ドキュメント」をご参照ください。

ヒント: スロークエリーログまたは一般クエリログを使用するとき、パラメータ log_output を FILE に設定します。

MariaDB 監査プラグインを使用すると、データベースにログオンしているユーザーやデータベースに対して実行されたクエリなどのデータベースアクティビティを監査することもできます。詳細については、「MariaDB 監査プラグインのサポート」をご参照ください。

MySQL 用 Aurora を使用する場合、Advanced Auditing も使用できます。Auditing を使用すると、ログに記録するクエリの種類をより細かく制御でき、ログ記録のオーバーヘッドを減らすことができます。

innodb_print_all_deadlocks パラメータを使用すると、デッドロックおよびリソースのロックを確認できます。。このパラメータを使用して、InnoDB ユーザートランザクションのデッドロックに関する情報を、MySQL エラーログに記録できます。詳細については、「innodb_print_all_deadlocks の MySQL ドキュメント」をご参照ください。

高い CPU 使用率のワークロードの分析と最適化

CPU 使用率を増加させているクエリを特定したら、ワークロードを最適化して、CPU の消費量を減らすことができます。

ワークロードに不要なクエリが表示された場合、以下のコマンドを使用して、接続を終了 (クエリを強制終了) できます。

CALL mysql.rds_kill(processID);

SHOW FULL PROCESSLIST コマンドを実行することで、クエリの processID を検索できます。

クエリを強制停止しない場合は、 EXPLAIN を使用してクエリを最適化することができます。これは、クエリ実行に関連した個々のステップを示しています。詳細については、「EXPLAIN によるクエリーの最適化の MySQL ドキュメント」をご参照ください。

PROFILING を有効化することで、現在のセッション中に実行されるステートメントのリソース使用量を表示するプロファイルの詳細を確認できます。詳細については、「PROFILING 構文の MySQL ドキュメント」をご参照ください。

ANALYZE TABLE を使用すると、テーブルの索引統計を更新します。これは、オプティマイザが適切な実行計画を選択するのに役立ちます。詳細については、「ANALYZE TABLE 構文の MySQL ドキュメント」をご参照ください。

Amazon RDS for MySQL、MariaDB、または MySQL 用 Aurora インスタンスでの高い CPU 使用率をトラブルシューティングおよび解決する方法を教えてください。

問題

簡単な説明

解決方法

関連情報