标准模式示例 - Amazon Elastic Compute Cloud
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

标准模式示例

以下示例介绍当实例配置为 standard 时的积分使用情况。

示例 1:介绍 T3 标准版的积分使用情况

在本示例中,您将了解作为 t3.nano 启动的 standard 实例如何获得、累积和使用获得 的积分。您可以看到积分余额如何反映累积的获得 的积分。

运行的 t3.nano 实例每 24 小时获得 144 积分。其积分余额限制为 144 个获得的积分。达到该限制后,将丢弃获得的任何新积分。有关可获得和可累积的积分数的更多信息,请参阅积分表

您可启动 T3 标准实例并立即使用它。或者,您可能在启动 T3 标准实例后让其闲置几天,再在该实例上运行应用程序。实例是正在被使用还是闲置决定积分是消耗还是累积。如果实例从启动时开始保持闲置状态 24 小时,则积分余额将达到其限制,这是可以累积的获得积分的最大数目。

本示例介绍启动后闲置 24 小时的实例,并向您分析 96 小时内共 7 个时段的积分情况,演示获得、累积、使用和丢弃积分的速率以及每个时段结束时的积分余额值。

以下工作流程引用图中的编号数据点:

P1 – 在图表中的 0 小时处,实例以 standard 模式启动并立即开始获得积分。实例自启动后保持闲置状态(CPU 利用率为 0%),不使用任何积分。所有未使用的积分都累积到积分余额中。对于前 24 小时,CPUCreditUsage 为 0,而 CPUCreditBalance 值达到其最大值 144。

P2 – 对于接下来的 12 小时,CPU 利用率为 2.5%,这低于 5% 基准。实例获得的积分多于花费的积分,但 CPUCreditBalance 值不能超过其最大值 144 积分。所获得的超过限制的所有积分都会被丢弃。

P3 – 对于接下来的 24 小时,CPU 利用率为 7%(高于基准),这要求花费 57.6 积分。实例花费的积分多于获得的积分,CPUCreditBalance 值降至 86.4 积分。

P4 – 对于接下来的 12 小时,CPU 利用率降至 2.5%(低于基准),这要求花费 36 积分。同时,实例获得 72 积分。实例获得的积分多于花费的积分,CPUCreditBalance 值增至 122 积分。

P5 – 对于接下来的两个小时,实例突增至 60% CPU 利用率,并耗尽其整个 CPUCreditBalance 值的 122 积分。在此期间结束时,CPUCreditBalance 为零,CPU 利用率会被强制降低到基准利用率级别 5%。在基准时,实例获得的积分与花费的积分一样多。

P6 – 对于接下来的 14 小时,CPU 利用率为 5%(基准)。实例获得的积分与花费的积分一样多。CPUCreditBalance 值保持为 0。

P7 – 对于本例中的最后 24 小时,实例空闲,CPU 利用率为 0%。在此期间,实例获得 144 积分,这些积分将累积到其 CPUCreditBalance 中。


                  T3 标准实例 CPU 使用率。

示例 2:介绍 T2 标准版的积分使用情况

在本示例中,您将了解作为 t2.nano 启动的 standard 实例如何获得、累积和使用启动积分获得的积分。您还可以了解积分余额如何反映累积获得的积分和累积启动积分

启动时,t2.nano 实例获得 30 启动积分,之后每 24 小时获得 72 积分。其积分余额限制是获得的 72 积分;启动积分不计入该限制。达到该限制后,将丢弃获得的任何新积分。有关可获得和可累积的积分数的更多信息,请参阅积分表。有关 限制的更多信息,请参阅 启动积分限制

您可启动 T2 标准实例并立即使用它。或者,您可能在启动 T2 标准实例后让其闲置几天,再在该实例上运行应用程序。实例是正在被使用还是闲置决定积分是消耗还是累积。如果实例自启动后闲置 24 小时,积分余额将超过其限制,因为积分余额同时反映累积获得的积分和累积启动积分。不过,使用 CPU 后,会先使用启动积分。此后,积分余额限制始终反映可累积获得的最大积分。

本示例介绍启动后闲置 24 小时的实例,并向您分析 96 小时内共 7 个时段的积分情况,演示获得、累积、使用和丢弃积分的速率以及每个时段结束时的积分余额值。

第 1 个时段:1 – 24 小时

在图上的第 0 小时,T2 实例作为 standard 启动并立即获得 30 启动积分。当它处于运行状态时,会获得积分。实例自启动后保持闲置状态(CPU 利用率为 0%),不使用任何积分。所有未使用的积分都累积到积分余额中。在启动后大约 14 小时,积分余额为 72 (30 启动积分 + 获得的 42 积分),这与实例在 24 小时内获得的积分相同。在启动后 24 小时,积分余额超过 72,因为未使用的启动积分累积到了积分余额中 (积分余额为 —102 积分:30 启动积分 + 72 获得积分)。


                     在 T2 标准的第 1 个时段中,积分余额为 102 积分。
积分使用率 每 24 小时 0 积分 (0% CPU 利用率)
积分获得率 每 24 小时 72 积分
积分丢弃率 每 24 小时 0 积分
积分余额

102 积分 (30 启动积分 + 获得的 72 积分)

结论

如果启动后没有 CPU 利用率,实例累积的积分将超过其在 24 小时内获得的积分 (30 启动积分 + 获得的 72 积分 = 102 积分)。

在真实场景中,EC2 实例在启动和运行时会使用少量积分,以防止积分余额达到本实例中的最大理论值。

第 2 个时段:25 – 36 小时

在接下来 12 小时,实例继续保持闲置状态并获得积分,但积分余额不会增加。积分余额保持在 102 (30 启动积分 + 获得的 72 积分)。积分余额已达到 72 累积获得的积分限制,因此会丢弃新获得的积分。


                  积分余额已达到 72 个累积获得的积分限制。
积分使用率 每 24 小时 0 积分 (0% CPU 利用率)
积分获得率 每 24 小时 72 积分 (每小时 3 积分)
积分丢弃率 每 24 小时 72 积分 (100% 积分获得率)
积分余额

102 积分 (30 启动积分 + 72 获得积分) — 余额保持不变

结论

如果积分余额已达到其限制,实例会继续获得积分,但不会累积更多获得的积分。达到该限制后,会丢弃新获得的积分。启动积分不计入 积分余额限制。如果余额包含累积的启动积分,余额将超过该限制。

第 3 个时段:37 – 61 小时

在接下来 25 小时,实例使用 2% CPU,需要 30 积分。在同一周期,它获得 75 积分,但积分余额减少。余额减少的原因是先使用累积的启动 积分,并且由于积分余额已达到其获得的 72 积分限制,因此丢弃了新获得的积分。


                     由于积分余额已达到其限制,因此会丢弃新获得的积分。
积分使用率 24 小时 28.8 积分 (每小时 1.2 积分,2% CPU 利用率,40% 积分获得率) — 25 小时 30 积分
积分获得率 每 24 小时 72 积分
积分丢弃率 每 24 小时 72 积分 (100% 积分获得率)
积分余额

72 积分 (使用了 30 启动积分;剩余获得的 72 积分未使用)

结论

实例先使用启动积分,再使用获得的积分。启动积分不计入积分限制。使用启动积分后,积分余额永远不会超过在 24 小时内可获得的积分。此外,实例运行时,不会获得更多启动积分。

第 4 个时段:62 – 72 小时

在接下来 11 小时,实例使用 2% CPU,需要 13.2 积分。这与上一周期的 CPU 利用率相同,但积分余额不会减少。它保持在 72 积分。

积分余额不减少的原因是积分获得率高于积分使用率。实例使用 13.2 积分的同时,获得 33 积分。不过,由于余额限制是 72 积分,因此会丢弃获得的超过该限制的任何积分。积分余额保持在 72 积分,这与第 2 个时段保持在 102 积分不同,因为没有累积的启动积分。


                  由于没有累积的启动积分,因而积分余额保持在 72 积分。
积分使用率 24 小时 28.8 积分 (每小时 1.2 积分,2% CPU 利用率,40% 积分获得率) — 11 小时 13.2 积分
积分获得率 每 24 小时 72 积分
积分丢弃率 每 24 小时 43.2 积分 (60% 积分获得率)
积分余额

72 积分 (0 启动积分,获得的 72 积分) — 余额达到其限制

结论

使用启动积分后,积分余额限制由实例在 24 小时内可获得的积分数决定。如果实例获得的积分多于使用的积分,则会丢弃新获得的超过限制的积分。

第 5 个时段:73 – 75 小时

在接下来 3 小时,实例的 CPU 利用率激增至 20%,需要 36 积分。在相同的 3 小时内,实例获得 9 积分,导致净余额减少 27 积分。在这 3 小时结束时,积分余额为累积获得的 45 积分。


                  在这 3 小时结束时,积分余额为累积获得的 45 积分。
积分使用率 24 小时 288 积分 (每小时 12 积分,20% CPU 利用率,400% 积分获得率) — 3 小时 36 积分
积分获得率 每 24 小时 72 积分 (3 小时 9 积分)
积分丢弃率 每 24 小时 0 积分
积分余额

45 积分 (以前的余额 (72) - 使用的积分 (36) + 获得的积分 (9)) — 余额按每 24 小时 216 积分的速率减少 (使用率 288/24 + 获得率 72/24 = 余额减少率 216/24)

结论

如果实例使用的积分多于获得的积分,则其积分余额将减少。

第 6 个时段:76 – 90 小时

在接下来 15 小时,实例使用 2% CPU,需要 18 积分。这与第 3 个和第 4 个时段的 CPU 利用率相同。不过,此周期的积分余额增加,而第 3 个时段的积分余额减少,第 4 个时段的保持不变。

在第 3 个时段,使用累积的启动积分,并会丢弃获得的超过积分限制的任何积分,导致积分余额减少。在第 4 个时段,实例发挥的积分数少于其获得的积分数。所获得的任何超出限制的积分将丢弃,因此余额保持在其最大值 72 积分。

在本周期,没有累积的启动积分,余额中累积获得的积分数低于限制。不会丢弃获得的任何积分。此外,实例获得的积分多于使用的积分,导致积分余额增加。


                  实例获得的积分多于花费的积分。
积分使用率 24 小时 28.8 积分 (每小时 1.2 积分,2% CPU 利用率,40% 积分获得率) — 15 小时 18 积分
积分获得率 每 24 小时 72 积分 (15 小时 45 积分)
积分丢弃率 每 24 小时 0 积分
积分余额

72 积分 (余额按每 24 小时 43.2 积分的速率增加 — 更改率 = 使用率 28.8/24 + 获得率 72/24)

结论

如果实例使用的积分少于获得的积分,则其积分余额将增加。

第 7 个时段:91 – 96 小时

在接下来六小时,实例保持闲置状态—(CPU 利用率为 0%),—不使用任何积分。这与第 2 个时段的 CPU 利用率相同,但积分余额不保持在 102 积分,而保持在 72 积分,—这是实例的积分余额限制。

在第 2 个时段,积分余额中包含累积的 30 启动积分。启动积分在第 3 个时段使用。正在运行的实例无法获得更多启动积分。达到积分余额限制后,会丢弃获得的超过限制的任何积分。


                     所获得的超过限制的积分会被丢弃。
积分使用率 每 24 小时 0 积分 (0% CPU 利用率)
积分获得率 每 24 小时 72 积分
积分丢弃率 每 24 小时 72 积分 (100% 积分获得率)
积分余额

72 积分 (0 启动积分,获得的 72 积分)

结论

如果已达到积分余额限制,实例会继续获得积分,但不会累积更多获得的积分。达到该限制后,会丢弃新获得的积分。积分余额限制由实例在 24 小时内可获得的积分数决定。有关积分余额限制的更多信息,请参阅积分表