EC2 t2.medium突发信用“储蓄”计算 [英] EC2 t2.medium burstable credit "savings" calculation
问题描述
我正在使用T2.medium实例。一天的三分之一，我在进行大量的统计计算，并发现剩下的2/3的我将以每小时24小时的速度赚取信用。
I am using a T2.medium instance. A third of the day I am doing intensive statistical calculations and figured that the rest 2/3 of the time I would "earn" credits at a rate at 24 per hour.
但是那没有发生。这是最近两天的用法：
But that is not happening. This is my usage the last two days:
这是我的信用帐户：
我没有直到昨天下午6点才用了一天以上。我用了五个小时。然后，我希望我的帐户每小时累积24个学分，但是9-10个小时几乎没有任何反应，然后按预期的9个小时累积，然后又恢复稳定。
I hadn´t used it for (more than) a day until yesterday 6 pm. I use it intensive for five hours. Then I would expect my "account" to acummulate 24 credits per hour but for 9-10 hours almost nothing happens, then it acummulate as expected for 9 hours and then goes flat again.
我无法弄清楚发生了什么以及是否有故障。
I am unable to figure out what is going on and if it is a fault. Do anyone have a good explanation?
编辑：我在下面进行了一周的活动。我仍然无法弄清楚算法：
I have included a week of activity below. I still can´t figure out the algoritm:
推荐答案
更新：用于计算t2 CPU信用余额的规则似乎已更改，因此不再提示该问题的问题会产生影响。
Update: The rules used to calculate t2 CPU credit balances appear to have changed such that the issue prompting this question should no longer have an impact.
根据客户的反馈，我们使用新的CPU信用分配策略（与或相同）更新了T2实例在所有情况下都比以前的政策更好。
Based on customer feedback, we’ve updated T2 instances with a new CPU Credit allocation policy that is the same as or better than the previous policy in all cases.
...
现在，在实例终止或停止之前，获得的CPU积分不会过期。 T2实例仍可以赚取实例大小所允许的最高级别。现在，只要当前的CPUCreditUsage低于基线，CPUCreditBalance就会增加，并且可以增长到实例大小允许的最大值
Now, earned CPU Credits do not expire until the instance is terminated or stopped. A T2 instance can still earn up to the same maximum level allowed by the instance size. The CPUCreditBalance will now increase anytime the current CPUCreditUsage is below the baseline and can grow to the maximum allowed for the instance size
https://forums.aws.amazon.com/ann.jspa?annID=5196
h / t： AWS上周更新。
h/t: Last Week in AWS for the update.
原始答案如下。
此问题已引起在过去的几个小时中，我感到非常痛苦，因为根据我对t2实例的了解，这些图表几乎是有意义的。 差不多，但不是完全一样，我无法解决这个问题。那是最糟糕的一种。特别是t2机器所提供的价值主张的忠实拥护者。
This question has caused me quite a bit of mental anguish over the last few hours, because the graphs almost make sense, based on what I know about t2 instances. Almost, but not quite, and I couldn't put my finger on the problem. That's the worst kind. Particularly being a huge fan of the value proposition offered by t2 machines.
但是我终于弄清楚了这是怎么回事。
But I did finally figure out what's going on here.
文档中似乎没有解释CPU积分的一个概念，但是数学计算出来了，并且在现实世界的观察下，这种解释很好地成立了：
There's one concept of CPU credits the documentation doesn't seem to explain, but the math works out, and the explanation holds up nicely under real-world observations:
最近获得的CPU积分首先使用，而不是最后使用。
是否订购物？
为了进行测试，我使用了t2.micro（主要是因为我有一个闲置的设备已经运行了几天，并且需要做一些事情，并且我不希望新实例的额外初始功劳来掩盖观察结果），但是t2类中的所有实例类型都具有相似的行为。
For testing, I used a t2.micro (primarily because I had an idle one that had been running for several days, and needed something to do, and I didn't want the extra "initial" credits of a new instance to cloud up the observations) but all instance types in the t2 class have similar behavior.
背景：在t2类中，CPU信用以不同的速率获得，但是该类中所有实例类型的CPU信用以相同的速率使用：
By way of background: in the t2 class, CPU credits are earned at different rates, but CPU credits are used at the same rate for all instance types in the class:
CPU积分可在一分钟内提供完整CPU内核的性能。
A CPU Credit provides the performance of a full CPU core for one minute.
t2.micro和t2.small只有一个核心，因此每分钟最多可消耗1个信用点，每分钟可消耗60个信用点小时，CPU利用率为100％。 t2.medium和t2.large是双核的，因此它们每分钟可消耗多达2个学分，即每小时可消耗120个学分，两个内核上的CPU使用率均为100％。
The t2.micro and t2.small have only one core, so they can burn up to 1 credit per minute or 60 credits per hour, at 100% CPU utilization. The t2.medium and t2.large are dual core, so they can burn up to 2 credits per minute, or 120 credits per hour, at 100% CPU utilization on both cores.
如果1个信用= 1分钟的1个核心的100％，则1个信用也等于5分钟1个核心的20％。由于Cloudwatch图形间隔以5分钟为增量，因此我设置了以下测试：
If 1 credit = 100% of 1 core for 1 minute, then 1 credit is also equal to 20% of 1 core for 5 minutes. Since the Cloudwatch graph interval is in 5 minute increments, I set up the following test:
在已经运行了几周且几乎没有负载的t2.micro上，我安装了 lookbusy ，它是一种方便的实用程序，可让您使用自己的参数使计算机看上去很忙。指定-例如，保持CPU利用率为20％。
On a t2.micro that has been running for several weeks with essentially no load, I installed lookbusy, a handy utility that allows you to make a machine "look busy" with parameters you specify -- e.g, keep the CPU at 20% utilization.
$ screen -S eat_cpu
$ ./lookbusy -v -c 20 -r fixed
这完全符合您的期望，消耗1个CPU积分每5分钟一次。 CPU信用使用情况图对此进行确认，显示每5分钟使用1个信用。 （CPU使用率图和 top 都确认了20％。）
This does exactly what you'd expect, burning 1 CPU credit every 5 minutes. The "CPU Credit Usage" graph confirms this, showing 1 credit being used every 5 minutes. (The CPU Utilization graph, and top, both confirm the 20%.)
但是我的功劳是什么平衡？每5分钟就会消耗1点信用。这似乎是错误的，不是吗？我的意思是，是的，我只是说这是我正在使用的数量，但是...我也应该每小时赚6个学分，所以我应该只用净余额0.5个学分来消耗每5分钟，对吧？
But what's happening to my credit balance? It's being depleted by 1 credit every 5 minutes. That seems wrong, doesn't it? I mean, yes, I just said that's how many I'm using, but... I'm also supposed to be earning 6 credits per hour, so I should only be depleting by balance by a net of 0.5 credits every 5 minutes, right?
请稍等...再检查一次数字：我每小时收入6，每小时花费12，所以，是的...似乎每小时净减少仅6，而不是12 ...是吗？显然，有些事情并没有达到我的预期，因为我的余额肯定每小时下降12，而且我的CPU绝对只以20％的速度运行。
Hold on... checking the numbers, again: I'm earning 6 per hour, spending 12 per hour, so, yes... that seems like it should be a net decrease of only 6 per hour, not 12... right? Clearly, something doesn't add up the way I expected, because my balance is definitely going down by 12 per hour, and my CPU is definitely only running at 20%.
我似乎没有获得任何积分来抵消使用量。那怎么可能？
I seem to be earning no credits to offset my usage. How is that possible?
除非...
在给定的5分钟间隔内未使用的赚取积分过期后24小时过期
Unused earned credits from a given 5 minute interval expire 24 hours after they are earned
好吧，在24小时前，我的实例完全空闲了。在该小时内，我获得了6个未使用过的信用。我现在不使用它们吗？我不应该吗？
Well, 24 hours ago, my instance was completely idle. During that hour, I earned 6 credits that I... didn't (?) use. Am I not using them now? Shouldn't I be?
在添加任何新获得的积分之前，任何过期的积分都已从CPU积分余额中删除了
any expired credits are removed from the CPU credit balance at that time, before any newly earned credits are added
Crud。这可能有关吗？这个小时，我获得了6个新学分。但就在此之前，我从24小时前损失了6个学分。然后我这小时花了12个积分...所以我的余额减少了6点，增加了6点，然后又减少了12点。嗯，这可以解释每小时-12点的变化，但是...
Crud. Could this be related? This hour, I earned 6 new credits. But right before that, I lost 6 credits from 24 hours ago. Then I spent 12 credits this hour... so my balance when down by 6, up by 6, and down by another 12. Well, that explains the -12 change for the hour, but...
那是原因吗？
我是文档的狂热读者，所以我知道积分即将到期的情况……但是我一直认为这仅是闲着的原因实例徘徊在最大余额附近，没有其他意义。怎么可能如果我的数量少于最大值（t2.micro的最大数量为6 x 24 = 144），那么我怎么相信需要过期？
I'm a voracious reader of documentation, so I knew about the expiring credits aspect... but I assumed all along that this was nothing more than the reason an idle instance hovers near its maximum balance, and did not have any other significance. How could it? If I have less than the maximum (6 x 24 = 144 for a t2.micro) then how could I have credits the need to expire?
如果我24小时前的信用额始终对我不利，无论我做什么，我的余额都不会趋于零吗？
If my credits from 24 hours ago are always counting against me, wouldn't my balance tend toward zero, regardless of what I do?
除非...
在整夜抛掷并转向后，同时考虑在假想的令牌（代表CPU积分）周围滑动虚构的桌面（代表时间）...我意识到，如果以违反直觉的方式不按信用额度消费信用，过期规则将完全导致我们观察到的行为（FIFO），而是相反的顺序（LIFO）。
After tossing and turning most of the night while contemplating sliding around piles of imaginary tokens (representing CPU credits) on an imaginary table top (representing time)... I realized that the "expiration" rule would cause exactly the behavior we observe if, counter-intuitively, credits are not spent in the order in which they are earned (FIFO), but rather in the reverse order (LIFO).
按照上述推理，对我的20％CPU测试实际所做的解释是，测试的第一个小时为小时0-
Following that line of reasoning, the explanation for what my 20% CPU test is actually doing is this, where the first hour of my test was "hour 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
他们在中间相遇。
这是货真价实吗？我没猜到，这是证据：
Is this genuine, or am I guessing? I'm not guessing, and here's the evidence:
8小时后，我的CPU信用使用情况图表仍然稳定，仍保持每5分钟1信用，但是在相同的8个小时内，我的CPU信用余额最终开始以我最初期望的（较慢）速率耗尽：每5分钟0.5信用。
After 8 hours, my CPU credit usage graph remains solid, still holding steady at 1 credit per 5 minutes, but after the same 8 hours, my CPU credit balance finally begins to deplete at the (slower) rate I originally expected: 0.5 credits every 5 minutes.
显然，随着时间的推移，我以前消费的信用额度最新第一，我赶上了即将到期的旧信用额度，终于到了在它们有机会过期之前我在哪里使用它们。现在，我没有24小时的学分，因此也没有学分到期-因此，在获得新学分之前，我不再失去学分。现在我可以保持每小时6的收入，因为我用尽了旧的收入，将对信贷余额的净影响降低到了预期水平。
Apparently, as I worked backward in time, spending previously earned credits "newest first," I caught up with my old credits that were about to expire, finally reaching the point where I was using them before they had a chance to expire. Now, I have no credits that are 24 hours old, and so no credits are expiring -- so I am no longer losing credits before new credits are earned. I am now able to keep the 6 that I earn per hour, because I used up the old ones, decreasing the net impact to my credit balance to the expected level.
这解释了我对问题图表的唯一保留：为什么利用率下降时，余额反弹需要这么长时间？
This explains the only reservation I had about the graphs in the question: why, when utilization drops off, does it take so long for the balance to rebound?
> TL; DR 的答案是：在大量使用之后，余额不会立即反弹，因为从24小时之前您仍然有未使用的信用，这些信用会取消您新赚的信用，直到您达到您没有任何24小时未使用信用的时间点。发生这种情况时，您的信用余额会再次增加。
The TL;DR answer is this: the balance doesn't rebound immediately, after a burst of heavy utilization, because you still have unused credits from 24 hours prior, which are canceling out your newly-earned credits, until you reach the point in time when you don't have any 24-hour-old unused credits. When that happens, your credit balance increases again.
将实例完全闲置24小时，最终您将看到稳定的平衡（大部分情况下）再次达到预期的最大值。少于24小时的完全闲置时间将导致您的余额永久保持在最高限额以下。
Leave the instance completely idle for 24 hours and you will eventually see the balance steadily (for the most part) rise to the maximum again, as expected. Anything less than 24 hours completely idle will cause your balance to remain perpetually be somewhere below the max.
我的测试脚本最终几乎耗尽了我的信用余额。当我杀死吃掉CPU的进程时，信用余额开始立即恢复，以每小时6个信用的预期速度恢复。
My test script eventually depleted my credit balance almost all the way down. When I killed the process eating the CPU, the credit balance began to recover immediately, at the expected rate of 6 credits per hour.
相反，当我使用另一台在24小时内发现利用率低的机器并将其CPU运行至100％几分钟后，又将其恢复为空闲状态，抵免额并没有立即开始累积...已被过期的过期抵销额。
Conversely, when I took a different machine that had seen low utilization for 24 hours, and ran it's CPU to 100% for a few minutes, then took it back to idle, the credits did not begin to accumulate immedately... being offset by old, expiring ones.
行情来自 http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html 。
这篇关于EC2 t2.medium突发信用“储蓄”计算的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
