汤不热吧许多个人站长在选择公有云的入门级VPS或虚拟机时，会遇到所谓的“突发型实例”或“共享型实例”（例如阿里云的T5/T6系列，AWS的T系列）。这些实例通常价格低廉，但它们在CPU使用上有一套特殊的机制——CPU信用积分（CPU Credit）。用户担心，如果一个1核心的突发型实例一直跑满100%的CPU，是否会被云服务商停机？
核心答案：通常不会被“停机”，但会被“限速”（Throttling），使其性能大幅下降，导致网站或应用响应缓慢到无法使用。
1. 突发型实例的CPU积分机制
突发型实例的设计哲学是：适用于那些平均负载很低，但偶尔需要快速处理突发流量的场景（如小型博客、开发测试环境）。
积分如何运作？
- 积累（Earning）: 实例在运行过程中，只要CPU实际利用率低于其设定的“基准线”（Baseline），它就会持续积累CPU积分。例如，一个1核实例的基准线可能是10%。当它只用了5%时，剩余的5%就以积分形式存储起来。
- 消耗（Spending）: 当CPU利用率超过基准线（例如，达到100%）时，实例就开始快速消耗积累的积分。
- 限速（Throttling）: 一旦实例的CPU积分余额耗尽（降到0），实例的CPU性能将被强制限制在基准线水平（例如，持续保持在10%）。此时，尽管你看到的是100%的负载，但实际的计算能力被限制住了。
这意味着，如果你长期让一个突发型实例跑满100%，它会在短时间内耗尽所有积分，随后进入长期限速状态。
2. 如何判断和模拟CPU积分耗尽
了解实例是否因积分耗尽而被限制，最直接的方法是登录云服务商的控制台，查看实例的监控指标，尤其是“CPU信用积分余额”（CPU Credit Balance）和“CPU信用消耗”（CPU Credit Usage）。
在Linux系统上，我们可以通过压力测试工具来模拟积分快速消耗的过程：
步骤一：安装压力测试工具
我们使用 stress-ng 来对单核心进行持续压力测试。
# 适用于 Debian/Ubuntu 系统
sudo apt update
sudo apt install -y stress-ng
# 适用于 CentOS/RHEL 系统
sudo yum install -y epel-release
sudo yum install -y stress-ng
步骤二：运行持续高负载测试
运行以下命令，让一个核心持续跑满100%（持续5分钟）。
# --cpu 1 表示使用一个核心
# --timeout 300s 表示运行300秒（5分钟）
stress-ng --cpu 1 --cpu-method matrixprod --timeout 300s
在测试运行期间，你可以在另一个终端使用 top 或 htop 命令观察CPU利用率。如果你的突发型实例积分充足，你会看到持续的100%利用率。一旦积分耗尽（这可能需要几小时或几天，取决于云服务商初始赠送的积分），实例的实际性能就会骤降。
步骤三：观察性能下降
如果你运行了长时间的压力测试，当积分降为零后，你会发现尽管系统负载（Load Average）依然很高（例如达到1.0+），但是应用程序的运行速度会变得极其缓慢，因为CPU的实际运行频率和时间片已被限制在基准线（如10%）。
3. 建议与解决方案
如果你的应用需要长期持续的高CPU性能，突发型实例是不适合的，你应该考虑以下解决方案：
- 升级到固定性能实例（Dedicated Instance）： 选择云服务商提供的标准型、计算型或内存型实例。这些实例保证了你所购买的vCPU是专用的，没有CPU积分限制。
- 选择无限突发模式（T-Unlimited）： 部分云服务商（如AWS）提供了“无限突发”模式。在这种模式下，即使你积分耗尽，也可以继续以高于基准线的性能运行，但超额的部分会按需计费。这解决了性能限制问题，但需注意账单风险。
- 优化应用： 找出导致CPU持续高负载的原因。例如，优化数据库查询、使用缓存机制或调整定时任务的执行频率，确保实例的大部分时间处于基准线以下运行，以积累足够的积分。