Google Cloud Compute Engine 实例怎么选，CPU、内存和工作负载需要怎样匹配

在 Google Cloud 上创建 Compute Engine 虚拟机时，很多人第一反应是看 vCPU 数量和内存大小，认为 CPU 越多、内存越大，性能就越好。但云服务器的性能并不是简单地按照“核心越多越快”计算。

一台虚拟机可能受 CPU、内存容量、内存带宽、磁盘 IOPS、磁盘吞吐、网络带宽、CPU 架构以及应用程序本身的并发模型限制。选择实例时，如果只看一个指标，很容易出现一种资源严重过剩，而另一个资源已经成为瓶颈的情况。

Google Cloud 目前把 Compute Engine 的机器划分为通用型、计算优化型、内存优化型、存储优化型、网络优化型以及加速器优化型等不同类别。通用型适合大多数 Web 服务、应用服务器和普通数据库；计算优化型针对 HPC、计算密集型程序和对单核性能敏感的应用；内存优化型则面向大型内存数据库和内存分析等场景。

因此，选择实例的第一步不是问“需要多少 CPU”，而是先判断应用究竟缺什么资源。

一、不要再把 N1 当成今天的默认答案

原稿大量使用 n1-standard、n1-highmem 等实例作为主要案例，但 N1 已经属于 Compute Engine 的第一代通用型机器系列。Google 官方文档显示，N1 最初覆盖多代 Intel Xeon 平台，并提供 standard、highmem 和 highcpu 等配置；对于多数新部署，应该先考察更新的机器系列，而不是机械地从 N1 开始选择。

例如，目前通用型系列已经包括 N4、N4D、N4A、N2、N2D、C4、C4D 等不同选择。不同系列背后的 CPU 架构、内存技术、网络能力和存储能力并不相同，因此不能仅仅按照“8 vCPU 比4 vCPU快一倍”这样的方式理解性能。

Google Cloud 的 vCPU 也不能简单理解成一个完整的物理 CPU 核心。Google 文档说明，在大多数情况下，Compute Engine 使用 SMT，一个 vCPU 对应一个硬件线程；部分系列则是一线程对应一个物理核心。因此，不同机器系列之间比较 vCPU 数量时，必须同时考虑底层处理器和每核性能。

这也是原稿中“n1-standard-4 单核性能约等于16核物理CPU”一类说法需要删除的原因。这种比较没有统一的计算依据，也无法作为实例选型标准。

二、CPU 到底应该怎么配

CPU 密集型应用的特点是大量时间都在执行计算，而不是等待磁盘或者网络。例如视频转码、压缩、加密、科学计算、部分编译任务以及某些高性能计算程序，都可能随着 CPU 性能增加而明显缩短运行时间。

这类应用首先应该观察 CPU 使用率、单线程性能、并行度和任务持续时间。

如果程序本身只有少量线程，那么增加几十个 vCPU 并不会带来对应的性能提升。相反，如果程序可以高度并行，例如多个独立任务可以同时执行，那么增加 vCPU 往往更加有效。

Web 服务也是如此。一个 Web 服务器即使拥有大量 CPU，如果请求大部分时间都在等待数据库、缓存、外部 API 或磁盘，那么继续增加 CPU 的收益可能很小。

因此，“CPU 长期超过80%就必须升级”并不是 Google Cloud 的固定规则。80%可以作为监控中的一个警戒指标，但是否需要扩大实例，最终应该结合响应时间、请求队列、错误率、吞吐量和业务高峰共同判断。

如果 CPU 长期只有20%到30%，也不能简单认定应该降级。低 CPU 使用率可能意味着应用正在等待数据库、网络或者磁盘，也可能意味着系统存在明显的突发流量。如果为了节省成本直接降低实例规格，反而可能造成高峰期延迟。

三、内存容量和 CPU 是两个不同的问题

内存不足和 CPU 不足产生的表现完全不同。

如果应用需要大量内存保存数据库缓存、对象、索引或者计算中间结果，那么增加 CPU 并不能解决内存容量不足的问题。

Google Cloud 的不同机器类型提供不同的 vCPU 与内存比例。例如 N1 standard 每个 vCPU 配置3.75GB内存，highmem则达到每个 vCPU 6.5GB，而 highcpu只有0.9GB。更新的机器系列也提供不同的 CPU 与内存比例。

因此，与其简单地说“数据库至少需要4倍工作集内存”，不如直接观察数据库实际工作集、缓存命中率、页面换入换出、内存压力以及查询延迟。

数据库尤其不能套用一个固定比例。

PostgreSQL、MySQL、Redis、Java应用的内存模型完全不同。数据库自身缓存、操作系统页缓存、连接数量、排序操作、临时表、索引以及应用程序内存都会影响实际需求。

Java应用也不存在“JVM堆必须达到实际内存1.5倍”这种通用规则。JVM应该根据堆需求、垃圾回收器、容器限制和应用行为确定内存配置，并为操作系统和非堆内存留下空间。

四、内存带宽和容量不是一回事

一台机器拥有128GB内存，并不意味着任何需要大量数据处理的程序都能够获得相同的性能。

某些应用的瓶颈不是内存容量，而是内存带宽，也就是 CPU 从内存读取和写入数据的速度。

例如科学计算、部分数据分析、视频处理以及某些数据库操作可能需要大量连续内存访问。如果 CPU 经常等待数据从内存返回，那么增加 CPU 核心数量的效果就会逐渐下降。

这也是为什么选择实例时需要关注机器系列和底层 CPU，而不能只看“多少GB内存”。

不过，也不能把某个 DDR4 频率直接作为 Google Cloud 所有机器的统一性能指标。不同机器系列使用的处理器和平台不同，内存架构也不同，实际性能应该通过对应机器类型的基准测试验证。

五、磁盘性能不能用一个“每秒多少MB”概括

原稿把“每秒100MB写入”作为内存带宽与存储性能之间的关系，这个逻辑并不准确。

内存带宽和磁盘吞吐是两个不同层次的指标。应用进行磁盘 I/O 时，数据需要经过操作系统、虚拟化和存储路径，CPU、网络和存储设备都有可能成为限制因素。

Google Cloud 的 Persistent Disk 是网络化存储，性能主要涉及 IOPS 和吞吐量。对于4KB到16KB左右的小型随机 I/O，IOPS往往更重要；对于大块连续读写，吞吐量通常更加重要。Persistent Disk 的实际性能还受到磁盘容量、虚拟机类型、vCPU 数量和 I/O 大小等因素影响。

因此，数据库服务器不能简单地理解为“CPU够用、内存够用就可以”。

如果数据库产生大量随机读写，就应该关注 IOPS 和延迟；如果是大规模顺序读取和写入，则应该关注吞吐量。

Google Cloud 目前提供 pd-balanced、pd-ssd、pd-extreme 等不同 Persistent Disk 类型。pd-balanced 面向一般应用，在价格和性能之间取得平衡；pd-ssd 更适合需要较低延迟和更高 IOPS 的企业应用及高性能数据库；Extreme Persistent Disk 则针对高端数据库工作负载，并允许配置目标 IOPS。

此外，部分工作负载还可以考虑 Hyperdisk 或 Local SSD。不能把“没有 Local SSD 就一定慢”作为通用判断。

六、网络也是实例选型的一部分

对于普通网站，1Gbps 网络可能已经绰绰有余；对于大型文件传输、分布式数据库、视频服务或者 GPU 集群，网络则可能成为主要瓶颈。

Google Cloud 的网络带宽是按照虚拟机实例计算，而不是简单按照网卡或者 IP 地址计算。实例的最大出口带宽取决于机器类型和实例规模，部分较新的机器系列可以提供非常高的网络带宽。

因此，“计算密集型任务至少需要1Gbps”也不是一个普遍成立的规则。

一个本地数据处理程序可能几乎不需要网络；一个 GPU 分布式训练集群则可能极度依赖节点之间的网络通信。

这意味着网络需求应该从应用的数据流量反推，而不是按照 CPU 类型直接决定。

七、不同工作负载应该怎样选择

对于普通企业网站、API、后台管理系统和中小型数据库，通常可以从通用型机器开始。重点观察 CPU、内存、磁盘和网络四项指标，再根据实际监控数据调整。Google 也将通用型机器定位为适合大多数常规和云原生工作负载的类型。

对于计算密集型程序，则应该重点考察每核性能、CPU架构、并行度和持续负载。如果程序能够充分利用多线程，可以选择更高 CPU 配置；如果程序主要依赖单线程性能，则单纯增加 vCPU 未必有效。

对于数据库，应该同时观察内存命中率、磁盘 IOPS、磁盘延迟、CPU 使用率和网络流量。数据库出现慢查询，并不意味着一定需要增加 CPU。

对于内存数据库、大规模内存分析和 SAP HANA 等工作负载，则应该考虑内存优化型系列。Google Cloud 当前的内存优化型机器可以提供远高于普通通用型实例的内存与 vCPU 比例，部分系列能够提供 TB 级内存。

对于机器学习训练和推理，则不能只讨论 CPU 和内存。如果模型需要 GPU 或其他加速器，应该直接考虑 accelerator-optimized 系列以及对应 GPU 类型、GPU 显存、GPU 间通信和网络能力。

八、自定义实例什么时候值得用

如果预定义实例的 CPU 和内存比例刚好符合应用需求，使用预定义机器通常更加简单。

如果应用需要例如“8个 vCPU，但需要比标准配置更多的内存”，或者“CPU需求不高，但必须提供较大的内存容量”，那么自定义机器类型就有价值。

Google Cloud 支持部分机器系列创建 custom machine type，让用户自行组合 vCPU 和内存，而不必被固定规格限制。当前支持自定义配置的系列包括 N4、N4D、N4A、N2、N2D、E2 和 N1 等。

这类配置尤其适合那些标准实例比例与实际工作负载不匹配的应用，可以减少为了获得额外内存而被迫购买大量闲置 CPU 的情况。

九、正确的选型方法不是猜，而是测

比较可靠的 Compute Engine 选型流程应该是先确定工作负载，再确定主要瓶颈，然后进行基准测试。

例如 Web 服务可以记录请求量、P95/P99延迟、CPU利用率、内存压力和网络流量；数据库则增加 IOPS、吞吐量、缓存命中率和查询延迟；批处理程序则重点记录每个任务的执行时间、并发度和单位任务成本。

随后选择两个或三个候选机器系列进行实际测试。

如果扩大 CPU 后处理时间明显下降，说明 CPU 是瓶颈；如果增加内存后磁盘读写明显下降，说明此前存在缓存不足；如果 CPU 和内存都很低，但应用延迟很高，则应该继续检查磁盘、网络、锁竞争、数据库或者外部服务。

Cloud Monitoring 可以用于观察基础资源指标，应用级性能分析则应该结合具体语言和运行时工具。对于复杂系统，还需要把 CPU、内存、磁盘、网络和应用指标放在同一个性能模型中分析。

Compute Engine 实例选型的核心并不是寻找一台“配置最高”的机器，而是寻找资源比例与工作负载最匹配的机器。

对于大多数新部署，可以先从现代通用型系列开始；CPU 密集型任务再考虑计算优化型，超大内存应用考虑内存优化型，高 I/O 应用重点比较存储方案，GPU 任务则直接从加速器平台出发。只有当监控数据证明某项资源成为瓶颈后，再扩大对应资源。

这样做不仅能够提高性能，也能避免为了一个瓶颈购买整台规格过高的虚拟机，把大量没有被使用的 CPU、内存或者网络能力一起付费买下来。