EC2 t2.medium突破性信用“储蓄”计算
我正在使用一个T2.medium实例。 三分之一的时间我正在进行密集的统计计算，并认为剩余2/3的时间我将以每小时24的速度“赚取”信贷。
但是这并没有发生。 这是我过去两天的用法：
这是我的信用账户：
直到昨天下午6点，我一天都没有使用它（超过）。 我用它密集了五个小时。 那么我希望我的“账户”每小时可以累积24个学分，但是9-10个小时几乎没有任何事情发生，然后如预期的那样9个小时完成，然后再次变平。
我无法弄清楚是怎么回事，如果是错的。 有没有人有一个很好的解释？
编辑：我已经包括了一个星期的活动。 我仍然不知道这个algorithm：
这个问题在过去的几个小时里引起了我很大的精神痛苦，因为根据我对t2实例的了解，图表几乎是有意义的。 几乎，但不完全，我不能把我的手指在这个问题上。 这是最糟糕的一种。 特别是t2机器提供的价值主张的巨大风扇。
但是我终于明白了这里发生了什么事情。
有一个CPU信用的概念，文档似乎没有解释，但是math运算出来了，并且在现实世界的观察下，这个解释很好地支持：
最近获得的CPU积分首先被使用，而不是最后使用。
订单是否重要？ 它确实。
为了testing，我使用了一个t2.micro（主要是因为我有一个已经运行好几天的空闲的，并且需要做些什么，而且我不希望新实例的额外的“初始”观察结果），但是t2类中的所有实例types都有类似的行为。
作为背景：在t2类中，CPU学分是以不同的速率获得的，但CPU学分对于类中的所有实例types使用相同的速率：
CPU信用提供了一分钟的完整CPU内核的性能。
t2.micro和t2.small只有一个核心，所以他们可以在CPU使用率达到100％的情况下，每分钟消耗1个信用点，或者每小时消耗60个信用点。 t2.medium和t2.large是双核，所以它们可以在两个内核上以100％的CPU利用率每分钟刻录2个信用点，或者每小时120个信用点。
如果1分钟= 1分钟的100％1分钟，那么1分钟也等于1分钟的20％，持续5分钟。 由于Cloudwatchgraphics间隔以5分钟为增量，因此我设置了以下testing：
在已经运行好几个星期，基本上没有任何负载的t2.micro上 ，我安装了lookbusy ，这是一个方便的工具，可以让你使用你指定的参数使机器“看起来很忙” – 例如，保持CPU的利用率为20％ 。
$ screen -S eat_cpu $ ./lookbusy -v -c 20 -r fixed 这正是你所期望的，每5分钟烧1个CPU信用点。 “CPU Credit Usage”图表证实了这一点，显示每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变化，但…
这可能是原因吗？
我是一个贪婪的文档阅读者，所以我知道即将到期的学分方面……但我始终认为，这只不过是一个闲置的实例在最大平衡附近hover的原因，没有任何其他意义。 怎么可能？ 如果我低于最大值（对于t2.micro，6 x 24 = 144），那么我怎么能有信用需要过期？
如果我24小时前的信用总是对我不利，那么无论我做什么，我的余额是不是会趋于零？
除非…
在考虑在一个虚构的桌面上（代表时间）在大量的想象的代币（代表CPU信用）上滑动并转动大部分的夜晚之后，我意识到“过期”规则将导致我们观察到的行为，直觉上，信用不会按照他们赚取的顺序（FIFO），而是按照相反的顺序（LIFO）。
按照这样的推理，我20％的CPUtesting实际上做的解释是这样的，我的testing的第一个小时是“小时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信用余额最终开始以我原本预期的（较慢）速率消耗： 5分钟。
显然，当我在时间上倒退时，以前的消费获得了“最新的优先”信用，我赶上了我即将到期的旧信用，最终达到了在他们有机会到期之前使用它们的地步。 现在，我没有24小时的信用，所以没有信用到期 – 所以我不再失去信用，才能获得新的信用。 我现在可以保留我每小时赚取的6美元，因为我用完了旧的帐户，将对我的贷方余额的净影响降低到预期的水平。
这就解释了我对这个问题中唯一的保留意见：为什么在利用率下降的时候，这个平衡会反弹呢？
TL，DR的答案是这样的：在一次大量使用之后，余额不会立即反弹，因为在24小时之前，您仍然有未使用的信用，这就是取消新获得的信用，直到达到当你没有任何24小时的未使用的信用。 当这种情况发生时，您的贷方余额再次增加。
让实例完全闲置24小时，您将最终稳定地（大部分）平稳地看到余额再次上升到预期的水平。 任何less于24小时的完全闲置将导致您的余额永远保持在最大值以下的某个位置。
我的testing脚本最终几乎完全耗尽了我的信用余额。 当我杀死CPU的进程时，信用余额立即开始恢复，预期每小时6个信用。
相反，当我使用一台已经使用了24小时不同的机器，并在几分钟内将CPU的使用率降至100％，然后将其重新设置为闲置状态，这些信用并没有立即开始累积。旧的，到期的。
行情来自http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html 。
