Amazon RDS for MySQL または Amazon Aurora MySQL 互換 DB インスタンスの CPU 使用率が増加している場合のトラブルシューティングと解決方法を教えてください。

簡単な説明

CPU 使用率が増加する原因は、複数存在します。原因には、ユーザーが開始したワークロードによる高負荷、複数の同時クエリ実行、長時間実行トランザクションなどが含まれます。

DB インスタンスにおける CPU 消費の原因を特定する方法について、次のリソースを確認してください。

• 拡張モニタリング
• Performance Insights
• ワークロードの CPU 使用率の原因を検出するクエリ
• 監視が有効になっているログ

原因を特定したら、ワークロードを分析して最適化し、CPU 使用率を低減させます。

解決策

拡張モニタリングを使用する

拡張モニタリングでは、高い CPU 付加の原因を特定するためのオペレーティングシステム (OS) レベルのビューが用意されています。たとえば、負荷平均、OS プロセスリスト、CPU 配分 (System (%) または Nice (%))を確認できます。

拡張モニタリングを使用すると、1、5、および 15 分間隔で loadAverageMinute データを確認できます。負荷平均が vCPU の数よりも大きい場合は、インスタンスが高負荷の状態であることを示しています。負荷平均が DB インスタンスクラスの vCPU 数を下回る場合、CPU のスロットリングはアプリケーション遅延の原因ではない可能性があります。CPU 消費の原因を診断する際に誤検出を避けるには、負荷平均を確認します。

例として、DB インスタンスでは db.m5.2xlarge インスタンスクラスを使用しており、CPU 制限に達している場合を示します。そのインスタンスクラスには 8 つの vCPU が関連付けられています。負荷平均が 170 を超えている場合、測定された期間にマシンに過負荷がかかっていることを示しています。

負荷平均 (分):

• 15: 170.25
• 5: 391.31
• 1: 596.74

CPU 使用率:

• ユーザー (%): 0.71
• システム (%): 4.9
• Nice (%): 93.92
• 合計 (%): 99.97

注: Amazon RDS では、DB インスタンスで実行されている他のタスクよりもワークロードの優先度が高くなります。管理に関連するタスクを優先する目的で、ワークロードタスクの Nice には異なる値が付与されます。そのため、拡張モニタリングでは、Nice% はデータベースに対してワークロードが使用している CPU の量を示しています。

拡張モニタリングを有効にした後、DB インスタンスに関連付けられている OS プロセスリストを確認します。拡張モニタリングには、最大 100 のプロセスが表示されます。このリストを参照すると、CPU とメモリのパフォーマンスへの影響が最大のプロセスを特定できます。

拡張モニタリングの [OS プロセスリスト] セクションで [OS プロセス] と [RDS プロセス] を確認します。これらのメトリクスを参照すると、OS プロセスまたは RDS プロセスが CPU 使用率を増加させているかどうかを確認できます。これらのメトリクスを参照し、mysqld または aurora プロセスが使用する CPU の割合を監視することもできます。Aurora Storage Daemon が Aurora インスタンスの CPU を多く消費している場合、インスタンスで高負荷の読み取り/書き込みワークロードが発生しています。また、この CPU 消費量増加は、現在のストレージボリュームとワークロードに対し、インスタンスのサイズが不足していることを示している可能性があります。または、バックグラウンドで複雑な操作が行われている可能性があります。

CPU 使用率の内訳を確認するには、CPUUtilization のメトリクスを確認します。詳細については、「拡張モニタリングで OS メトリクスを監視する」を参照してください。

注: Performance Schema が有効な場合、OS のスレッド ID は RDS MySQL DB インスタンスのプロセス ID にのみマッピングできます。OS のスレッド ID を Aurora MySQL DB インスタンスのプロセス ID にマッピングすることはできません。詳細については、「メモリが十分であるにもかかわらず、Amazon RDS DB がスワップメモリを使用する原因を教えてください」を参照してください。

Database Insights を使用する

重要: 2025 年 11 月 30 日に Performance Insights のサポートは終了します。2025 年 11 月 30 日までに、Database Insights の Advanced モードにアップグレードしてください。アップグレードしない場合、Performance Insights を使用する DB クラスターは、デフォルトで Database Insights の Standard モードを使用します。実行計画とオンデマンド分析は、Database Insights の Advanced モードでのみサポートされます。クラスターがデフォルト設定により Standard モードになった場合、コンソールでこれらの機能を使用できない可能性があります。Advanced モードの有効化方法については、「Amazon RDS で Database Insights の Advanced モードを有効にする」を参照してください。また、必要に応じて「Amazon Aurora Database Insights の Advanced モードを有効にする」を参照してください。

Database Insights を使用すると、DB インスタンスで実行中の CPU 使用率が高いクエリを特定できます。

まず、MySQL インスタンスで Database Insights を有効にします。次に、Database Insights でワークロードを最適化します。必要に応じてデータベース管理者と連携し、問題の根本原因を特定します。

エンジン、AWS リージョン、インスタンスクラスのサポートについては、「Database Insights における Aurora DB エンジン、リージョン、インスタンスクラスのサポート」を参照してください。また、必要に応じて「Database Insights における Amazon RDS DB エンジン、リージョン、インスタンスクラスのサポート」を参照してください。

クエリを使用してワークロードでの CPU 消費の原因を検出する

ワークロードを最適化する前に、問題のあるクエリを特定する必要があります。CPU 使用率の根本原因を特定するには、CPU 使用率増加の問題が発生した際に、次のクエリを実行します。

MySQL インスタンスで実行されているスレッドを確認するには、SHOW FULL PROCESSLIST コマンドを実行します。

SHOW FULL PROCESSLIST;

注: SHOW PROCESSLIST クエリは、プライマリシステムユーザーとして実行します。MySQL インスタンスで実行されるすべてのスレッドを確認するには、MySQL PROCESS サーバー管理権限が必要です。管理者アクセス許可がない場合、SHOW PROCESSLIST では使用している MySQL アカウントに関連付けられているスレッドのみが表示されます。

同じステートメントのセットが完了せずに、実行を続ける場合もあります。この場合、後続のステートメントは最初のステートメントのセットが終了するまで待つ必要があります。InnoDB の行レベルロックにより、同じ行が更新される可能性があります。詳細については、MySQL のウェブサイトで「SHOW PROCESSLIST ステートメント」を参照してください。

INNODB_TRX テーブルからは、読み取り専用トランザクションではない、実行中のすべての InnoDB トランザクションに関する情報を取得できます。INNODB_TRX テーブルを表示するには、次のクエリを実行します。

SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;

INNODB_LOCKS テーブルからは、InnoDB トランザクションが要求したものの、取得しなかったロックに関する情報を取得できます。INNODB_LOCKS テーブルを表示するには、次のクエリを実行します。

MySQL 5.7 以前:

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;

MySQL 8.0:

SELECT * FROM performance_schema.data_locks;

詳細については、MySQL のウェブサイトで MySQL 5.7 用のセクション「INFORMATION_SCHEMA.INNODB_LOCKS テーブル」および MySQL 8.0 用のセクション 「data_locks テーブル」を参照してください。

INNODB_LOCK_WAITS テーブルには、ブロックされた各 InnoDB トランザクションに関する 1 行以上の情報が表示されます。INNODB_LOCKS_WAITS テーブルを表示するには、次のクエリを実行します。

MySQL 5.7 以前:

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;

MySQL 8.0:

SELECT * FROM performance_schema.data_lock_waits;

待機中のトランザクションおよび、待機中トランザクションをブロックするトランザクションを確認するには、次の例を参考にクエリを実行します。

MySQL 5.7 以前:

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;

MySQL 8.0:

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       performance_schema.data_lock_waits w  
INNER JOIN information_schema.innodb_trx b  
  ON b.trx_id = w.blocking_engine_transaction_id  
INNER JOIN information_schema.innodb_trx r  
  ON r.trx_id = w.requesting_engine_transaction_id;

このクエリの出力を解釈する方法については、MySQL のウェブサイトで My SQL 8.0 用のセクション「InnoDB トランザクションとロックに関する情報の活用」を参照してください。

InnoDB ストレージエンジンの状態に関する情報を標準の InnoDB モニターから取得するには、次のクエリを実行します。

SHOW ENGINE INNODB STATUS;

詳細については、MySQL のウェブサイトで MySQL 8.0 用のセクション「SHOW ENGINE ステートメント」を参照してください。

サーバーの状態を確認するには、次のコマンドを実行します。

SHOW GLOBAL STATUS;

詳細については、MySQL のウェブサイトで MySQL 8.0 用のセクション「SHOW STATUS ステートメント」を参照してください。

履歴リストの長さ (HLL) を確認するには、次のコマンドを実行します。

select NAME AS RollbackSegmentHistoryListLength, COUNT from INFORMATION_SCHEMA.INNODB_METRICS where NAME = 'trx_rseg_history_len';

ワークロードで複数のオープントランザクションまたは長時間実行トランザクションが必要な場合は、データベースの HLL が高くなる可能性があります。また、パージスレッドが DB の変更速度に対応できない場合も HLL が高くなる可能性があります。HLL の増加は、リソース消費の増加および、SELECT ステートメントのパフォーマンス低下や不安定化につながります。

Aurora MySQL 書き込みインスタンスでは、CloudWatch メトリクス RollbackSegmentHistoryListLength を参考に HLL を監視します。

インスタンスの HLL が高くなっている場合は、SQL ステートメントをレビューします。この問題は、START TRANSACTION を適用したものの、COMMIT が実行されない場合に発生します。スレッドが SLEEP 状態に移行したため、前回の SQL ステートメントは表示されません。

この問題を解決するには、次のコマンドを実行します。

SELECT event_id, current_schema, sql_text, lock_time
 FROM performance_schema.events_statements_history
 WHERE thread_id=<thread_id>  
 ORDER BY event_id DESC;

ログを分析して監視を有効にする

MySQL 一般クエリログを分析し、特定の時間に mysqld が実行する内容を確認します。クライアントの接続または切断タイミングに関する情報など、特定の時間にインスタンスで実行されるクエリを確認することもできます。詳細については、MySQL のウェブサイトで「一般クエリログ」を参照してください。

重要: 一般クエリログを長期間アクティブにすると、ログがストレージを消費し、パフォーマンスのオーバーヘッドが増える可能性があります。

MySQL スロークエリログを分析し、long_query_time に設定した秒数よりも長時間実行されるクエリを特定します。ワークロードをレビューしてクエリを分析し、パフォーマンスとメモリ消費量を改善することもできます。詳細については、MySQL のウェブサイトで「7.4.5 スロークエリログ」を参照してください。

注: スロークエリログまたは一般クエリログを参照する際、パラメータ log_output を FILE に設定することをおすすめします。

MariaDB Audit Plugin を使用すると、Amazon RDS for MySQL または Amazon RDS for MariaDB でのデータベースアクティビティを監査できます。たとえば、データベースにログインしたユーザーや、データベースに対して実行されたクエリを追跡することができます。

Aurora MySQL 互換のユーザーは、Advanced Auditing を使用できます。Advanced Auditing では、ログに記録するクエリの種類を詳細に制御できるため、ログ記録のオーバーヘッドを削減できます。

innodb_print_all_deadlocks パラメータを使用し、デッドロックやリソースロックが発生していないかを確認します。このパラメータを使用して、InnoDB ユーザートランザクションのデッドロックに関する情報を MySQL エラーログに記録できます。詳細については、MySQL のウェブサイトで innodb_print_all_deadlocks を参照してください。

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

CPU 使用率を増加させているクエリを特定した後、ワークロードを最適化して CPU 消費を削減します。

ワークロードに必要のないクエリが見つかった場合は、次のコマンドを実行して接続を終了させます。

CALL mysql.rds_kill(processID);

重要: インスタンスへのデータ操作言語 (DML) 書き込みを終了すると、中断されたトランザクションがロールバックされます。更新のロールバックには、長時間かかる場合があります。クエリの実行時間が長い場合は、データベース管理者に協力を依頼し、そのクエリを停止できるかどうかを確認してください。

クエリのプロセス ID を確認するには、SHOW FULL PROCESSLIST コマンドを実行します。

クエリを終了させたくない場合は、EXPLAIN でクエリを最適化します。EXPLAIN では、クエリの実行時に含まれる個々のステップが表示されます。詳細については、MySQL のウェブサイトで「EXPLAIN でクエリを最適化する」を参照してください。

プロファイルの詳細を確認するには、プロファイリングを有効にします。SHOW PROFILE コマンドは、現在のセッションで実行されているステートメントのリソース使用状況を表示します。詳細については、MySQL のウェブサイトで「SHOW PROFILE ステートメント」を参照してください。

テーブルの統計情報を確認し、最適化するには、ANALYZE TABLE クエリを使用します。詳細については、MySQL のウェブサイトで 「ANALYZE TABLE ステートメント」を参照してください。

関連情報

待機イベントにより Aurora MySQL をチューニングする

Amazon RDS for MySQL DB インスタンスのログを有効にして監視する方法を教えてください

現実のシナリオにおける Amazon CloudWatch Database Insights の適用