一台只有 1 GiB 内存的云主机，在标准 UnixBench 测试里能交出什么样的成绩？AWS t3.micro 是很多轻量部署的首选，但它的突发性能积分机制经常让跑分结果出现波动。本文在 Amazon Linux 2023 上完整安装并运行 UnixBench 5.1.3，记录单项分数与总分数，同时说明积分机制、磁盘类型对最终结果的影响。
测试环境与实例规格
本次测试使用 AWS 东京区域的一台全新 t3.micro 实例。该实例配置为 2 个 vCPU、1 GiB 内存，系统盘为 20 GB 通用型 SSD gp3，预装 Amazon Linux 2023。t3.micro 属于突发性能实例，CPU 型号通常为 Intel Xeon Platinum 8000 系列，基础频率约 2.5 GHz，支持睿频。它与固定性能实例不同，CPU 能力通过积分进行调节，短时间高负载可以跑出不错成绩，但持续满载会面临积分耗尽后的限速。
测试前确认系统已更新到最新内核和补丁，关闭可能干扰结果的自动更新服务。为了避免磁盘成为瓶颈，额外挂载了一块 50 GB gp3 数据盘，并设置 3000 IOPS，用于部分文件复制测试项。内存虽然只有 1 GiB，但 UnixBench 默认测试规模较小，不会触发 OOM。所有测试均在标准网络环境下执行，未使用竞价实例或专用宿主机。
UnixBench 的分数受编译器、glibc 版本、内核版本和运行时长影响较大。同一实例在不同时间段也可能出现个位数百分比波动，因此本文给出的分数是连续三次运行后的中位值，且每次运行之间等待 60 秒让 CPU 积分回落。
UnixBench 安装与执行命令
UnixBench 最早源自 Byte 杂志的 BYTE UNIX Benchmarks，现在常用的开源版本是 byte-unixbench。Amazon Linux 2023 默认不包含该工具，需要从源码编译。安装依赖的命令如下：
sudo dnf update -y sudo dnf install -y gcc make perl git automake git clone https://github.com/kdlucas/byte-unixbench.git cd byte-unixbench/UnixBench make
编译完成后，在 UnixBench 目录下执行单核测试和多核测试。单核测试通过限制 CPU 数量来实现，多核测试默认使用全部可用 vCPU。
./Run -c 1 -c 2 ./Run -c 2
第一条命令会依次运行单核与多核测试，第二条命令单独跑多核。实际测试中，单核分数对应一个 vCPU 的峰值能力，多核分数则反映两个 vCPU 同时并行的水平。运行一次完整测试大约需要 10 到 15 分钟，其中包括 Dhrystone 整数运算、Whetstone 浮点运算、Execl 进程替换、文件复制、管道吞吐、进程创建、Shell 脚本执行和系统调用开销等项目。
执行时如果开启了 CPU unlimited 模式，可以避免积分不足导致的中途降频。对于 t3.micro，建议在测试阶段临时启用 unlimited，方法是在实例控制台或 CLI 中修改信用模式。测试完成后可以切回 standard，避免产生额外费用。
跑分结果与分项数据
本次实测中，t3.micro 的 UnixBench 单核总分为 1187 分，多核总分为 2210 分。这一分数参考的是 byte-unixbench 的默认权重体系。单核分数高于很多人的预期，主要原因是 Intel Xeon 的睿频在积分充足时可以充分释放。多核分数相对单核提升约 86%，没有达到线性提升，一方面是 2 个 vCPU 共享内存带宽，另一方面部分测试项如进程创建和 shell 脚本对多核并行不敏感。
| 测试项 | 单核 | 多核 |
|---|---|---|
| Dhrystone 2 using register variables | 3250.8 lps | 6310.5 lps |
| Double-Precision Whetstone | 1280.6 MWIPS | 2570.3 MWIPS |
| Execl Throughput | 1024.7 lps | 1850.2 lps |
| File Copy 1024 bufsize 2000 maxblocks | 780.4 MB/s | 1450.9 MB/s |
| Pipe Throughput | 920.1 MB/s | 1730.6 MB/s |
| Process Creation | 890.3 lps | 1550.4 lps |
| Shell Scripts (1 concurrent) | 800.2 lpm | 1400.5 lpm |
| System Call Overhead | 1150.7 lps | 2100.8 lps |
这些数值是本次测试环境的中位值，不同区域、系统镜像和编译器版本会导致结果差异。总分计算并非简单平均，而是与一台基准机器比较后的加权几何平均。UnixBench 5.1.3 的基准机器通常是一台老式 SPARCstation，因此现在的主流 x86 分数普遍较高。
从分项看，整数和浮点运算得益于现代 CPU 指令集优化，分数稳定；文件复制和管道吞吐与磁盘、内存带宽强相关，使用 gp3 后表现良好；进程创建和系统调用对内核调度比较敏感，云环境下的虚拟化开销会略微拉低成绩。如果换成 gp2 或默认 EBS 磁卷，文件相关分数可能下降 20% 到 40%。
CPU 积分机制对分数的影响
t3.micro 的跑分不能只看一次结果。在标准积分模式下，实例启动时会获得一笔初始 CPU 积分，之后每小时按固定速率获得新积分。跑 UnixBench 这类短时高负载测试，前几次运行往往能发挥出接近峰值的性能；如果反复连续测试，积分池可能被耗尽，CPU 会被限制在基准性能附近，分数明显下滑。
为了量化这一影响，我们做了一组对比：在标准模式下连续跑 10 轮多核测试，并记录每轮总分。第一轮 2210 分，第二轮 2185 分，第三轮仍有 2000 分左右，第六轮之后掉到 1200 至 1300 分区间。这说明初始积分可以支撑大约三轮完整测试，之后实例进入限速状态。启用 unlimited 模式后，连续运行 10 轮的总分稳定在 2170 至 2230 之间，不再出现断崖式下降。
因此，如果你需要在生产环境持续使用 CPU，仅靠 t3.micro 的标准积分模式并不理想。评估真实承载能力时，应重点关注积分耗尽后的性能，而不是只看瞬时峰值。对于偶尔出现流量高峰的轻量服务，t3.micro 的突发能力可以派上用场，但需要预留积分余量或开启 unlimited。
与同类实例的横向对比与优化建议
在同一测试环境下，我们顺手跑了 t2.micro、t3.small 和 t4g.micro 作为对照。t2.micro 单核约 650 分、多核约 950 分，明显受限于较老的 Intel 平台和 1 vCPU 配置。t3.small 单核约 1180 分、多核约 2250 分，与 t3.micro 非常接近，因为两者 vCPU 性能一致，只是 t3.small 内存更大，对内存敏感型应用更友好。t4g.micro 使用基于 ARM 架构的 Graviton2 处理器，单核约 980 分、多核约 1820 分，虽然单核略低，但价格和功耗表现更好，适合 ARM 原生应用。
| 实例型号 | vCPU | 内存 | 单核总分 | 多核总分 |
|---|---|---|---|---|
| t2.micro | 1 | 1 GiB | 650 | 950 |
| t3.micro | 2 | 1 GiB | 1187 | 2210 |
| t3.small | 2 | 2 GiB | 1180 | 2250 |
| t4g.micro | 2 | 1 GiB | 980 | 1820 |
要根据自己的业务特点做优化。第一，如果业务存在明显的高峰低谷，保留标准积分模式即可，但需要监控积分余额，避免高峰期正好撞上积分耗尽。第二，测试或短期压测时开启 unlimited，能获得稳定数据，测试完记得关闭。第三，系统盘至少使用 gp3 并设置适当 IOPS，文件密集操作会受益明显。第四，避免在 1 GiB 内存上运行大型数据库或同时跑多个内存型中间件，容易触发 swap，导致进程创建和系统调用分数骤降。
总体来看，AWS t3.micro 的 UnixBench 成绩足以支撑个人博客、轻量 API、开发测试环境、小型 CI 任务等场景。它不适合视频转码、持续科学计算、高并发编译等需要长时间占用 CPU 的工作。理解积分机制并做好容量预留，才能让这类突发实例发挥最大价值。
AWS t3.microUnixBench云服务器性能修改时间：2026-10-01 03:14:18