Amazon EC2 Linux インスタンスの CPU 使用率が高い場合のトラブルシューティング方法を教えてください。

簡単な説明

アプリケーションレベルのアクティビティ、EC2 インスタンスのプロビジョニング不足、モニターのミスマッチなどの要因で、CPU 使用率が上昇する場合があります。CPU 使用率の上昇をトラブルシューティングするには、環境のスティール時間に関するメトリクスを確認します。CPU スティール時間は、インスタンスの準備はできているものの、基盤となる物理リソースが別の場所に割り当てられていることが原因で、インスタンスが処理を続行できない時間を指します。スティール時間の上昇は、アプリケーションのパフォーマンスに影響します。速度低下やタイムアウトが発生したり、動作の一貫性が失われたりする原因となります。

スティール時間が長くなる理由は次のとおりです。

• 基盤となる同じ物理ホスト上の隣接インスタンスで、CPU の需要が高くなっている。
• インスタンスのハイパーバイザーがリクエストで過負荷になっている。
• バースト可能なインスタンスの CPU クレジット残高がなくなった。

注: Amazon CloudWatch メトリクスとインスタンスレベルツールのメトリクスには違いがある可能性があります。CloudWatch がハイパーバイザーレベルでメトリクスを収集するのに対し、インスタンスツールはゲストオペレーティングシステム (OS) 内から測定するため、この相違が発生します。また、CloudWatch は 1～5 分間隔でサンプリングを行うのに対し、インスタンスツールは 1 秒あたりのデータを提供します。時刻同期と CPU 使用率の計算方法も、相違の原因となる可能性があります。

解決策

Linux インスタンスの CPU 使用率上昇をトラブルシューティングするには、次のトラブルシューティング手順を実行します。

設定の CPU スティール時間を測定する

設定のスティール時間を確認するには、次のコマンドを実行します。

top

出力例:

top - 14:23:45 up 7 days, 2:03, 1 user, load average: 0.45, 0.50, 0.45
Tasks: 105 total, 1 running, 104 sleeping, 0 stopped, 0 zombie
%Cpu(s): 5.3 us, 2.1 sy, 0.0 ni, 85.6 id, 1.2 wa, 0.0 hi, 0.3 si, 5.5 st
MiB Mem : 3949.2 total, 146.7 free, 1367.8 used, 2434.7 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 2312.8 avail Mem

出力の st 値を参照し、CPU スティール時間のパーセンテージを取得します。上記の例では、スティール時間は全 CPU 時間の 5.5% を占めています。スティール時間は、5% 未満に抑えることをおすすめします。スティール時間が常に 10% を超えている場合は、インスタンスに設定ミスの問題がないか確認してください。

専用リソースを必要とするワークロードには、Amazon EC2 専有ホストを使用するのがベストプラクティスです。

CloudWatch を使用して CPU を監視する

CloudWatch を使用してインスタンスのパフォーマンスを監視します。インスタンスの CPUUtilization メトリクスと、t2 インスタンスと t3 インスタンスの CPUCreditUsage メトリクスと CPUCreditBalance メトリクスを確認します。

CloudWatch メトリクスと、インスタンスが示す内容に相違がある場合は、CloudWatch エージェントが正しく設定されていることを確認してください。/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log にエラーが表示されていないか確認します。

注: CloudWatch では、デフォルトではスティール時間メトリクスを取得できません。代わりに、CloudWatch エージェントを設定して、カスタムメトリクスを追加する必要があります。

インスタンスレベルのツールを使用してインスタンスを監視する

top コマンドの代わりに htop コマンドを使用すると、設定のスティール時間を見やすいインターフェイスで確認できます。htop のダウンロードについては、GitHub のウェブサイトで「htop-dev/htop」を参照してください。

メモリ、ページング、I/O、CPU などの詳細なシステムレベルのリソース使用状況を時系列で表示するには、次のコマンドを実行します。

vmstat

出力例:

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b  swpd      free buff cache  si so bi bo in cs us sy id wa st
0 0    0    150272 97545 2394124   0  0  0  5  1  2 5 2 86  1 6
0 0    0    150272 97545 2394124   0  0  0  0 435 625 4 2  88 0 6

注: スティール時間を確認するには、st 列を参照します。

リソースに関する過去データを確認するには、次のコマンドを実行します。

sar

出力例:

 $ sar -P ALL 1 3
Linux 5.4.0-1045-aws (ip-10-0-1-100) 04/22/2025 _x86_64_ (2 CPU)
4:25:00 CPU %user %nice %system %iowait %steal %idle
14:25:01 all 4.50 0.00 2.00 1.00 5.50 87.00
14:25:01 0 4.00 0.00 2.00 1.00 6.00 87.00
14:25:01 1 5.00 0.00 2.00 1.00 5.00 87.00

注: sar で設定を行うと、CPU メトリクスを定期的に収集できます。詳細については、Red Hat のウェブサイトで「The sar command」(sar コマンド) を参照してください。

バースト可能なインスタンスタイプの残高を確認する

スティール時間の問題が発生しやすいインスタンスタイプは、複数存在します。例えば、CPU 使用率が高い状態が続くと、CPU クレジットが枯渇し、t2 や t3 などのバースト可能なインスタンスタイプのパフォーマンスが低下する可能性があります。

バースト可能なインスタンスタイプのクレジット残高が常に低いか 0 の場合は、インスタンスタイプをより大きなサイズに変更してください。インスタンスタイプを m、c、r シリーズなどのバースト不可能なインスタンスに変更します。

インスタンスまたはアプリケーションの構成を最適化する

特定のプロセスが CPU を大量に使用している場合は、次の手順を実行してください。

• CPU 使用率の上昇は想定された動作であるかどうかを調査します。
• アプリケーションログにエラーや予期しない動作がないか確認します。
• アプリケーションまたはサービスを再起動します。

CPU 使用率が想定どおりの動作であるものの、高すぎる場合は、アプリケーションを調整し、効率性を改善してください。例えば、ワークロードの計算量が多い場合は、別のインスタンスまたはコンテナに移動することをおすすめします。

トラフィックと負荷パターンを管理する

トラフィックまたは負荷パターンが原因で CPU 使用率が高くなる問題が繰り返し発生する場合は、次の手順を実行してください。

• Amazon EC2 Auto Scaling グループを設定し、スケーリングを自動的に管理します。
• Elastic Load Balancing (ELB) を使用してトラフィックを分散します。
• コンテナとサーバーレスアプリケーションを使用してワークロードを小規模サービスに分割します。

関連情報

リソースの過剰使用が原因で、EC2 Linux インスタンスがステータスチェックに合格できない場合のトラブルシューティング方法を教えてください