cpu
cpu 待機イベントは、スレッドが CPU でアクティブな場合、または CPU を待っている際に発生します。
サポート対象エンジンバージョン
この待機イベント情報は、以下のエンジンバージョンでサポートされています。
-
Aurora MySQL バージョン 2 および 3
Context
すべての vCPU に対して、接続はこの CPU 上で動作を実行できます。状況によっては、実行可能なアクティブな接続の数が vCPUs の数よりも多くなります。この不均衡により、接続が CPU リソースを待機することになります。アクティブな接続の数が vCPUs の数よりも常に多い場合、インスタンスに CPU 競合が発生します。この競合により、cpu 待機イベントが発生します。
注記
CPU の Performance Insights メトリクスは DBLoadCPU です。DBLoadCPU の値は CloudWatch メトリクス CPUUtilization の値とは異なる場合があります。後者のメトリクスは、データベースインスタンスのハイパーバイザーから収集されます。
Performance Insights OS メトリクスは、CPU 使用率に関する詳細情報を提供します。例えば、以下のメトリクスを表示できます。
-
os.cpuUtilization.nice.avg -
os.cpuUtilization.total.avg -
os.cpuUtilization.wait.avg -
os.cpuUtilization.idle.avg
Performance Insights は、データベースエンジンによる CPU 使用率を os.cpuUtilization.nice.avg として報告します。
待ち時間増加の考えられる原因
このイベントが通常よりも多く発生し、パフォーマンス問題を示している可能性がある場合、典型的な原因は次のとおりです。
-
分析クエリ
-
高パラレルトランザクション
-
実行時間が長いトランザクション
-
ログインストームとして知られる、接続数の急激な増加。
-
コンテキスト切り替えの増加
アクション
cpu 待機イベントがデータベースアクティビティを占領している場合でも、必ずしもパフォーマンスの問題を示すわけではありません。パフォーマンスが低下した場合にのみ、このイベントに応答します。
CPU 使用率の増加の原因に応じて、次の戦略を検討してください。
-
ホストの CPU 容量を増やします。このアプローチは通常、テンポラリ救済しか与えません。
-
潜在的な最適化のためのトップクエリを特定します。
-
読み取り専用ワークロードをリーダーノードにリダイレクトします (該当する場合)。
問題の原因となっているセッションまたはクエリを特定します。
セッションとクエリを見つけるには、Performance Insights のトップ SQL の表で、CPU ロードが最も高い SQL ステートメントを探します。詳細については、「Performance Insights ダッシュボードを使用してメトリクスを分析する」を参照してください。
通常、1 つまたは 2 つの SQL ステートメントは CPU サイクルの大半を消費します。これらのステートメントを中心に確認してください。DB インスタンスに 2 つの vCPUs があり、DB ロードが平均 3.1 のアクティブセッション (AAS) がすべて CPU 状態にあるとします。この場合、インスタンスは CPU バインドされています。以下の戦略を検討して下さい。
-
より多くの vCPUs を持つより大きなインスタンスクラスにアップグレードします。
-
クエリを調整して CPU ロードを下げます。
この例では、上位 SQL クエリの DB ロードが 1.5 AAS で、すべて CPU 状態です。別の SQL ステートメントの CPU 状態では 0.1 のロードがあります。この例では、lowest-load SQL 文を停止しても、データベースのロードは大幅に軽減されません。ただし、2 つの高ロードクエリを最適化して 2 倍の効率が得られると、CPU のボトルネックがなくなります。1.5 AAS の CPU ロードを 50% 減らすと、各ステートメントの AAS は 0.75 に減少します。CPU に費やされた DB ロードの合計は 1.6 AAS になりました。この値は、vCPU の最大ラインの 2.0 を下回っています。
Performance Insights を使用したトラブルシューティングの便利な概要については、ブログ記事 Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析
高い CPU ワークロードを分析して最適化する
CPU 使用率を増加させているクエリを特定したら、それらを最適化するか、接続を終了します。次の例は、接続の終了方法を解説しています。
CALL mysql.rds_kill(processID);
詳細については、「mysql.rds_kill」を参照してください。
セッションを終了すると、アクションによって長いロールバックがトリガーされることがあります。
クエリを最適化するためのガイドラインに従う
クエリを最適化するには、次のガイドラインを考慮してください。
-
EXPLAINステートメントを実行します。このコマンドは、クエリの実行に関連する個々のステップを示しています。詳細については、MySQL ドキュメントの「EXPLAIN を使用したクエリの最適化」
を参照してください。 -
SHOW PROFILEステートメントを実行します。このステートメントを使用して、現在のセッション中に実行されるステートメントのリソース使用状況を示すプロファイル詳細を確認します。詳細については、MySQL ドキュメントの SHOW PROFILE ステートメント
を参照してください。 -
ANALYZE TABLEステートメントを実行します。このステートメントを使用して、CPU を大量に消費するクエリによってアクセスされるテーブルのインデックス統計を更新します。ステートメントを分析することで、オプティマイザが適切な実行プランを選択するのに役立ちます。詳細については、MySQL ドキュメントの ANALYZE TABLE ステートメント
を参照してください。
CPU 使用率を改善するためのガイドラインに従ってください
データベースインスタンスの CPU 使用率を向上させるには、次のガイドラインに従ってください。
-
すべてのクエリが適切なインデックスを使用していることを確認します。
-
Aurora パラレルクエリを使用できるかどうかを調べます。このテクニックを使うと、関数処理、行のフィルタリング、および
WHERE句のプロジェクションをプッシュダウンすることにより、ヘッドノードの CPU 使用率を削減することができます。 -
1 秒あたりの SQL 実行数が予想されるしきい値と合っているかを調べます。
-
インデックスのメンテナンスまたは新規インデックスの作成が、本番ワークロードで必要な CPU サイクルにかかるかどうかを調べます。ピークアクティビティ時間外のメンテナンスアクティビティをスケジュールします。
-
パーティショニングを使用してクエリデータセットを削減できるかどうかを調べます。詳細については、ブログの投稿記事 統合ワークロードに向けて Amazon Aurora with MySQL の互換性を計画、最適化する方法
を参照してください。
接続ストームをチェックする
DBLoadCPU メトリクスはそれほど高くはないが CPUUtilization メトリクスが高い場合、CPU 使用率が高い原因はデータベースエンジンの外部にあります。典型的な例はコネクションストームです。
以下の条件に該当するかどうかを確認してください。
-
Performance Insights
CPUUtilizationメトリックスと Amazon CloudWatchDatabaseConnectionsメトリクスの両方で増加が見られる。 -
CPU 内のスレッド数が vCPUs 数を超えいる。
上記の条件に当てはまる場合は、データベース接続数を減らすことを検討してください。例えば、RDS プロキシなどの接続プールを使用できます。効果的な接続管理とスケーリングのベストプラクティスを学ぶには、ホワイトペーパー接続管理のための Amazon Aurora MySQL DBA ハンドブック
