[EC2]CPU占用率窃取项是什么？

我是系统解决方案部门的中川。

之前某台服务器频繁出现 CPU 负载过高的情况，我调查后
发现这是由于 AWS 上 T2 系列 EC2 实例的特性造成的。这
正好是一个深入调查负载原因和特性的好机会。

top 命令的结果

top - 运行时间 01:41:32，已运行 13 分钟，1 个用户，平均负载：0.17、0.17、0.08。
任务总数：88 个，1 个正在运行，87 个处于睡眠状态，0 个已停止，0 个僵尸
进程。CPU 使用率：0.7% 用户，2.0% 系统，0.0% 空闲，93.8% 空闲，3.0% 等待，0.0% 高级，0.0% 静态，0.5% 静态。
内存：总计 1017372k，已用 184052k，可用 833320k，缓冲区 33848k。
交换空间：总计 1048572k，已用 52416k，可用 996156k，缓存 24688k。

看起来 Cpu(s): 行最右边的“st (steal)”项与此有关。

CPU窃取

由于我对这个术语并不熟悉，所以我查阅了相关资料，

发现它指的是
“向客户操作系统发出处理请求但未分配 CPU 资源的时间百分比” 提供多种实例类型，其中 T2 系列实例
具有一项功能，当使用量超过一定水平时，会限制性能（突发性能）。

CPU积分

在研究T2系列实例时，我遇到了另一个不熟悉的术语。
根据官方网站的代表每分钟一个CPU核心的性能”。

由于峰值CPU使用率会在所有分配的CPU额度用完时出现，因此
我认为这可以作为CPU使用率的粗略参考。
就CPU而言，我原以为可以获得与核心数成正比的处理能力，但
T2系列实例可能并非如此。

如何处理

既然我们已经了解了爆发式处理的含义及其发生的条件，那么我们该如何应对呢？
如果我们不改变处理量，则有三种可能的选择：

・重启实例

重启机器会重新分配 CPU 资源。
这只是一个临时解决方案，如果置之不理，最终会导致 CPU 过载。

・升级实例规格

增加 T2 实例大小，以增加分配的 CPU 积分数量。

・更改实例类型

T2 系列实例采用 CPU 积分制，这意味着它们无法处理核心数，因此
您可能需要考虑更换为固定性能实例（例如 M3 系列或 C3 系列）以确保稳定处理。

最后

EC2 经常被用作测试环境，因为从创建实例到启动实例的过程非常顺畅。

虽然我们一直在使用它，但
我们只在构建时指定实例类型时才关注它，或者调查 CPU、内存大小和其他实例的使用费差异。

在撰写这篇博客文章的过程中，我学到了很多关于性能方面的新知识，所以
我希望能够运用这些知识来帮助解决问题，并提高我在工作中的技能和知识。