Amazon RDS for MySQL または Amazon Aurora MySQL 互換 DB インスタンスの CPU 使用率が高い場合のトラブルシューティングと解決方法を教えてください。
Amazon Relational Database Service (Amazon RDS) for MySQL DB または Amazon Aurora MYSQL 互換エディションのインスタンスで、CPU 使用率が高くなっています。
簡単な説明
CPU 使用率の増加は、ユーザーが開始する負荷の高いワークロード、複数の同時クエリ、長時間実行されるトランザクションなど、いくつかの要因によって発生で可能性があります。
DB インスタンスの CPU 使用率の原因を特定するには、以下のリソースを確認してください。
- 拡張モニタリング
- Performance Insights
- ワークロードの CPU 使用率の原因を検出するクエリ
- 監視が有効になっているログ
原因を特定したら、ワークロードを分析して最適化し、CPU 使用率を低減させます。
解決策
拡張モニタリングを使用する
拡張モニタリングでは、高い CPU 付加の原因を特定するためのオペレーティングシステム (OS) レベルのビューが用意されています。たとえば、負荷平均、OS プロセスリスト、CPU 配分 (System (%) または Nice (%))を確認できます。
拡張モニタリングを使用すると、1、5、および 15 分間隔で loadAverageMinute データを確認できます。負荷平均が vCPU の数よりも大きい場合は、インスタンスが高負荷の状態であることを示しています。負荷平均が DB インスタンスクラスの vCPU の数より小さい場合、CPU スロットリングがアプリケーション遅延の原因ではない可能性があります。CPU 使用率の原因を診断する際に誤検出を避けるためにも、負荷平均を確認してください。
たとえば、プロビジョンド IOPS が 3000 の db.m5.2xlarge インスタンスクラスを使用する DB インスタンスがあり、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 プロセス] を確認します。mysqld プロセスまたは aurora プロセスの CPU 使用率を確認します。これらのメトリクスは、CPU 使用率の増加が OS によるものか RDS プロセスによるものかを確認するのに役立ちます。または、これらのメトリクスを使用して、mysqld または Aurora が原因で発生した CPU 使用量の増加を監視することもできます。CPU 使用率の内訳を確認するには、CPUUtilization のメトリクスを確認します。詳細については、「拡張モニタリングで OS メトリクスを監視する」を参照してください。
注: Performance Schema が有効な場合、OS スレッド ID をデータベースのプロセス ID にマップできます。詳細については、「十分なメモリがあっても Amazon RDS DB インスタンスがスワップメモリを使用する理由を知りたいです」を参照してください。
Performance Insights を使用する
Performance Insights を使用すると、DB インスタンスで実行されている CPU 使用率が高いクエリを特定できます。まず、MySQL で Performance Insights 有効にします。その後、Performance Insights を使用してワークロードを最適化します。必要に応じて、データベース管理者と協力して問題の根本原因を特定してください。
Performance Insightsで使用できるデータベースエンジンについては、「Performance Insights での Amazon RDS DB エンジン、AWS リージョン、インスタンスクラスのサポート」を参照してください。
クエリを使用してワークロードの CPU 使用率の原因を検出する
ワークロードを最適化する前に、問題のあるクエリを特定する必要があります。CPU 使用率が高くなる問題が発生しているときに、次のクエリを実行すると、CPU 使用率の根本原因を特定できます。
MySQL インスタンスで実行されているスレッドを表示するには、SHOW FULL PROCESSLIST コマンドを実行します。
SHOW FULL PROCESSLIST;
注: SHOW PROCESSLIST クエリは、プライマリシステムユーザーとして実行します。プライマリシステムユーザーではない場合、MySQL インスタンスで実行されているすべてのスレッドを閲覧するには、サーバー管理アクセス許可 MySQL PROCESS が必要です。管理者アクセス許可がない場合、SHOW PROCESSLIST は使用している MySQL アカウントに関連付けられているスレッドのみを表示します。
場合によっては、同じステートメントのセットが完了せずに実行され続けることがあります。この場合、後続のステートメントは最初のステートメントのセットが終了するまで待つ必要があります。これは、InnoDB の行レベルのロックによって同じ行が更新される可能性があるためです。詳細については、MySQL のウェブサイトで「13.7.5.29 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 のウェブサイトで「24.4.14 INFORMATION_SCHEMA.INNODB_LOCKS テーブル」および「10.13.1 The 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 のウェブサイトで「17.15.2.1 InnoDB トランザクションとロック情報を使用する」を参照してください。
InnoDB ストレージエンジンの状態に関する情報を標準の InnoDB モニターから取得するには、次のクエリを実行します。
SHOW ENGINE INNODB STATUS;
詳細については、MySQL のウェブサイトで「13.7.5.15 SHOW ENGINE ステートメント」を参照してください。
サーバーの状態を確認するには、次のコマンドを実行します。
SHOW GLOBAL STATUS;
詳細については、MySQL のウェブサイトで「15.7.7.37 SHOW STATUS ステートメント」を参照してください。
ログを分析して監視を有効にする
MySQL 一般クエリログを分析して、特定の時間に mysqld が行うことを確認します。また、クライアントの接続または切断タイミングに関する情報など、特定の時間にインスタンスで実行されているクエリを確認することもできます。詳細については、MySQL のウェブサイトで「7.4.3 一般クエリログ」を参照してください。
重要: 一般クエリログを長期間アクティブにすると、ログがストレージを消費し、パフォーマンスのオーバーヘッドが増える可能性があります。
MySQL Slow Query ログを分析して、long_query_timeに設定した秒数よりも実行に時間がかかっているクエリを特定します。ワークロードを確認してクエリを分析し、パフォーマンスとメモリ消費量を改善することもできます。詳細については、MySQL のウェブサイトで「7.4.5 スロークエリログ」を参照してください。
注: Slow Query ログまたは一般クエリログを使用する場合、パラメータ log_output は FILE に設定するのがベストプラクティスです。
MariaDB 監査プラグインを使用してデータベースアクティビティを監査します。たとえば、データベースにログインしたユーザーや、データベースに対して実行されたクエリを追跡することができます。
Aurora for MySQL を使用している場合は、Advanced Auditing も使用できます。Advanced Auditing では、ログに記録するクエリの種類をより細かく制御できるため、ログ記録のオーバーヘッドを削減できます。
innodb_print_all_deadlocks パラメータを使用して、デッドロックとリソースロックを確認します。このパラメータを使用して、InnoDB ユーザートランザクションのデッドロックに関する情報を MySQL エラーログに記録できます。詳細については、MySQL のウェブサイトで innodb_print_all_deadlocks を参照してください。
高い CPU ワークロードの分析と最適化
CPU 使用率を増加させているクエリを特定したら、ワークロードを最適化して CPU 使用量を削減します。
ワークロードに必要のないクエリが見つかった場合は、次のコマンドを実行して接続を終了させます。
CALL mysql.rds_kill(processID);
クエリのプロセス ID を確認するには、SHOW FULL PROCESSLIST コマンドを実行します。
クエリを終了させない場合は、EXPLAIN を使用してクエリを最適化します。EXPLAIN には、クエリの実行時に必要な個々のステップが表示されます。詳細については、MySQL のウェブサイトで「10.8.1 EXPLAIN によるクエリの最適化」を参照してください。
プロファイルの詳細を確認するには、プロファイリングを有効にします。SHOW PROFILE コマンドは、現在のセッションで実行されているステートメントのリソース使用状況を表示します。詳細については、MySQL のウェブサイトで「15.7.7.30 SHOW PROFILE ステートメント」を参照してください。
テーブル統計を表示して最適化するには、ANALYZE TABLE クエリを使用します。詳細については、MySQL のウェブサイトで 「15.7.3.1 ANALYZE TABLE ステートメント」を参照してください。
関連情報
関連するコンテンツ
- 質問済み 7年前lg...
- 質問済み 1年前lg...
- AWS公式更新しました 1年前
- AWS公式更新しました 1ヶ月前
- AWS公式更新しました 2年前