我有亚马逊微型实例，看起来 CPU 不够用。将升级到具有更多可用 CPU 的下一个最便宜的实例。
可以是 m1.small 实例吗？根据描述，它们具有相同数量的计算单元。当更多内核可用于短时间 CPU 突发时，看起来 micro 甚至可以超越小型实例。
【问题讨论】：
标签： amazon-web-services amazon
更新：请注意，此信息仅适用于上一代 t1.micro 实例类型，它具有循环钳制节流算法。当前一代 t2 实例类，包括 t2.micro，比 t1.micro 具有更好的性能，并且控制节流的算法完全不同。 t2 实例类的节流由 CPU 积分驱动，这些积分在实例的 CloudWatch 指标中可见，节流更加优雅，并且在很久以后才会生效。 t1.micro 上的节流本质上是一个黑匣子，系统会在高负载下反复进出节流模式。除非您正在运行 PV AMI，否则不再有使用 t1 实例的令人信服的理由。 t2 是 HVM。
ECU 是“EC2 计算单元”，大致相当于 1.0-1.2 GHz 2007 Opteron 处理器的 CPU 容量。
This Comparison of t1.micro and m1.small 解释说，小型实例有 1 个持续可用的 ECU，而 Micro 可以在最多 2 个 ECU 的短时间内运行，但持续基线要少得多。
在我的测试中，我发现在微型实例上消耗 100% CPU 大约 10-15 秒，在接下来的 2-3分钟，当节流提升几秒钟时，循环重复，尽管它只有在你仍然拉硬爆裂时才会重复。他们通过管理程序“窃取”大部分可用周期来完成节流。当它发生时，您可以在“顶部”中看到它。如果您在不要求 100% CPU 的情况下运行足够长的时间，那么 2 ECU 突发在您需要时立即可用——这并不是说它们使用计时器来上下循环性能——节流对施加的负载是有反应的。
随着时间的推移，小型实例将完成更多处理，因为在几秒钟的大量使用后，微型实例被如此积极地限制，足够长的时间足以抵消短暂的良好突发性。这是有道理的，尽管因为微型是成本较低的实例。
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts_micro_instances.html
...所以，是的，尝试一个小实例。
【讨论】：