Ari*_*ler 12 amazon-ec2 amazon-web-services
我阅读了EC2的文档:实例类型,定价,常见问题,突发性能以及有关CPU信用的这些内容.我甚至问过以下AWS支持,答案也不清楚.
问题是,根据文档(虽然不太清楚)和AWS支持,所有3种实例类型在突发时具有相同的性能,它是100%使用某种类型的CPU核心.
所以这是我的思考过程.假设t2.micro的RAM足够,软件可以水平扩展.有2个t2.micro与1 t2.small具有相同的成本,假设负载在它们之间平均分配(可能通过AWS LB),它们将使用相同数量的总CPU并消耗相同数量的CPU信用.如果它们回归到基线性能,它将是相同的.
但是,当它们爆裂时,2 t2.micro可以达到x2 t2.small的性能(同样的成本).同样的概念适用于t2.medium.此外,使用较小的实例允许自动(或手动)缩放,这允许节省金钱.
所以我的问题是,鉴于RAM和水平比例不是问题,为什么一个人使用除了t2.micro之外.
编辑:经过一些回复,这里有一些关于它们的说明:
Mic*_*bot 13
你的分析似乎是对的.
虽然处理器类型没有明确记录,但我通常会看到我的t2.micro实例配备了一个Intel Xeon E5-2670 v2(Ivy Bridge)核心,而我的t2.medium实例有两个.
只要具有合理数量的CPU信用剩余,微小的确应具有相同的突发性能.我说"一个合理的数字"因为记录的性能会在15分钟的窗口内优雅地降级,而不是像t1.micro那样急剧下降.
当你提升时,关于三个类别(除了核心,微观与小)的所有内容都会增加两倍:基线,每小时赚取的信用额度和信用上限.可以说,当涉及到短期突发性能(具有两个内核)时,介质非常接近于两个小,但是再次说明,正如你所指出的那样,这也恰好具有两个微处理器的能力.如果内存不是问题,流量是适当的突发,你的分析是明智的.
虽然t1类几乎完全不适合生产环境,但t2类也是如此.他们是世界分开的.
如果您的代码对内存非常紧凑且高效,并且您的工作负载适用于基于cpu信用的模型,那么我同意您对t2.micro所代表的优秀价值的分析.
当然,这是一个巨大的"如果".但是,我的网络中的系统完全适合这个模型 - 它们的内存几乎完全在启动时分配,它们的负载相对较轻但在一天中变化很大.只要你没有用尽你的信用余额,我就没有看到这种方法的错误.
分配给每个实例的信用余额各不相同。因此，虽然两个微型芯片在爆发期间可以提供双倍的性能，但它只能持续一半的时间。
出于可用性目的，我通常更喜欢至少两个实例。但对于突发模型，工作负载也需要考虑在内。您正在考虑持续负载吗？或者您是否预计全天会出现随机峰值？
| 归档时间： |
|
| 查看次数： |
8903 次 |
| 最近记录： |