リソースの過剰使用によりステータスチェックに失敗した EC2 Linux インスタンスのトラブルを解決する方法を教えてください。

短い説明

リソースの過剰使用が原因でヘルスチェックが失敗する最も一般的な理由を以下に 3 つ挙げます。

• インスタンスの CPU 使用率が 100% 近くに達し、カーネルを実行するのに十分なコンピューティング性能がインスタンスに残っていませんでした。
• ルートデバイスが 100% いっぱいになっていて、他のプロセスの完了または開始を妨げています。
• インスタンスで実行されているプロセスがメモリをすべて使用したため、カーネルの実行ができませんでした。

決議

インスタンスを停止して起動します

警告:

• インスタンスを停止すると、インスタンスストアボリュームに保存されているデータは失われます。インスタンスを停止する前に、データのバックアップを保存しておいてください。EBS ベースのボリュームと異なり、インスタンスストアボリュームは一時的なもので、データの永続性はサポートされていません。詳細については、「インスタンスを停止するとどうなるか」を参照してください。
• インスタンスに対して停止操作と起動操作を行うと、カーネルは実行中のプロセスを強制的に停止します。これは、リソースをオペレーティングシステムに戻すための一時的な解決策です。問題の根本原因に対処しないと、引き続き過剰使用が発生します。
• Amazon EC2 が起動時または開始時にインスタンスに自動的に割り当てた静的パブリック IPv4 アドレスは、停止および起動後に変更されます。インスタンスが停止しても変わらないパブリック IPv4 アドレスを維持するには、Elastic IP アドレスを使用してください。

詳細については、「インスタンスの停止と起動」を参照してください。

Amazon CloudWatch CPU 使用率メトリクスを確認してください

インスタンスの CloudWatch のメトリクスを表示します。CPU 使用率が 100% またはそれに近い場合は、次のオプションを使用してトラブルシューティングを行います。

• インスタンスを再起動して正常な状態に戻します。
  注: インスタンスの CPU 要件が現在のインスタンスタイプよりも高い場合、再起動後に再び問題が発生します。
• CPU 要件を満たすインスタンスタイプにインスタンスを変更することを検討してください。
• インスタンスがバースト可能パフォーマンスインスタンス (T2、T3、または T3a) の場合は、インスタンスのメトリクスを一覧表示して CPUCreditBalance を確認してください。CloudWatch コンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用してメトリックスを一覧表示できます。
  クレジット残高がゼロに近い場合は、インスタンスの CPU が制限される可能性があります。インスタンスでクレジット仕様が「標準」に設定されている場合は、仕様を「無制限」に変更できます。詳細については、「Modify the credit specification of a burstable performance instance」を参照してください。

注: AWS CLI コマンドを実行する際にエラーが発生する場合は、最新バージョンの AWS CLI を使用していることを確認してください。

インスタンスのシステムログにエラーがないか確認してください

システムログをチェックし、デバイスに空き容量がないか、メモリ不足エラーがないかを確認してください。

デバイスに空き容量が残っていません

インスタンスのシステムログに「OSError: [Error 28] デバイス '/var/lib/' に空き容量が残っていません」のようなエラーが表示される場合は、リストされるフォルダを含むファイルシステムに空き容量がありません。この例では、/var/lib に空き容量がありません。

次のいずれかの方法で、ファイルシステムの空き容量を増やすことができます。

方法 1: Linux 用 EC2 シリアルコンソールを使用します

Linux インスタンス用 EC2 シリアルコンソールを有効にすると、サポートされている Nitro ベースのインスタンスタイプとベアメタルインスタンスのトラブルシューティングに使用できます。シリアルコンソールは、起動の問題、ネットワーク設定、SSH 設定の問題のトラブルシューティングに役立ちます。シリアルコンソールは、ネットワーク接続が機能していなくてもインスタンスに接続されます。Amazon EC2 コンソールまたは AWS CLI を使用してシリアルコンソールにアクセスできます。

EC2 シリアルコンソールをこれまで使用したことがない場合は、接続を試みる前に前提条件を確認し、アクセスを設定してください。インスタンスにアクセスできず、シリアルコンソールへのアクセスを設定していない場合は、「方法 2: レスキューインスタンスを使用する」の手順に従ってください。EC2 シリアルコンソールの設定については、「EC2 シリアルコンソールへのアクセスを設定する」を参照してください。

方法 2: レスキューインスタンスを使用します

警告: 以下の手順では、インスタンスを停止する必要があります。インスタンスを停止すると、インスタンスストアボリュームに保存されているデータは失われます。インスタンスを停止する前に、データのバックアップを保存しておいてください。EBS ベースのボリュームと異なり、インスタンスストアボリュームは一時的なもので、データの永続性はサポートされていません。詳細については、「インスタンスを停止するとどうなるか」を参照してください。

1.    仮想プライベートクラウド (VPC) で新しい EC2 インスタンスを起動します。障害が発生したインスタンスと同じ Amazon マシンイメージ (AMI) と同じアベイラビリティーゾーンを使用します。新しいインスタンスがレスキューインスタンスになります。

または、アクセス可能な既存のインスタンスを使用します。既存のインスタンスは、障害が発生したインスタンスと同じ AMI を使用し、同じアベイラビリティーゾーンにある必要があります。

2.    障害のあるインスタンスを停止します。

3.障害のあるインスタンスから Amazon Elastic Block Store (Amazon EBS) ルートボリューム (/dev/xvda または /dev/sda1) をデタッチします。ルートボリュームのデバイス名 (/dev/xvda または /dev/sda1) を書き留めておきます。

4.    レスキューインスタンスに、セカンダリデバイス (/dev/sdf) として EBS ボリュームをアタッチします。

5.    SSH を使用してレスキューインスタンスに接続します。

6.    レスキューインスタンスにアタッチした新しいボリュームのマウントポイントディレクトリ (/rescue) を作成します。

$ sudo mkdir /rescue

7.    手順 6 で作成したディレクトリにボリュームをマウントします。

$ sudo mount /dev/xvdf1 /rescue

デバイス (/dev/xvdf1) は別のデバイス名でレスキューインスタンスにアタッチされている可能性があります。lsblk コマンドを使用して、使用可能なディスクデバイスとそのマウントポイントを表示し、正しいデバイス名を確認してください。

**注:**次のようなエラーメッセージが表示される場合があります。

「...fs タイプが間違っている、オプションが間違っている、/dev/nvme2n1 のスーパーブロックが間違っている、コードページまたはヘルパープログラムがない、またはその他のエラー。」

上記のエラーは、XFS ファイルシステムとの UUID の競合が原因で発生します。このエラーが表示された場合は、「Amazon EBS ボリュームをマウントできないのはなぜですか?」を参照してください。

8.    du-h コマンドを実行して、どのファイルが最も多くの容量を占めているかを確認してください。

du -shcm /rescue/var/lib/* |sort -n

9.    必要に応じてファイルを削除して空き容量を増やします。

10.    unmount コマンドを実行して、レスキューインスタンスからセカンダリデバイスをアンマウントします。

$ sudo umount /rescue

アンマウント操作が成功しなかった場合、クリーンなアンマウントを行うためにレスキューインスタンスを停止または再起動する必要がある場合があります。

11.    レスキューインスタンスからセカンダリボリューム (/dev/sdf) をデタッチします。その後、それを元のインスタンスに /dev/xvda (ルートボリューム) としてアタッチします。

12.    インスタンスを起動し、インスタンスが応答するかどうかを確認してください。

以下の手順でルート EBS ボリュームのサイズを変更できます。

1.    EBS ボリュームサイズの変更をリクエストします。

2.    レスキューインスタンスを使用してボリュームのサイズを変更したら、Linux ファイルシステムを拡張します。

メモリ不足エラー

インスタンスのシステムログに「メモリ不足: プロセスの終了」というエラーが表示された場合、インスタンスのメモリがすべて使用されています。メモリがすべて使用されると、カーネルの実行に必要なメモリが不足し、メモリを解放するために他のプロセスが終了されます。

メモリ不足 (OOM) の問題を解決する方法の詳細については、「メモリ不足: プロセスの終了」を参照してください。

メモリエラーログ (メモリ不足) を確認するには、「方法 2:レスキューインスタンスを使用する」の手順 7「ボリュームをマウントする」までの手順に従います。

次に、Linux ディストリビューションに応じて、以下のコマンドを使用してログからメモリ不足アラートを検索します。

Amazon Linux 1 および Amazon Linux 2

sudo grep -i -r 'out of memory' /var/log/

Amazon Linux 2023

$ sudo journalctl -p err | grep -i "out of memory"

-または-

$ sudo dmesg | grep -i "out of memory"

メモリ不足 (OOM) の問題を解決する方法の詳細については、「メモリ不足: プロセスの終了」を参照してください。

ページ割り当ての失敗

ページ割り当ての失敗は、カーネルメモリアロケータが割り当てリクエストに失敗したときに発生します。この場合、システムログにページ割り当ての失敗のメッセージが追加されます。

このメモリ不足の問題をトラブルシューティングして解決するには、インスタンスをより大きなインスタンスタイプにアップグレードすることを検討してください。エフェメラルインスタンスストアボリュームを使用するインスタンスの場合は、インスタンスにスワップストレージを追加してメモリ負荷を軽減します。

スワップ領域の設定の詳細については、以下を参照してください。

• スワップファイルを使用して、Amazon EC2 インスタンスのスワップ領域として機能するようにメモリを割り当てるにはどうすればよいですか?
• ハードドライブのパーティションを使用して、Amazon EC2 インスタンスのスワップ領域として動作するようにメモリを割り当てる方法を教えてください。

注: RAM の容量が不足すると、インスタンスはスワップ領域を使用します。RAM の容量が少ないインスタンスにスワップ領域を使用することはできますが、RAM の増設の代わりにはなりません。スワップ領域はインスタンスのハードドライブ上にあるため、実際の RAM と比較するとパフォーマンスは遅くなります。メモリを増やしたり高速化したりするには、インスタンスサイズを増やすことを検討してください。

ページ割り当ての失敗の詳細については、access.redhat.com の「What are page allocation failures?」を参照してください。

関連情報

EC2 Linux インスタンスが到達不能で、そのステータスチェックの一方、または両方が失敗するのはなぜですか?

EC2 Linux インスタンスのインスタンスタイプを変更する前に、どのような手順を踏む必要がありますか?

CPU 使用率が高い EC2 Windows インスタンスを診断する方法を教えてください。