AWS EC2 高 CPU 警报响起

Posted

技术标签:

【中文标题】AWS EC2 高 CPU 警报响起【英文标题】:AWS EC2 High CPU alarms going off 【发布时间】:2012-07-27 01:09:00 【问题描述】:

我有一个运行 Windows 2008 R2 的微型 EC2 实例。最近我收到了很多高 CPU 警报,当我登录 AWS 管理控制台时,我发现我的 CPU 几乎固定在 100%。但是,如果我登录实例并打开任务管理器,我的 CPU 看起来几乎处于空闲状态。我已经将任务管理器打开了一段时间,并截取了这张屏幕截图,显示了 AWS 正在报告的内容与我的实例正在执行的操作之间的差异。建议?

(https://s3.amazonaws.com/caskerdbbucket/public/cpu.png)

PS:任务管理器的更新速度设置为“低”

【问题讨论】:

我在 t1.micro linux 实例上看到了同样的情况。 随着 t2 实例的发布,这可能已经基本消失,因为我们对何时可能会受到限制有了更多的了解。 【参考方案1】:

操作系统暴露的数据在Amazon EC2这样的虚拟化环境中通常是不充分或具有误导性的,报告的百分比取决于您的实例类型和底层处理器核心利用率(通常与您所使用的虚拟化硬件不匹配)由管理程序提供),除其他外 - 您所看到的很可能是由当今大多数相关的 Unix/Linux 监控工具中暴露的相应 CPU 窃取时间 引起的(但不幸的是,在 Windows 上没有,有关此问题的更多信息,请参阅我的问题Is there a Windows equivalent of Unix 'CPU steal time'?)-例如sartop 中的 %steal 或 st 列:

st -- 偷时间 从该虚拟机“窃取”的 CPU 数量 由管理程序执行其他任务(例如运行另一个虚拟 机器)。

博文EC2 monitoring: the case of stolen CPU 对该主题进行了很好的探索和说明:

当 top 命令显示 40% CPU 繁忙但 CloudWatch 显示 服务器已达到 100% 的上限——你站在哪一边?答案是 简单(CloudWatch 是正确的,top 不是)[...]

CPU 窃取时间 在您使用的 EC2 实例类型 t1.micro 中尤为普遍,根据定义,它可能会受到严重限制(通常约为 97% 的窃取时间!),请参阅 Micro Instances对该概念的广泛解释和说明 - 具体而言,When the Instance Uses Its Allotted Resources 部分指出:

我们希望您的应用程序仅消耗一定数量的 CPU 一段时间内的资源。如果应用程序消耗超过 您的实例分配的 CPU 资源,我们暂时限制 实例,因此它在低 CPU 级别上运行。如果您的实例继续 使用所有分配的资源,其性能将下降。我们 将增加我们限制其 CPU 级别的时间,从而增加 允许实例再次爆发之前的时间。 [强调我的]

因此,您可能已经超出了微型实例的可持续 CPU 使用情况,需要调整工作负载或切换到其他实例类型。

【讨论】:

优秀的答案。附带说明一下,我的实例现在似乎恢复正常了。【参考方案2】:

我遇到了同样的问题,花了很多时间才找到解决方案。 在互联网上我没有找到我的案例,所以我分享。

我在事件列表中发现记录了许多欺诈性登录尝试。在那种情况下,任务管理器报告了 30-40% 的 CPU 使用率(Cloud Watch 100%),并且在进程列表中可以看到一些 winlogon.exe。 更改远程桌面端口(默认为 3389)后,我再也没有问题了。 现在 Cloud Watch 中的 CPU 使用率高达 34-35%。

希望这会有所帮助。

【讨论】:

以上是关于AWS EC2 高 CPU 警报响起的主要内容,如果未能解决你的问题,请参考以下文章

服务器列表的 Cloudwatch 警报

Amazon EC2 Auto Scaling CPU 利用率警报 - 数据不足

如何根据多个警报扩展 aws ecs 服务

CloudWatch 自动警报删除执行多次

AWS 监控与报警 aws CloudWatch 自动恢复硬件故障实例 Auto Recover

实例关闭时触发 AWS Cloudwatch 监控警报