EC2 t2.medium突发信用"储蓄"计算

Question

我正在使用T2.medium实例.一天中的三分之一,我正在进行密集的统计计算,并认为其余的2/3时间我将以每小时24小时的速度"获得"积分.

但那并没有发生.这是我最近两天的使用情况:

这是我的信用账户:

直到昨天下午6点,我还没有用它(超过一天).我用它密集了五个小时.然后我希望我的"帐户"每小时能累积24个学分,但是9-10个小时几乎没有任何反应,然后它按预期累计9个小时然后再次变平.

我无法弄清楚发生了什么以及是否是一个错误.有没有人有一个很好的解释？

编辑:我在下面列出了一周的活动.我仍然无法弄清楚算法:

Answer 1

更新:用于计算t2 CPU贷方余额的规则似乎已更改,以便提示此问题的问题不应再产生影响.

根据客户反馈,我们使用新的CPU信用分配策略更新了T2实例,该策略在所有情况下都与先前的策略相同或更好.

...

现在,获得的CPU积分在实例终止或停止之前不会过期.T2实例仍然可以获得实例大小允许的最大级别.CPUCreditBalance现在会在当前CPUCreditUsage低于基线的任何时候增加,并且可以增长到实例大小允许的最大值

https://forums.aws.amazon.com/ann.jspa?annID=5196

h/t:AWS的上周进行更新.

原来的答案如下.

这个问题在过去的几个小时里给我带来了相当多的精神痛苦,因为基于我对t2实例的了解,这些图几乎是有意义的. 几乎,但不完全,我无法指出问题.那是最糟糕的一种.尤其是t2机器提供的价值主张的巨大粉丝.

但我终于弄清楚这里发生了什么.

有一个CPU信用的概念,文档似乎没有解释,但数学计算出来了,并且解释在现实世界观察中很好地得到了解释:

最近获得的CPU学分首先花费,而不是最后花费.

订单有关系吗？确实如此.

为了进行测试,我使用了t2.micro(主要是因为我有一个已经运行了好几天的闲置,需要做点什么,而且我不想让新实例的额外"初始"信用点云起来观察结果)但是t2类中的所有实例类型都有类似的行为.

作为背景:在t2类中,CPU学分以不同的速率获得,但CPU学分以相同的速率用于该类中的所有实例类型:

CPU Credit可在一分钟内提供完整CPU内核的性能.

t2.micro和t2.small只有一个核心,因此它们可以每分钟刻录1个信用点或每小时60个信用点,CPU利用率为100%.t2.medium和t2.large是双核心,因此它们可以每分钟刻录2个学分,或者每小时120个学分,两个核心的CPU利用率均为100%.

如果1个信用= 1个核心100%的1分钟,那么1个信用也等于1个核心的20%,持续5分钟.由于Cloudwatch图形间隔以5分钟为增量,因此我设置了以下测试:

在已经运行了几周且基本没有负载的t2.micro上,我安装了lookbusy,这是一个方便的实用程序,允许您使用您指定的参数使计算机"看起来很忙" - 例如,将CPU保持在20%的利用率.

$ screen -S eat_cpu
$ ./lookbusy -v -c 20 -r fixed

这完全符合您的期望,每5分钟刻录1个CPU信用."CPU信用额度"图表确认了这一点,显示每5分钟使用1个信用额度.(CPU利用率图表,并且top都确认了20%.)

但是我的信用余额发生了什么变化？它每5分钟消耗1点积分.那似乎不对,不是吗？我的意思是,是的,我刚才说的是我用了多少,但是......我也应该每小时赚6个学分,所以我应该每5分钟净掉0.5个学分, 对？

坚持......再次检查数字:我每小时收入6,每小时收费12,所以,是的......看起来它应该是每小时净减少6,而不是12 ...对？显然,某些东西并没有按照我的预期加起来,因为我的平衡肯定会下降到每小时12,而我的CPU肯定只能达到20%.

我似乎没有获得任何学分来抵消我的使用.怎么可能？

除非...

在给定的5分钟间隔内未使用的赢得的积分将在获得后24小时到期

好吧,24小时前,我的实例完全闲置了.在那个小时里,我获得了6个学分,我...没有(？)使用.我现在不用它们吗？我不应该吗？

在添加任何新获得的积分之前,任何过期的积分将从当时的CPU积分余额中删除

污物.这有关系吗？这一小时,我获得了6个新学分.但在此之前,我从24小时前失去了6个学分.然后我这小时花了12个学分...所以我的平衡时间下降了6个,上升了6个,然后下降了12个.那么,这解释了-12小时的变化,但......

这可能是原因吗？

我是一个贪婪的文档读者,所以我知道即将到期的学分方面...但我一直认为这只不过是空闲实例徘徊在其最大平衡附近的原因,并没有任何其他意义.怎么可能呢？如果我的最大值小于最大值(6 x 24 = t2.micro为144)那​​么我怎么能得到到期的需要呢？

如果我24小时前的学分总是在不计算我,那么无论我做什么,我的余额都不会趋于零吗？

除非...

在大部分时间折腾和转动之后,考虑在虚构的桌面(代表时间)上滑动成堆的假想标记(代表CPU信用)......我意识到"过期"规则将导致我们观察到的行为,如果,反直觉地,信用不是按照它们获得的顺序(FIFO)花费,而是以相反的顺序(LIFO)花费.

按照这种推理方式,我的20%CPU测试实际上做的是这样的解释,我的测试的第一个小时是"小时0" -

     | spends 6+6 credits  | expire 6 credits
test | earned this many    | earned this many
hour | hours before hour 0 | hours before hour 0
-----+---------------------+--------------------
 0       -1,  -2                   -24
 1       -3,  -4                   -23
 2       -5,  -6                   -22
 3       -7,  -8                   -21
 4       -9, -10                   -20
 5      -11, -12                   -19
 6      -13, -14                   -18
 7      -15, -16                   -17

他们在中间见面.

这是真的吗,还是我猜？我不猜,这是证据:

8小时后,我的CPU信用使用率图表保持稳定,仍然稳定在每5分钟1个信用点,但在相同的8小时后,我的CPU信用余额最终开始以我原先预期的(较慢)速率耗尽:每个0.5个信用点5分钟.

显然,当我及时向后工作时,先前已经获得了"最新第一"的学分,我赶上了即将到期的旧学分,最终达到我有机会到期之前使用它们的程度.现在,我没有24小时的学分,所以没有学分到期 - 所以我不再在获得新学分之前失去学分.我现在能够保持每小时赚取的6,因为我用完了旧的,将我的信用余额的净影响降低到预期水平.

这解释了我对问题中图表的唯一保留:为什么,当利用率下降时,平衡需要很长时间才能反弹？

该TL; DR答案是这样的:天平不会立即反弹,重利用一阵之后,因为你还有时间从24小时未使用的信用之前,这是抵消了你新获得的学分,直到到达该点你没有任何24小时未使用的学分的时间.发生这种情况时,您的信用余额会再次增加.

让实例完全闲置24小时,你最终会看到稳定的平衡(大部分)再次达到最大值,正如预期的那样.任何不到24小时完全闲置的东西都会导致你的余额永远低于最大值.

我的测试脚本最终耗尽了我的信用余额.当我杀死使用CPU的过程时,信用余额立即开始恢复,达到每小时6个信用点的预期速度.

相反,当我使用另一台24小时低利用率的机器,并将其CPU运行至100%几分钟,然后将其恢复到闲置状态时,信用额度不会立即累积...被抵消旧的,即将到期的.

报价来自http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html.