如何用 AWS CLI 判断 T 系列实例 CPU 不够(实战指南)

在使用 AWS EC2 T 系列实例(如 t4g / t3)时,经常会遇到:

  • CPU 使用率很高

  • load 很高(> CPU 核数)

  • PostgreSQL / 应用变慢

  • 但又不确定是不是 CPU 不够

本文通过 AWS CLI + 系统指标,教你如何一步步证明:

👉 你的 CPU 不够(而且是被 CPU Credit 限制)

有个比较简单的方法

这里一直是0的话,说明额度一直是空的,也就是一直被消耗

可以是额度正好被消耗完,也可以是消耗 > 额度


一、T 系列 CPU 的本质(必须理解)

以 t4g.2xlarge 为例:

复制代码
8 vCPU,但 baseline 只有 40%

换算:

复制代码
8 × 40% = 3.2 vCPU(长期可用)

👉 也就是说:

这台 8核机器,长期性能 ≈ 3.2核


二、核心指标 1:CPUCreditBalance(最关键)

查询命令

复制代码
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUCreditBalance \
  --dimensions Name=InstanceId,Value=你的实例ID \
  --statistics Average \
  --period 60 \
  --start-time 2026-04-22T00:00:00Z \
  --end-time 2026-04-22T23:59:59Z

如何判断

数值 含义
> 100 CPU 有余量
持续下降 正在透支 CPU
≈ 0 ❗ CPU 已被限制

本次优化查询的数据

bash 复制代码
{
    "Label": "CPUCreditBalance",
    "Datapoints": [
        {
            "Timestamp": "2026-04-22T00:55:00+00:00",
            "Average": 0.0,
            "Unit": "Count"
        },
        {
            "Timestamp": "2026-04-22T16:50:00+00:00",
            "Average": 0.0,
            "Unit": "Count"
        },
        {
            "Timestamp": "2026-04-22T02:40:00+00:00",
            "Average": 0.0,
            "Unit": "Count"
        },
        {
            "Timestamp": "2026-04-22T18:35:00+00:00",
            "Average": 0.0,
            "Unit": "Count"
        },
        {
            "Timestamp": "2026-04-22T02:05:00+00:00",
            "Average": 0.0,
            "Unit": "Count"
        },
        {
            "Timestamp": "2026-04-22T20:20:00+00:00",
            "Average": 0.0,
            "Unit": "Count"
        },
        {
            "Timestamp": "2026-04-22T03:50:00+00:00",
            "Average": 0.0,
            "Unit": "Count"
        },
.........

关键结论

复制代码
CPUCreditBalance = 0

👉 表示:

CPU 已经不能再 burst,只能用 baseline(≈3.2核)


三、核心指标 2:CPUCreditUsage(算出真实 CPU 需求)

查询命令

复制代码
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUCreditUsage \
  --dimensions Name=InstanceId,Value=你的实例ID \
  --statistics Sum \
  --period 300 \
  --start-time 2026-04-22T00:00:00Z \
  --end-time 2026-04-22T23:59:59Z

如何计算真实 CPU

这个指标是:

复制代码
5分钟内消耗的 CPU credit

换算公式:

复制代码
CPU核数 ≈ credit / 5

示例

bash 复制代码
{
    "Label": "CPUCreditUsage",
    "Datapoints": [
        {
            "Timestamp": "2026-04-22T00:55:00+00:00",
            "Sum": 30.0007428,
            "Unit": "Count"
        },
        {
            "Timestamp": "2026-04-22T16:50:00+00:00",
            "Sum": 33.16712308333334,
            "Unit": "Count"
        },
        {
            "Timestamp": "2026-04-22T02:40:00+00:00",
            "Sum": 26.27567871666667,
            "Unit": "Count"
        },
        {
            "Timestamp": "2026-04-22T18:35:00+00:00",
            "Sum": 35.062843916666665,
            "Unit": "Count"
        },
        {
            "Timestamp": "2026-04-22T02:05:00+00:00",
            "Sum": 33.40315138333333,
            "Unit": "Count"
        },
        {
            "Timestamp": "2026-04-22T20:20:00+00:00",
            "Sum": 35.161372566666664,
            "Unit": "Count"
        },
        {
            "Timestamp": "2026-04-22T03:50:00+00:00",
            "Sum": 17.962388716666666,
            "Unit": "Count"
        },
........

如果看到:

复制代码
30 credit / 5分钟

那么:

复制代码
30 / 5 = 6 CPU

👉 说明:

业务需要 6 个真实 CPU


对比 baseline

复制代码
t4g.2xlarge baseline = 3.2 CPU
实际需求 ≈ 6 CPU

👉 差距:

复制代码
6 - 3.2 = 2.8 CPU(不足)

四、辅助指标 3:CPUUtilization(确认 CPU 打满)

查询命令

复制代码
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=你的实例ID \
  --statistics Average Maximum \
  --period 60 \
  --start-time 2026-04-22T00:00:00Z \
  --end-time 2026-04-22T23:59:59Z

判断

复制代码
Average > 80%
Maximum ≈ 100%

👉 表示:

CPU 已经被打满


五、可选指标(Unlimited 模式)

如果你的实例是 Unlimited 模式,可以查:


1. 超额 CPU(欠债)

复制代码
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUSurplusCreditBalance \
  --dimensions Name=InstanceId,Value=你的实例ID \
  --statistics Average \
  --period 300 \
  --start-time 2026-04-22T00:00:00Z \
  --end-time 2026-04-22T23:59:59Z

2. 被收费的超额 CPU

复制代码
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUSurplusCreditsCharged \
  --dimensions Name=InstanceId,Value=你的实例ID \
  --statistics Sum \
  --period 300 \
  --start-time 2026-04-22T00:00:00Z \
  --end-time 2026-04-22T23:59:59Z

六、系统层面验证(强烈建议)

1. vmstat

复制代码
vmstat 1

重点看:

复制代码
r = 等 CPU 的进程数

判断

如果:

复制代码
r > CPU核数

👉 CPU 不够


2. top

复制代码
top

看:

复制代码
id ≈ 0
load > CPU核数

👉 CPU 已经满载 + 排队


七、最终判断公式(核心总结)

如果你看到:

复制代码
CPUCreditBalance = 0
+ CPUCreditUsage 很高
+ CPUUtilization ≈ 100%
+ vmstat r > vCPU
+ load > vCPU

👉 可以 100% 确认:

CPU 不够(而且是被 T 系列 credit 限制)


八、结论与建议

当前问题本质

复制代码
不是机器太弱
而是 T 系列 CPU 被限速

推荐方案

场景 推荐实例
通用 m6g / m7g
数据库(推荐) r6g / r7g

一句话总结

T 系列不是"低配机器",而是"限速机器",CPU credit 用完后性能会骤降。


相关推荐
Easy_API8 小时前
2.8万亿参数,编程反超GPT-6 Astra:Kimi K3.1 Pro把开源模型推到了哪一步
大数据·人工智能·gpt·深度学习
GlobalInfo8 小时前
2026年机器人多指灵巧手市场分析报告——涵盖行业调查、趋势分析与发展前景
大数据·人工智能·microsoft·微服务·机器人
微订校园外卖平台9 小时前
校园外卖平台选模板还是定制:架构、数据流与验收清单
大数据·架构·外卖系统·本地生活·微订
Eloudy11 小时前
Qwen2.5-14B-Instruct-AWQ 模型文件结构分析
大数据·elasticsearch·搜索引擎
重生之高冷汉堡包13 小时前
跨境电商运营团队如何安全交接店铺账号?多账号权限管理指南
大数据
玩AI的奶茶14 小时前
MiniMax H3 出 30 秒长片:显存账、拼接法和一次的成本
大数据·人工智能·ai·gpu算力·算力租赁
SelectDB14 小时前
Doris Arrow Flight SQL 高速读取协议实战:与 Snowflake 客户端取数链路对照
大数据·数据库·数据分析
爱签AI电子合同15 小时前
电子合同全维度实测与选型指南
大数据·人工智能
AI办公探索者15 小时前
从SaaS到本地部署:大模型推理成本优化与8888元私有化方案的技术解析
大数据·人工智能
做运维的阿瑞15 小时前
云项目可观测性与成本治理:告警、日志、Dashboard 与预算标签
大数据·云原生·云计算·terraform