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 实例仍然可以获得与实例大小允许的相同的最大级别.CPUCreditBalance 现在会在当前 CPUCreditUsage 低于基线时增加，并且可以增长到实例大小允许的最大值

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 中的更新.

原始答案如下.

在过去的几个小时里，这个问题让我感到相当痛苦，因为根据我对 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 积分最先使用，而不是最后使用.

顺序重要吗?确实如此.

Does order matter? It does.

为了测试，我使用了一个 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 只有一个内核，因此在 100% 的 CPU 利用率下，它们每分钟最多可以消耗 1 个积分或每小时消耗 60 个积分.t2.medium 和 t2.large 是双核，因此在两个内核的 CPU 利用率均为 100% 的情况下，它们每分钟最多可以消耗 2 个积分，或每小时消耗 120 个积分.

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 个积分也等于 1 个核心 5 分钟的 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

这完全符合您的预期，每 5 分钟消耗 1 个 CPU 积分.CPU Credit Usage"图表证实了这一点，显示每 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

粗暴.这可能有关系吗?这个小时，我获得了 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屋！