多个 t2.micro 优于单个 t2.small 或 t2.medium答案

【问题标题】：several t2.micro better than a single t2.small or t2.medium多个 t2.micro 优于单个 t2.small 或 t2.medium
【发布时间】：2015-06-27 15:37:22
【问题描述】：

我阅读了 EC2 的文档：instance types、pricing、FAQ、burstable performance 以及 this 关于 CPU 积分。我什至问了下面的 AWS 支持，答案也不清楚。

问题是，根据文档（虽然不太清楚）和 AWS 支持，所有 3 种实例类型在突发时具有相同的性能，它是 100% 使用某种类型的 CPU 内核。

这就是我的思考过程。假设 t2.micro 的 RAM 足够并且软件可以水平扩展。拥有 2 个 t2.micro 与 1 个 t2.small 的成本相同，假设负载在它们之间平均分配（可能通过 AWS LB），它们将使用相同数量的总 CPU 并消耗相同数量的 CPU 积分。如果他们要回退到基线性能，那将是相同的。

但是，当它们爆发时，2 t2.micro 可以达到 t2.small 的 x2 性能（同样，成本相同）。相同的概念适用于 t2.medium。此外，使用较小的实例可以实现更紧密的自动（或手动）扩展，从而可以节省资金。

所以我的问题是，鉴于 RAM 和水平缩放不是问题，为什么要使用 t2.micro 以外的其他工具。

编辑：经过一些回复，这里有一些关于它们的说明：

我询问了 AWS 支持，据说 t2.medium 的每个 vCPU 可以达到“全核”的 50%。这意味着我所说的同样适用于 t2.medium（如果他们说的是正确的话）。
T2.micro 实例可用于生产。根据技术和实现，单个实例可以处理超过 400 RPS。我喜欢，this guy 也是。
确实需要仔细查看以确保信用不会降低，但我不接受这是不使用它们的理由。

【问题讨论】：

我同意您的分析，但前提是您的工作量可以像您提到的那样纯横向扩展。所需的任何垂直扩展都将受益于更大的 t2 实例。说 t2.micro 和 t2.small 之间的最大区别在于您可以使用 CPU 实现的基准性能。如果您有任何 CPU 密集型任务，那么能够长时间维持 20% 的 CPU 利用率将是使用 t2.small 实例的理由。
请注意，t3 代加强了 micros 的情况，因为现在它们有 2 个 vCPU，甚至与 t3.large 一样多。

标签： amazon-web-services amazon-ec2

【解决方案1】：

分配给每个实例的积分余额各不相同。因此，虽然两个 micros 可以在突发期间提供 small 的两倍性能，但它只能提供一半的时间。

出于可用性目的，我通常更喜欢至少两个实例。但是对于可突发模型，工作量也被考虑在内。你在看持续负载吗？还是您预计全天会出现随机峰值？

【讨论】：

流量不是高峰，而是在白天变化。感谢您的评论，但我不是在寻找关于是否依赖 T2 的建议，我前段时间评估了这些选项。请注意，2 个实例（对于相同的负载）的 CPU 利用率将是单个实例的一半，因此它们不会维持一半的时间，这是同一时间，因为每个实例要做的工作更少。

【解决方案2】：

这里有很多移动目标。你的实例在做什么？你说流量在一天内变化，但不是尖峰。因此，如果您希望使用少量 t2.micro 实例“密切关注”负载，您将无法使用过多的突发，因为在每次升级时，您的 CPU 积分都会很低。因此，如果您的大多数实例仅在负载不足时运行，它们将永远不会收集 CPU 积分。此外，每次启动时间和未使用但已开始的使用时间都会浪费时间和金钱，因此过于频繁的向上/向下扩展并不是最具成本效益的。最后但并非最不重要的一点是，操作系统，其他软件或多或少都有修复开销，运行它 2 次而不是 1 次，可能会从系统中的应用程序中占用更多资源，在该系统中，您仅在 20% 的负载下获得 CPU 积分.

如果您想要极高的成本效率，请使用 Spot 实例。

【讨论】：

您好，感谢您的评论。缩放确实是一个旁注。假设我让它们整天运行。大型机器的唯一优势是操作系统处理能力，但实际上，相比之下这非常低。
一般你不应该在生产环境中使用 T 类型的实例。如果您不介意有一些停机时间（如果您有负载并且您的信用不足，您可能会遇到什么），那么您也可以使用一组现场实例。但是，您可以以优惠的价格获得 m3.small。（如果出价太高，请准备一个带有 t 实例的自动缩放组。）
请注意，我在问题中添加了更多信息，与生产中的 T 相关。有一些方法可以监控信用并在它发生之前采取行动。这里的重点是 T2 实例的极高成本效率，这使得所有这些都成为可行的讨论。
@AdamOcsvari 我同意您的建议，即使用 t2 池 + 现货实例以非常便宜的方式满足峰值/现货价格上涨 + 基本负载。不过，我不同意 t2 不具备生产能力。对于您只需要 a 服务器（或 HA 对）持续启动的许多情况，它们是完全足够的。 t2.micro 可以维持 2 小时的完全爆发（或小型/中型约 5 小时）足以自动对持续负载做出反应。在工作负载中等且受磁盘或网络 I/O 限制的情况下，它们也是完美的。 t2.micro/medium 主机尤其是最好的 Jenkins 服务器。

【解决方案3】：

您的分析似乎是正确的。

虽然没有明确记录处理器类型，但我通常会看到我的 t2.micro 实例配备一个 Intel Xeon E5-2670 v2 (Ivy Bridge) 内核，而我的 t2.medium 实例有两个。

只要有合理数量的剩余 CPU 积分，微型和小型确实应该具有相同的突发性能。我说“一个合理的数字”是因为记录显示性能会在 15 分钟的窗口内平稳下降，而不是像 t1.micro 那样急剧下降。

随着您的升级，三个课程（除了核心课程，无论是微型还是小型）的所有内容都会乘以 2：基线、每小时赚取的学分和学分上限。可以说，就短期突发性能（具有两个内核）而言，中型非常接近于两个小部分，但是正如您所指出的，这也正是您拥有两个微型的能力。如果内存不是问题，并且流量适当突发，那么您的分析是明智的。

虽然 t1 类几乎完全不适合生产环境，但 t2 类并非如此。他们是天壤之别。

如果您的代码在内存方面紧凑高效，并且您的工作负载适合基于 CPU 积分的模型，那么我同意您对 t2.micro 所代表的卓越价值的分析。

当然，这是一个巨大的“如果”。然而，我的网络中的系统完全适合这个模型——它们的内存几乎完全在启动时分配，它们的负载相对较轻，但在一天中变化很大。只要您的贷方余额没有用尽，我认为这种方法没有任何问题。

【讨论】：

谢谢，没有冒犯其他 cmets，但这是第一个关注问题而不是其他问题的答案。我根据此回复编辑了其他内容。
根据这里的基准vpsbenchmarks.com/compare/ec2_vs_gce t2-small 45.8ms，t2-micro 161.0ms 的平均响应时间。性能冲击来自哪里？