t3.micro属于AWS EC2的突发性能型（Burstable Performance）实例家族，定价便宜，常被用作入门学习、个人博客或轻量级服务的首选。它的标称配置是2个vCPU和1GB内存，但和传统固定性能实例不同，t3系列的CPU性能与积分机制直接挂钩，短时间爆发和长时间高负载的表现差异很大。本文将围绕t3.micro实例展开CPU与内存两方面的基准测试，用真实数据说话，并解释积分机制对测试结果的影响。
测试环境与工具准备
本次测试使用的系统镜像是Amazon Linux 2023，区域选择ap-northeast-1（东京），实例类型为t3.micro。测试前先通过yum安装必要的编译工具和测试软件：
sudo yum update -y sudo yum install -y sysbench gcc gcc-c++ make git # 查看CPU信息 lscpu | grep -E "Model name|CPU\(s\)|MHz"
从lscpu的输出可以看到，t3.micro底层使用的是Intel Xeon Platinum 8259CL处理器，主频2.5GHz，睿频可达3.1GHz。这个级别的CPU在物理规格上并不弱，问题在于突发积分机制是否允许它持续输出。因此测试分两个场景进行：一是刚启动时积分充足的状态，二是积分耗尽后的限速状态，两者对比才能反映真实性能。
内存方面，t3.micro配备了1GB物理内存，操作系统识别约990MB可用。测试工具选用sysbench内置的memory测试模块，它可以灵活调整块大小和读写模式，覆盖顺序与随机两种访问模式。另外还准备了云监控指标CloudWatch中的CPUCreditBalance数据用于交叉验证积分变化。
CPU性能实测：sysbench压测结果
第一个测试是纯CPU计算能力，使用sysbench的cpu模块，素数上限设为20000，分别测单线程和双线程：
# 单线程测试 sysbench cpu --cpu-max-prime=20000 --threads=1 run # 双线程测试 sysbench cpu --cpu-max-prime=20000 --threads=2 run
在积分充足的状态下，单线程每秒可完成约1850次事件，双线程约为3600次，接近线性扩展，说明两个vCPU在爆发状态下确实能提供接近完整核心的性能。这个成绩与固定性能的m5.large（2 vCPU）相比差距只有15%左右，对轻量任务来说完全够用。
但连续运行十分钟后情况就变了。t3.micro的基础积分获取速率约为每小时12个积分，而每个vCPU满载运行一分钟消耗1个积分。也就是说，两个vCPU同时满载，每分钟消耗2个积分，账户里默认的30个初始积分很快见底。积分耗尽后，CPU会被限制在约10%的基准性能上，sysbench的事件速率直接从3600次每秒跌到380次左右，降幅接近90%。这也是很多新手在跑压测时发现性能突然断崖式下跌的根本原因，不是机器坏了，而是积分机制在起作用。
如果业务确实需要长时间高CPU占用，可以考虑开启无限模式（Unlimited Mode），超出积分的部分按vCPU分钟计费，价格大约是实例单价的1.5倍，用完后账单会明显上涨，需要谨慎评估。或者直接换用t3.small、m5.large这类基准性能更高的型号更划算。
内存带宽与延迟测试
内存测试使用sysbench的memory模块，分别测试1KB小块的随机读写和1MB大块的顺序读写：
# 小块随机读，模拟大量小对象访问 sysbench memory --memory-block-size=1K --memory-total-size=10G \ --memory-access-mode=rnd run # 大块顺序写，模拟文件缓存场景 sysbench memory --memory-block-size=1M --memory-total-size=10G \ --memory-oper=write --memory-access-mode=seq run
实测1MB顺序写带宽约4.2GB/s，1KB随机读折算后约1.8GB/s。这个数字对于物理服务器来说不算亮眼，但在虚拟化环境中属于正常水平，且内存性能不受积分机制影响，是t3.micro相对稳定的部分。也就是说，如果你的应用是内存密集型而非CPU密集型，t3.micro的表现会比CPU压测结果看起来更可靠。
需要特别注意的是1GB总容量这个硬约束。测试中启动一个Java应用就会消耗400MB以上内存，再加上系统本身占用约200MB，剩余空间非常紧张。当内存不足触发swap时，t3.micro默认没有交换分区，内核的OOM Killer会直接杀掉占用内存最多的进程。生产环境建议安装earlyoom或配置合理的cgroup内存限制，避免关键进程被误杀。
典型使用场景与选型建议
综合测试结果来看，t3.micro适合的场景包括：个人博客或静态站点（配合Nginx，CPU占用通常低于5%）、开发测试环境、轻量的定时任务脚本、以及作为学习AWS的入门实例。这些场景的共同特点是CPU平均负载低，只在偶发峰值时需要爆发性能，正好契合积分机制的设计初衷。
不适合的场景同样明确：持续高负载的API服务、数据库主节点、视频转码等计算密集型任务。以MySQL为例，1GB内存分配给InnoDB缓冲池后所剩无几，稍微复杂一点的查询就容易触发磁盘IO，性能体验很差。这类需求至少要选择t3.small（2GB内存）起步，数据库类服务更推荐内存型的r系列。
日常运维中，建议持续关注CloudWatch中的CPUCreditBalance和CPUSurplusCreditCharged两个指标。前者低于20时说明积分即将耗尽，后者大于0说明已经产生了超积分费用。也可以在实例内部用如下命令快速查看当前CPU频率是否被降频：
cat /proc/cpuinfo | grep MHz # 配合CloudWatch CLI查询积分余额 aws cloudwatch get-metric-statistics \ --namespace AWS/EC2 --metric-name CPUCreditBalance \ --dimensions Name=InstanceId,Value=i-0abcd1234 \ --start-time 2024-01-01T00:00:00Z \ --end-time 2024-01-02T00:00:00Z \ --period 3600 --statistics Average
总结来说，t3.micro是一台爆发能力强、持续能力弱的实例。理解积分机制后再使用它，你会发现这台每月几美元的小机器其实性价比很高；反之，把它当成固定性能机器来压榨，大概率会遭遇性能悬崖和意外账单。选择实例类型时，先评估业务的CPU平均负载和内存容量需求，再决定是继续用t3系列还是升级到固定性能系列，这才是正确的打开方式。