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

簡単な説明

次の要因で、リソースの使用状況に起因し、インスタンスがステータスヘルスチェックに合格できない可能性があります。

• インスタンスの CPU 使用率が 100% 近くに達し、そのインスタンスではカーネルを実行するのに十分なコンピューティングキャパシティが枯渇した場合。
• ルートデバイスに空き容量がなく、他のプロセスを完了または開始できない場合。
• インスタンスで実行されるプロセスはメモリをすべて使用しており、カーネルが実行できない場合。

解決策

重要: インスタンスを停止して起動する前に、次の手順を実行してください。

• Amazon Elastic Block Store (Amazon EBS) ボリュームのスナップショットを作成します。
  注: インスタンスの基盤がインスタンスストアであるか、データを含むインスタンスストアボリュームがある場合、インスタンスの停止時に Amazon EC2 はデータを削除します。
• Amazon EC2 Auto Scaling グループからインスタンスを一時的に削除します。
  注: Amazon EC2 Auto Scaling グループ内のインスタンスを停止する場合、インスタンスがスケールイン保護設定に基づいて削除される場合があります。Amazon EMR、AWS CloudFormation、または AWS Elastic Beanstalk を使用して起動するインスタンスが、Auto Scaling グループに属している可能性があります。
• インスタンスのシャットダウン動作を Stop に設定し、インスタンスの停止時に、そのインスタンスが削除されないようにします。

インスタンスを停止して起動します。この手順により、カーネルは実行中のプロセスを強制的に停止します。この方法は、リソースをオペレーティングシステム (OS) に戻すための一時的な解決策です。過剰使用の問題を解決するには、次の手順を実行して根本原因に対処してください。

注: インスタンスを停止または起動する際、インスタンスのパブリック IP アドレスは変更されます。外部トラフィックをインスタンスにルーティングするには、パブリック IP アドレスではなく Elastic IP アドレスを使用することをおすすめします。

インスタンスの CloudWatch CPU メトリクスを確認する

インスタンスの Amazon CloudWatch CPUUtilization メトリクスが 100% またはそれに近くなっていないかを確認します。当てはまる場合は、インスタンスを再起動し、インスタンスを正常な状態に戻してください。再起動後も問題が発生する場合は、インスタンスの CPU 要件は、使用しているインスタンスタイプが提供するものよりも高いことが示唆されます。

この問題を解決するには、CPU の可用性が高いインスタンスタイプに変更してください。

使用中のインスタンスが T2、T3、T3a などのバーストパフォーマンスインスタンスの場合は、CpuCreditBalance メトリクスを確認してください。クレジット残高がゼロに近い場合、Amazon EC2 により、インスタンスの CPU がスロットリングされます。インスタンスのクレジット仕様を Standard に設定していた場合は、仕様を Unlimited に変更してください。

インスタンスのシステムログにエラーがないか確認する

システムログを参照し、"No space left on device"、"Out of memory" などのエラーが発生していないか確認してください。

"No space left on device" エラーのトラブルシューティング

表示されたフォルダを含むファイルシステムには空き領域がない場合、次の例に類似したエラーが発生します。

"OSError: [Error 28] No space left on device '/var/lib/'"

上記の例では、/var/lib には空き領域がありません。

EC2 シリアルコンソールでサポートされている Nitro ベースのインスタンスタイプとサポートされているベアメタルインスタンスに接続し、スペースを解放してください。次に、不要なファイルを削除します。EC2 シリアルコンソールを使用する際は、インスタンスに接続するための有効な接続は必要ありません。

EC2 シリアルコンソールを初めて使用する場合は、前提条件を満たしていることを確認してください。インスタンスに到達できず、シリアルコンソールへのアクセス設定が完了していない場合は、EC2 シリアルコンソールを使用できません。

EC2 シリアルコンソールを使用できない場合は、次の手順を実行してレスキューインスタンスを起動し、不要なファイルを削除してください。

1. 仮想プライベートクラウド (VPC) で新たにレスキューインスタンスを起動します。ステータスチェックに合格できないインスタンスと同一の Amazon マシンイメージ (AMI) およびアベイラビリティーゾーンを使用してください。
   注: 元のインスタンスと同じアベイラビリティーゾーンに存在し、同じ AMI を使用する既存のインスタンスを使用することもできます。

2. 元のインスタンスを停止します。

3. オリジナルインスタンスから、Amazon Elastic Block Store (Amazon EBS) のルートボリュームをデタッチします (例: /dev/xvda、/dev/sda1)。ルートボリュームのデバイス名を書き留めておきます。

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

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

6. レスキューインスタンスにアタッチしたボリューム用のマウントポイントディレクトリを作成するには、次のコマンドを実行します。

   sudo mkdir /rescue

   注: /rescue をマウントポイントのディレクトリ名に置き換えてください。

7. 次のコマンドを root ユーザーとして実行し、正しいデバイス名を特定します。

   sudo -i
   # lsblk

   注: レスキューインスタンスにアタッチされたデバイスには、異なるデバイス名が付いている場合があります。

8. ボリュームを新しいディレクトリにマウントするには、次のコマンドを実行します。

   sudo mount /dev/xvdf1 /rescue

   注: 実際のものでそれぞれ、dev/xvdf1 をルートボリュームのデバイス名に、/rescue をマウントポイントのディレクトリ名に置き換えてください。上記のコマンドを実行するとエラーが発生する場合は、「Why can't I mount my Amazon EBS volume? (Amazon EBS ボリュームをマウントできない原因を教えてください)」を参照してください。

9. 最も容量を消費しているファイルを特定するには、次のコマンドを実行します。

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

10. 空き容量を増やすには、不要な大容量ファイルを削除してください。

11. レスキューインスタンスからセカンダリデバイスをアンマウントするには、次のコマンドを実行します。

sudo umount /rescue

注: /rescue をマウントポイントのディレクトリ名に置き換えてください。
アンマウント操作が失敗した場合は、レスキューインスタンスを停止または再起動してから、上記のコマンドを再度実行してください。 レスキューインスタンスからセカンダリボリュームをデタッチします。 ボリュームを、/dev/xvda または /dev/sda1 というルートボリュームとして元のインスタンスにアタッチします。 インスタンスを起動し、インスタンスが応答するかどうかを確認します。

それでも十分なストレージを確保できない場合は、次の手順を実行するとルート EBS ボリュームのサイズを変更できます。

1. EBS ボリュームサイズの変更をリクエストします。
2. 前のセクションのステップ 1 ～ 8 を実行し、レスキューインスタンスを起動します。
3. Linux ファイルシステムを拡張します。

"Out of memory" エラーのトラブルシューティング

インスタンスがメモリ不足の場合、次のエラーが発生します。

"Out of memory: kill process"

インスタンスがメモリ不足になると、カーネルには実行に必要なメモリが不足しているため、Amazon EC2 は他のプロセスを終了してメモリを解放します。トラブルシューティング手順については、「メモリ不足: プロセスの終了」を参照してください。

メモリログを確認するには、前のセクションのステップ 1 ～ 8 を実行し、レスキューインスタンスを起動します。次に、使用する Linux ディストリビューションに応じて次のコマンドを実行し、ログから "out of memory" というメッセージを検索します。

Amazon Linux 2 (AL2):

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

Amazon Linux 2023 (AL2023):

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

または、

sudo dmesg | grep -i "out of memory"

ページ割り当てエラーのトラブルシューティング

カーネルメモリアロケーターが割り当てリクエストに対応できない場合、"page allocation failure" エラーが発生します。

この問題をトラブルシューティングするには、インスタンスを大容量インスタンスタイプにアップグレードすることをおすすめします。エフェメラルインスタンスストアボリュームを使用するインスタンスでは、スワップファイルまたはハードドライブパーティションを使用してインスタンスにスワップストレージを追加するとメモリ負荷を軽減できます。

注: RAM の空き容量がなくなると、インスタンスはスワップ領域を使用します。インスタンスの RAM 容量が少ない場合は、スワップ領域を使用できます。ただし、スワップ領域は RAM 増設の代替策にはなりません。スワップ領域はインスタンスのハードドライブに置かれるため、パフォーマンスは RAM よりも低速です。メモリを増設したり高速化したりするには、インスタンスサイズを大容量にする必要があります。

atop を使用してリソースの問題を調査、防止する

atop 監視ツールを使用すると、システム障害が発生する前に、そのような問題を引き起こす可能性のあるリソース使用パターンとプロセスを特定できます。atop ツールは、システムの継続的な監視とトラブルシューティングに役立ちます。

注: atop ツールは、インストール後のデータのみを記録します。atop ツールをインストールする前の、過去のパフォーマンスデータを取得することはできません。

atop ツールで次のリソースを確認してください。

• /var/log/atop/ の過去データを参照し、障害の発生時のシステムとプロセスを分析します。
• 大量のリソースを消費するプロセスを特定します。
• 障害の原因となったメモリ、CPU、ディスク使用パターンを確認します。

関連情報

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

EC2 Linux インスタンスのインスタンスタイプを変更する前に必要となる手順を教えてください