8-5 虚拟服务器的性能估算 · 波仔的云计算课

📄 一句话概括

【这台机器能开多少台云主机？】——这个问题没有标准答案，因为云主机卖给你的那个单位（vCPU）不是一颗固定的物理核，而是一份【时间片的份额】。于是就有了超分比：一台物理机允许开出比它的物理核心更多的 vCPU，赌的是【大多数机器不会同时满载】。核心数据库敢 1:1，开发测试敢 6:1，同一台机器能开出的实例数差 6 倍——这个倍数就是【性能估算】要算的那笔账。

📝 本节和前面几节的关系

它把 1-7 那句话落到了具体数字上：那一节说【云上的服务器是虚拟服务器】，这一节回答【这些虚拟服务器到底是怎么切出来的、能切多少个】。

它也接上 4-4：那一节说虚拟化让【一台机器变成好多台】，这一节算的是【到底能变成几台、代价是什么】。

而它和 8-1 里【租用方式】那一节正好配成一对：上一节说【买多久】，这一节说【买多大】。

一、vCPU 不是一颗固定的核

云上买机器，看到的是【2 vCPU、8 GB】这样的规格。这里的 vCPU，很容易被理解成【一颗物理 CPU 核心】，但它其实不是。

准确的描述是：vCPU 是 Hypervisor（虚拟化层）分配给虚拟机的【一份逻辑计算单元】——它本质上是一份【CPU 时间片的份额】，会被调度到物理核心上去执行。

这个区别带来一个重要后果：物理核心数和 vCPU 总数之间，没有固定比例。一份物理资源可以被切成多少份 vCPU，取决于云商（或者你自己）的【超分策略】。

为什么可以超分？ 因为现实的服务器极少真正满载——一台对外提供服务的机器，大部分时间 CPU 利用率可能只有百分之十几。 于是把【同时可以挂上去的 vCPU】开得比物理核心更多，成了普遍做法：让那些大部分时间在空闲的机器，共享同一批物理核心。 这就是超分。

二、动手 Demo：超分比与能开多少台

看到什么算成功：

==================================================================================================
【Demo 5】虚拟服务器的性能估算
==================================================================================================

  前提：一台双路服务器，每颗 16 核，开启超线程。

  物理核心 = 2 x 16 = 32 核
  物理线程 = 32 x 2 = 64 线程（超线程把 1 核当 2 线程用）

  【一】超分比：不同负载敢超多少

  工作负载            建议超分比（vCPU : 物理线程）     理由
  ------------------------------------------------------------------------------------
  核心数据库          1 : 1 或更保守                    延迟敏感，不能被邻居抢
  通用企业应用        2 : 1 ~ 3 : 1                     有 I/O 等待和空闲周期
  开发测试环境        4 : 1 ~ 6 : 1                     不怕偶尔卡顿

  超分比的本质是【赌大多数机器不会同时满载】。赌赢了省钱，赌输了卡顿。

  【二】这台机器能开多少台 2 vCPU 的实例

  超分比            算式                                    可开实例数
  ------------------------------------------------------------------------------------
  1 : 1             64 x 1 / 2                              32 台
  3 : 1             64 x 3 / 2                              96 台
  6 : 1             64 x 6 / 2                              192 台

  同一台机器，差 6 倍。所以【能开多少台】这个问题，
  答案不取决于机器，取决于【你敢不敢赌】。

  【三】估算的先后顺序

  第 1 步  测真实峰值（至少观察 7 天，取 P95 而不是平均值）
  第 2 步  保留 10% ~ 20% 给宿主机自己用
  第 3 步  按负载类型选超分比
  第 4 步  留出增长余量，再定实例数

读结果：

第一段先把【核心】和【线程】分开。开启超线程之后，一颗物理核心会被操作系统看成两个逻辑线程——所以算容量时，用的是【线程数】而不是【核数】。 这一步很容易漏，漏掉就会把容量少算一半。
第一张表的重点不是那几个数字，而是【为什么差这么多】。核心数据库之所以要 1:1，是因为它【延迟敏感】——只要有一台邻居的虚拟机在抢核心，数据库的响应就会出现毛刺。 而开发测试环境之所以敢 6:1，是因为它【不怕偶尔卡】——慢一秒没人投诉。 所以超分比不是一个技术参数，它是【你对这份负载能容忍多少抖动】的表达。
第二张表把这笔账算到底：同一台机器，从 32 台到 192 台，差 6 倍。 这说明云商的【超分策略】直接决定了它的成本和价格——同样规格的两家，背后超分比不同，能承载的密度就不同，售价也可以差很多。 而对使用者来说，这意味着【便宜的那个规格，很可能也是超分更狠的那个】。

三、超分比的依据：负载类型

选超分比，本质是在回答一个问题：这份负载【允许被抢多少】。按这个标准，可以分成三类：

负载类型	特征	超分建议
延迟敏感型	数据库、实时交易、风控	1:1 或更保守，不冒险
通用型	Web 服务、中间件、ERP	2:1 ~ 3:1，靠空闲周期平衡
容忍型	开发测试、批处理	4:1 ~ 6:1，慢一点没关系

这里有一条经常被忽略的经验：超分比【允许】你开更多 vCPU，但并不保证它们都有性能。 当好几台虚拟机同时满载时，它们会一起排队等物理核心——表现出来就是【所有机器一起变慢】。这种现象在云上叫【邻居干扰】——你隔壁那台看不见的机器，可能正是拖慢你的原因。

所以估算的落脚点不是【最多能开多少】，而是【在我不希望被拖慢的前提下，能开多少】。 这两个答案往往差很远。

四、估算的正确顺序

Demo 第三段给了四步，值得展开：

第 1 步，测真实峰值。 注意是【P95 或 P99】，不是平均值——平均值会把偶发的尖峰抹平，而尖峰恰恰是决定体验的那个时刻。 观察期至少一周，覆盖工作日和休息日两种负载形状。

第 2 步，给宿主机留一份。 物理机自己要跑虚拟化层和管理程序，通常要留出 10% ~ 20% 的算力。 把全部算力都分出去，管理面自己就会不稳。

第 3 步，按负载类型选超分比。 这一步决定了【密度】，也就决定了【成本】。

第 4 步，留增长余量。 按【现在的负载】算出实例数，往往一上线就不够——因为业务会涨。 所以要留出一截余量，这也是为什么云上【先小后加】比【一次买大】更常见。

五、2026 现状

① 超分比越来越被【显式】规定。 早年云商往往不公开自己的超分策略；2026 年，主流云商开始把【是否超分】写进实例族命名里——比如【计算优化型】通常不超分或轻超分，而【突发型】允许较重的超分。 这给了使用者一个明确的判断依据：看实例族名字，大致能知道它的性能确定性。

② 【性能确定性】本身成了一种商品。 除了 CPU 超分，内存、网络带宽、磁盘 IOPS 也在被分级。有些规格保证【独享带宽】和【稳定的 IOPS】，价格自然更高——这说明市场已经接受了一件事：不是所有人都只买【平均性能】，有人愿意为【稳定的下限】付钱。

③ NUMA 与绑定成了大实例的必选项。 当一台实例的 vCPU 数比较大时（比如 16 核以上），它可能横跨两个物理 CPU 的内存区域——跨区域访问内存会明显变慢。 所以性能敏感的部署，会要求把实例【绑定】在同一个物理 CPU 的内存域内——这是从【能开多少台】进一步细化到【这台的性能稳不稳】。

30 秒实验

打开你自己电脑的任务管理器（Windows）或活动监视器（macOS），做两件事：

看看 CPU 的【核心数】和【逻辑处理器数】——它俩是不是不一样？
再随手指一个时间点，看看 CPU 使用率是多少。

做完你会看到两件事：逻辑处理器数通常是核心数的两倍（这就是超线程，一个核被当成两个用）；而使用率大部分时间都不高。这两个观察合起来，就是超分能成立的全部依据——因为你的电脑大部分时间也闲着，云商的服务器当然也一样。 只不过你一个人闲着的机器没法共享出去，而云商可以。

常见误区

错误：1 个 vCPU 就等于 1 颗物理核心。——纠正：vCPU 是一份逻辑份额，不是一颗固定的物理核。在开启超线程的机器上，一颗物理核心对应两个逻辑线程；在超分的机器上，一个物理线程还可能要服务好几个 vCPU。 所以【2 vCPU】这个规格本身不说明性能——它在不同云商、不同实例族上，实际拿到的物理资源可能差好几倍。
错误：云商敢超分，说明超分是安全的、可以放心用。——纠正：超分的安全前提是【赌大多数机器不同时满载】——这个赌注不是永远成立。当你的业务正好撞上全场的高峰期（比如电商大促的同一时段），邻居干扰就会集中爆发——表现是【所有机器一起变慢】，而你从自己这边完全看不出原因。所以对延迟敏感的业务，就该老老实实选不超分或轻超分的规格——多花的钱买的是【确定性】。
错误：容量估算按平均值算就够了。——纠正：平均值会掩盖真正的问题。一台 CPU 平均利用率 20% 的机器，可能在每天上午 10 点冲到 90%——而用户体验的坏点，恰恰出现在那个尖峰上。 所以估算要取【P95 或 P99 使用率】，而不是平均值；观察期也要够长，至少覆盖一个完整的业务周期（一周）——不然算出来的余量是假的。
错误：先把机器买大一点，反正可以随时改。——纠正：可以改，但改是有代价的。调大规格通常要重启实例，而且如果你买的是【预留实例】，改规格会牵涉到合同调整。所以更稳的做法是先按实际测量算出需求，留一截合理的余量——买大一点【保险】，但不要把【保险】变成【常态】。云上真正省钱的姿势是【贴近实际需求 + 弹性伸缩】，而不是【一律买最大】。

自测三问（点开对答案）

1. 为什么一台物理机可以开出比它的物理核心更多的 vCPU？ —— 因为**虚拟化的本质是【共享时间片】，而不是【切分实物】**。**大部分服务器在大部分时间并不满载**——**它们的 CPU 有大量空闲周期**。**超分就是把这些空闲周期收集起来，让更多虚拟机挂上来用。** 只要**大家不是同时满载**，每台机器都能拿到它需要的那一份。**所以超分成立的前提不是【资源够分】，而是【需求错峰】**——**一旦所有虚拟机同时忙起来，这份前提就没了，性能就会一起掉。** 2. 为什么【核心数据库要 1:1，开发环境敢 6:1】？判断依据是什么？ —— 判断依据是**这份负载【能容忍多少抖动】**。**核心数据库对延迟极其敏感**——**只要邻居抢走一点核心，它的响应就会出现毛刺，而这种毛刺会直接影响交易**。**开发环境正好相反**——**编译慢 10 秒、页面加载慢 1 秒，对使用者几乎没有影响**。所以**同样的机器，配给数据库只能开 32 台，配给开发环境能开 192 台**——**差别不在技术，在【这份负载到底在乎什么】。** 3. 为什么估算容量时要看【P95 使用率】而不是【平均使用率】？ —— 因为**决定体验的是峰值，不是平均**。**一台平均利用率 20% 的机器，完全可能在高峰期冲到 90%**——**用户投诉的时刻，都发生在那个高峰上。** 如果按平均值 20% 去规划，**你会以为还有很多余量，实际上一到高峰就顶不住了。** 所以**取 P95（或 P99）是为了【把那些真正会被用户感知到的时刻纳入计算】**——**这也是容量估算里【宁可算紧、不可算松】的道理：算松了性能不够，算紧了只是多花一点钱。**

☐ 下一节（8-6 从现有系统移植到云端：裸金属）