为什么我的 EC2 Linux 实例因为资源过度使用而变得无响应？

上次更新时间：2021 年 10 月 25 日

实例无响应的常见原因有以下几种：

内存：原定设置情况下，EC2 实例没有分配虚拟内存空间。内存不足会调用 Linux Out Of Memory (OOM) 管理器。OOM 管理器终止进程，例如数据库、Web 服务器或 SSH 服务。

网络：如果没有联网，您的系统将无法应答状态检查中的 ARP 请求。发生这种情况时，您的实例将无法与其他主机通信。

Amazon Elastic Block Store (Amazon EBS): 由于没有磁盘 I/O，读取或写入指令会卡住。例如，创建临时文件、从系统库或数据库中读取数据。

CPU: 上述所有任务都需要 CPU 时间才能工作。长时间使用 100% 的 CPU 会阻止内核执行正常的操作系统运维。

这些问题也可能会累积成滚雪球效应。例如，内存不足，OOM 管理器终止了一个重要的进程。现在，依赖于停止的第一个进程的第二个进程会启动更多的 CPU 周期。如果此任务与磁盘相关，则此周期也可能耗尽 EBS 卷。此外，问题可能会传输到另一个实例，该实例正在等待来自无响应的实例进行通信。

如果您的系统经常由于资源过度使用而无法响应，请执行以下操作：

1. 使用 Amazon CloudWatch 之类的监控工具来观察高资源利用率的趋势和模式。
2. 如果您有多项服务，但不确定哪个服务过度利用了资源，请安装一个实用程序，例atop。
3. 查看应用程序和操作系统日志。这些日志通常位于 /var/log/ 中。
4. 查看命令的历史记录以查看是否存在人为错误。命令历史记录通常位于 ~/.bash_history 文件中。
5. 通过运行 crontab -l 命令来查看 cronjobs。

• 您可能会发现，您的应用程序需要更改配置或代码来优化资源利用率。
• 如果您的流程出于正当的原因（例如大量用户）使用了大量资源，请考虑升级您的实例。
  Amazon Compute Optimizer 是生成推荐实例大小的有用来源。您还可以考虑使用 Amazon EC2 Auto Scaling 进行水平扩展。
• 如果想更好地了解用户命令和配置更改，可以安装 `audit` 来跟踪更改。

1. 在生产环境中部署新应用程序之前，请创建测试环境和基准测试，以确定必要的计算、内存、EBS 和网络。
2. 根据基准进行部署，同时构建容错能力。有关更多信息，请参阅以下内容：
   在分布式系统中设计交互以预防发生故障
   教程：设置具有扩展和负载均衡功能的应用程序
3. 继续监控您的实例，并为某些资源使用阈值创建告警。