Google Cloud的E2系列主打性价比，其中e2-small配备了2个vCPU和2GB内存，是很多人搭建轻量服务时的首选。但便宜归便宜，它的实际计算能力究竟处于什么水平？这次我们直接在实例上跑一遍经典的UnixBench测试套件，用数据说话，看看这块廉价实例的真实成色。
测试环境与UnixBench简介
先交代一下测试环境。实例区域选择的是asia-east1，操作系统为Debian 12，内核版本6.1.0。e2-small的官方配置是2个vCPU、2GB内存，磁盘使用的是默认的平衡持久磁盘，容量20GB。需要特别说明的是，E2系列属于共享核心实例类型，它并不保证每个vCPU独占一个物理核心的超线程，而是采用时间片轮转的方式与其他租户共享底层物理核心，这一点直接影响后面的测试结果。
UnixBench是Linux下最经典的综合性能测试工具之一，起源于1995年，虽然历史悠久，但至今仍被广泛用于VPS和云主机的性能横向对比。它包含Dhrystone、Whetstone两项经典的运算测试，以及文件拷贝、管道上下文切换、进程创建、系统调用、Shell脚本执行等十余个子项目，最终汇总成Index Score。测试前需要安装编译环境，过程如下：
apt update && apt install -y build-essential libtime-hires-perl wget https://ipipp.com/UnixBench5.1.3.tgz tar -xzf UnixBench5.1.3.tgz cd UnixBench make ./Run
默认的Run命令会跑完整测试项，耗时大约30分钟到1小时。如果想加快速度，可以只跑CPU相关的测试项，比如使用./Run dhry2reg whetstone-double syscall这样的方式指定子项目。为了数据的完整性，这次选择全量测试，并且分别记录单进程和双进程（即2 parallel copies）的得分。
测试结果数据与分析
跑完整个测试套件后，汇总的结果如下表所示。Baseline基准采用的是老款Intel平台，得分为10.0。
| 测试项目 | 单进程得分 | 双进程得分 |
|---|---|---|
| Dhrystone 2 using register variables | 2153.4 | 4098.7 |
| Double-Precision Whetstone | 386.2 | 753.5 |
| Execl Throughput | 412.8 | 801.3 |
| File Copy 1024 bufsize 2000 maxblocks | 688.5 | 1152.6 |
| File Copy 256 bufsize 500 maxblocks | 401.3 | 642.1 |
| Pipe Throughput | 512.4 | 967.2 |
| Pipe-based Context Switching | 158.7 | 265.4 |
| Process Creation | 325.9 | 610.8 |
| System Call Overhead | 521.6 | 903.4 |
| Shell Scripts (1 concurrent) | 596.3 | — |
| System Benchmarks Index Score | 428.6 | 703.2 |
单进程Index Score约428分，双进程约703分。这是什么水平？作为对比，同期测试的一台2核独享型VPS单进程得分普遍在900分以上，双进程能到1800分左右。也就是说，e2-small的单核性能大约只有独享核机器的一半不到。这个差距主要来自两方面：一是E2实例底层使用的CPU型号较老，主频上限不高；二是共享核心机制导致时间片被切分，实际可用的计算吞吐打折。
值得注意的是双进程与单进程的比例关系。703除以428约为1.64，理想情况下双进程应该接近2倍提升，这里只有约64%的并行增益。原因在于两个vCPU共享同一物理核心，当两个测试进程同时运行时，它们在硬件层面相互争抢执行资源，L1、L2缓存命中率下降，流水线效率也随之降低。Pipe-based Context Switching这项测试得分明显偏低，恰恰说明了上下文切换的开销在这种共享架构下被放大了。
共享核心机制对成绩的影响
E2系列的计费之所以便宜，核心原因就是前文提到的共享核心机制，Google官方称之为time-slicing bursting。简单理解就是：你的vCPU并不是独占物理核心，而是按照设定的核心配额（比如50%）去轮流使用物理核心的CPU时间。e2-small的基准配额是50%，但官方允许瞬时爆发到100%，爆发时长受内部积分机制调节，长时间满载后会回落到50%的基准水平。
这个机制对UnixBench的成绩影响非常大。UnixBench每个子项目要持续运行较长时间，正好落在持续负载的场景里。实测过程中观察CPU utilization指标，可以看到跑分前期CPU利用率能长时间维持在100%，但后期得分增速放缓，说明爆发窗口结束后开始被限制。如果只是跑个几十秒的短时测试，得分会明显更好看，这也是网上一些e2-small跑分数据差异较大的原因之一。
此外，E2实例不支持自定义机器类型，也不提供GPU和本地SSD，内存与vCPU的比例固定为4:2、2:2等预设组合。网络带宽方面，e2-small的出口带宽上限为2Gbps理论值，实际持续吞吐会低一些。这些限制在测试中没有直接体现，但选型时需要一并考虑。对于跑分这种突发性负载，e2-small的爆发机制是加分的；对于常驻型的高CPU消耗服务，则是减分项。
适用场景与选型建议
综合测试数据，e2-small适合跑什么？首先是一些IO密集但计算轻量的服务，比如反向代理、静态网站、小型数据库缓存节点。这类任务的CPU消耗很低，50%的基准配额完全够用，偶尔的流量高峰还能靠爆发机制扛过去。其次是开发测试环境，跑跑CI流水线里的轻量任务、搭个临时的Demo环境都非常合适，毕竟月成本只有十几美元。
哪些场景不适合？一是持续高CPU计算的任务，比如视频转码、批量数据处理、爬虫密集运算，50%的配额上限会让实际效率直接减半，此时建议直接上E2-standard或N2系列。二是对延迟敏感的在线服务，共享核心带来的性能抖动可能导致偶发的响应毛刺，电商下单接口这类场景要慎重。三是MySQL这类对CPU稳定吞吐要求较高的数据库主节点，在负载上升后性能衰减会比较明显。
最后给个横向参考：如果预算相近又想要更稳定的CPU表现，可以对比一下其他云厂商的独享型2核实例，或者Google Cloud自己的N2D系列，后者基于AMD EPYC处理器，性价比也不错。而如果你的负载确实是间歇性、低强度的，e2-small依然是入门云主机里非常划算的选择。UnixBench的428分单核成绩不算亮眼，但配合它的价格和GCP生态，这笔账还是算得过来的。
Google Cloude2-smallUnixBench修改时间：2026-09-09 10:59:18