如何對因資源過度使用而導致 EC2 Linux 執行個體狀態檢查失敗的問題進行疑難排解？

簡短描述

您的執行個體可能因以下資源使用情況導致運作狀態檢查失敗：

• 您執行個體的 CPU 使用率已接近 100%，且執行個體沒有足夠的運算能力供核心執行。
• 根裝置已使用 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 群組中。
• 將執行個體關閉行為設定為停止，以確保執行個體在您停止時不會終止。

先停止再重新啟動您的執行個體，以強制核心停止正在執行的程序。這是將資源傳回給作業系統 (OS) 的臨時解決方案。若要解決過度使用問題，請採取以下步驟來解決根本原因。

**注意：**當您停止和啟動執行個體時，該執行個體的公有 IP 位址也會變更。最佳實務是使用彈性 IP 位址而不是公用 IP 位址，將外部流量路由到執行個體。

檢查執行個體的 CloudWatch CPU 指標

檢查執行個體的 Amazon CloudWatch CPUUtilization 指標是否達到或接近 100%。如果是，請重新啟動執行個體，使執行個體恢復到運作良好的狀態。如果重啟後問題仍然存在，則表示該執行個體所需的 CPU 資源超過了其執行個體類型所能提供的上限。

若要解決此問題，請變更執行個體類型，使其具有更高的 CPU 可用性。

如果您的執行個體是爆量效能執行個體，例如 T2、T3 或 T3a，請檢查其 CPUCreditBalance 指標。如果點數餘額接近零，那麼 Amazon EC2 會對執行個體 CPU 限流。如果您將執行個體的點數規格設定為標準，請將規格改為無限制。

檢查執行個體的系統日誌中是否有錯誤

檢查系統日誌中是否存在「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 Machine Image (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. 以根使用者身分執行以下命令，以識別正確的裝置名稱：

   sudo -i
   # lsblk

   **注意：**連接到救援執行個體的裝置可能具有不同的裝置名稱。

8. 若要將磁碟區掛載到新目錄，請執行下列命令：

   sudo mount /dev/xvdf1 /rescue

   **注意：**將 dev/xvdf1 替換為您根磁碟區的裝置名稱，並將 /rescue 替換為您的掛載點目錄名稱。如果您在執行上述命令時收到錯誤，請參閱為什麼我無法掛載 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 發行版執行以下命令，搜尋日誌中的「記憶體不足」訊息：

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 執行個體的類型之前，我需要採取哪些步驟？