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：Last Week in AWS进行更新。

原始答案如下。

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

但我终于弄明白这里发生了什么。

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

最近获得的CPU积分首先花费，而不是最后一刻。

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

为了进行测试，我使用了t2.micro（主要是因为我有一个已经运行了好几天的闲置，需要做点什么，而且我不想要额外的＆＃34;初始＆＃ 34;新实例的信用来掩盖观察结果）但是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，这是一个方便的实用程序，可以让你制作一台机器并且看起来很忙...＃34;使用您指定的参数 - 例如，将CPU保持在20％的利用率。

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

这正是您所期望的，每5分钟刻录1个CPU点数。 ＆＃34; CPU信用使用＆＃34;图表证实了这一点，显示每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信用）上滑动时，大部分时间都在折腾和转动之后......我意识到＆＃34;到期＆＃34;规则将导致我们观察到的行为，如果反直觉地，信用不花费在他们获得的顺序（FIFO），而是以相反的顺序（LIFO）。

按照这样的推理，我的20％CPU测试实际上做的是这样的解释，我的测试的第一个小时是＆＃34;小时0＆＃34; -

     | 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分钟仍保持稳定，但在相同的8小时后，我的CPU余额最终开始耗尽（我最初的预期：每5分钟0.5学分。

显然，当我及时工作时，花费以前赢得的积分和最新的积分，＆＃34;我赶上了即将到期的旧信用，最终达到我有机会到期之前使用它们的程度。现在，我没有24小时的学分，所以没有学分到期 - 所以我不再在获得新学分之前失去学分。我现在能够保持每小时赚取的6，因为我用完了旧的，将我的信用余额的净影响降低到预期的水平。

这解释了我对问题中图表的唯一保留：为什么，当利用率下降时，余额是否需要很长时间才能反弹？

TL; DR 答案是这样的：在一次大量使用之后，余额不会立即反弹，因为您仍然有24小时前未使用的积分，这些积分正在取消您新获得的学分，直到您没有任何24小时未使用的学分时为止。发生这种情况时，您的信用余额会再次增加。

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

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

相反，当我使用另一台24小时低利用率的机器，并将其CPU运行至100％几分钟，然后将其恢复到闲置状态时，积分没有开始积累直接地......被旧的，过期的那些所抵消。

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