如何对因资源过度使用而未通过状态检查的 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 组中。
• 将实例关闭行为设置为 Stop（停止），以确保实例在您停止时不会终止。

停止并启动您的实例，以强制内核停止正在运行的进程。这是将资源返回给操作系统 (OS) 的临时解决方案。要解决过度使用问题，请执行以下操作以解决根本原因。

**注意：**当停止或启动某个实例时，该实例的公共 IP 地址将发生变化。最佳做法是使用弹性 IP 地址而不是公共 IP 地址将外部流量路由到您的实例。

检查实例的 CloudWatch CPU 指标

检查实例的 Amazon CloudWatch CPUUtilization 指标是否等于或接近 100%。如果是，请重启您的实例以使实例恢复正常状态。如果重启后问题仍然出现，则表明该实例的 CPU 需求量高于您的实例类型所提供的 CPU 量。

要解决此问题，请将您的实例类型更改为 CPU 可用性更高的实例类型。

如果您的实例是可突增性能实例（例如 T2、T3 或 T3a），请检查其 CPUCreditBalance 指标。如果积分余额接近零，则 Amazon EC2 会限制实例 CPU。如果您将实例的 Credit specification（积分规范）设置为 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 Serial Console 连接到受支持的基于 Nitro 的实例类型和受支持的裸机实例。然后，删除不需要的文件。使用 EC2 Serial Console 时，无需有效的连接即可连接到您的实例。

如果您之前没有使用过 EC2 Serial Console，请确保遵循先决条件。如果您的实例无法访问并且您尚未配置对串行控制台的访问权限，则无法使用 EC2 Serial Console。

如果您无法使用 EC2 Serial Console，请完成以下步骤，以启动救援实例并删除不需要的文件：

1. 在您的虚拟私有云 (VPC) 中启动新的救援实例。使用与状态检查失败的实例相同的亚马逊机器映像 (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 发行版运行以下命令，在日志中搜索 "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"

-or-

sudo dmesg | grep -i "out of memory"

对 "page allocation failure" 进行故障排除

当内核内存分配器分配请求失败时，您会收到 "page allocation failure" 错误。

要解决此问题，最佳做法是将实例升级到更大的实例类型。或者，对于使用临时实例存储卷的实例，请使用交换文件或硬盘分区向实例添加交换存储，以缓解内存压力。

**注意：**当 RAM 已满时，实例会使用交换空间。对于 RAM 较小的实例，您可以使用交换空间。但是，交换空间不能替代更多的 RAM。由于交换空间位于实例的硬盘上，因此与 RAM 相比，性能较慢。要获得更多或更快的内存，必须增加实例大小。

使用 atop 调查并预防资源问题

使用 atop 监控工具识别可能引发问题的资源使用模式和进程，以免其导致系统故障。atop 工具可帮助您持续监控系统并排查系统问题。

**注意：**atop 工具仅在安装后才会记录数据。您无法检索安装 atop 工具之前的历史性能数据。

使用 atop 工具检查以下资源：

• 查看 /var/log/atop/ 中的历史数据，以分析故障发生时的系统和进程。
• 查找消耗大量资源的进程。
• 检查导致故障的内存、CPU 和磁盘使用模式。

相关信息

如何对 EC2 Linux 实例的状态检查失败问题进行故障排除？

在更改我的 EC2 Linux 实例的实例类型之前，我需要执行哪些步骤？