我的 EC2 实例 (t2.small) 停止接受 SSH 或其他服务上的连接，但 EC2 控制面板显示自动状态检查并未失败，即使过了几个小时也是如此。我无法使用控制面板重新启动它，但我可以停止它并重新启动它。当天它又两次失去响应。
之后，我配置了 cgroups 来限制一个资源占用稍微大的进程的 CPU 和内存使用量，但这似乎不是正确的答案。这不应该导致机器停止运行。（它没有交换，但如果实例内存不足，OOM 终止程序应该会直接终止一个进程。）“获取系统日志”和“获取实例屏幕截图”没有显示任何可疑内容。该服务器正在运行一些相当可靠的软件，如 postfix 和 gitolite，以及一个以用户身份运行的开发中服务器。当我查看 CPU 使用率图表时，它显示这段时间为 2.5%，偶尔会飙升至 6% 左右。
我该怎么做才能解决这个问题并防止它再次发生？我能想到的只是这是一个硬件问题，但我认为这种情况不太可能发生。
答案1
我遇到了类似的问题，最终在查看我的t系列实例的 CPU 信用使用情况时找到了解决方案。默认情况下t系列实例使用 CPU 积分运行，一旦耗尽，实例就会失去响应，直到获得更多信用为止。
对我来说，无响应意味着：无法访问实例提供的任何服务和网站，包括对 ssh 连接尝试无响应。尝试重新启动实例无法恢复，只有停止实例并重新启动才能恢复。
我不知道有关电源关闭/打开事件的 CPU 信用系统的语义，但我认为电源循环本身必须附带信用奖励。
防止 t2 或 t3 实例以这种方式变得不可用的解决方案是以下之一：
- 使能够t2 无限制（或 t3 无限制），可能需要额外付费
- 升级到固定分配实例（m 系列），就我而言，这会使 VM 的成本翻倍，因为升级路径是从 t2.medium（0.045 美元/小时）到 m5d.large（0.113 美元/小时）。
- 重新部署到新的 t 系列实例，该实例附带新的信用分配。这里的成本很微妙，启动新的 VM 需要一些成本，但我不知道它是什么。
t2/t3 unlimited 表示一旦服务器超出了其 CPU 积分的使用量，则将对进一步的 CPU 使用量收取额外费用，直到获得更多积分。目前，超额使用量按24 小时期间。
在我们的具体案例中，我们的 t2 Jenkins 服务器变得无响应有时在有时候。很可能是那些天的源代码提交频率很高，导致 CI 运行更频繁，消耗了太多信用。我们切换到新的 t3，并启用了 T3 Unlimited。才过了几天，但问题还没有再次出现。作为 CI 服务器，它不太可能在一般工作时间之外运行太多，我非常怀疑成本是否会真正更高。
希望这篇事后分析能够帮助任何遇到同样问题的人。