我有一个运行 windows 2008 R2 的微型 EC2 实例。最近我收到了很多高 CPU 警报，当我登录 AWS 管理控制台时，我看到我的 CPU 几乎固定在 100%。但是，如果我登录实例并打开任务管理器，我的 CPU 看起来几乎处于空闲状态。我已经将任务管理器打开了一段时间，并截取了这张屏幕截图，显示了 AWS 正在报告的内容与我的实例正在执行的操作之间的差异。建议？
（https://s3.amazonaws.com/caskerdbbucket/public/cpu.png）
PS：任务管理器更新速度设置为“低”
操作系统公开的数据在Amazon EC2等虚拟化环境中通常不足或具有误导性，并且报告的百分比取决于您的实例类型和底层处理器核心利用率（通常与您从管理程序），除其他外 - 您所看到的很可能是由当今大多数相关 Unix/Linux 监控工具中暴露的相应CPU 窃取时间引起的（但不幸的是，不是在 Windows 上，请参阅我的问题Is there a Windows equivalent of Unix' CPU 窃取时间'？有关此问题的更多信息） - 参见例如列 %steal 或 st in saror top：
st -- 窃取时间
管理程序从该虚拟机“窃取”用于其他任务（例如运行另一个虚拟机）的 CPU 量。
博文EC2 监控：CPU 被盗案例对此主题进行了很好的探索和说明：
当 top 命令显示 40% CPU 繁忙但 CloudWatch 显示服务器已达到 100% 时，您会选择哪一边？答案很简单（CloudWatch 是正确的，top 不是）[...]
CPU 窃取时间对于您正在使用的 EC2 实例类型 t1.micro 来说尤其普遍，根据定义，它可能会受到严重限制（通常约为 97% 的窃取时间！），请参阅微实例以获得对该概念的广泛解释和说明 - 具体而言，实例使用其分配的资源时的部分状态：
我们希望您的应用程序在一段时间内仅消耗一定数量的 CPU 资源。如果应用程序消耗的 CPU 资源超过您的实例分配的 CPU 资源，我们会暂时限制该实例，使其在低 CPU 级别运行。如果您的实例继续使用其分配的所有资源，其性能将会下降。我们将增加限制其 CPU 级别的时间，从而增加允许实例再次爆发之前的时间。[强调我的]
因此，您可能已经超出了微型实例的可持续 CPU 使用情况，需要调整您的工作负载或切换到另一种实例类型。
我遇到了同样的问题，花了很多时间才找到解决方案。在互联网上我没有找到我的案例，所以我分享。
我在事件列表中发现记录了许多欺诈性登录尝试。在那种情况下，任务管理器报告了 30-40% 的 CPU 使用率（Cloud Watch 100%），并且在进程列表中可以看到一些 winlogon.exe。更改远程桌面端口（默认为 3389）后，我没有更多问题了。现在 Cloud Watch 中的 CPU 使用率高达 34-35%。
希望这可以帮助。