2026虚拟化宿主机服务器怎么配：超卖比、NUMA与CPU绑定的现实边界

同样 32 核，为什么有的机器开 20 台不卡

一台 32 核的宿主机上开 20 台虚机，跑大半年没收到投诉；隔壁机架一台配置单几乎一样的机器，开到 8 台，客户工单就开始排队。CPU 型号一样、内存一样、虚拟化层和镜像模板也一样，差别出在哪儿？

出在负载形状上。前面那 20 台大概率是官网、测试环境、内部 OA 这类东西，单台日均 CPU 占用不到百分之十，而且忙的时间点互相错开；后面那 8 台里只要有两台在跑数据库或者持续编译，它们会把某几个核长时间压到满，还顺带把磁盘的随机写打满。核数相同，你真正卖出去的是"核的时间片 + 访存路径 + IO 队列"这三样东西的组合，只按核数算账当然算不准。

所以谈超卖比之前，得先回答一个更土的问题：这台机器上，同一时刻究竟有多少个 vCPU 真的想跑？这个数字叫并发度，它由业务决定，不由配置单决定。后面关于 NUMA、大页、IO 隔离的所有讨论，本质上都是在给这个并发度修路——让想跑的线程少排队、少绕远、少等 IO。

还有一个常被忽略的事实：客户感受到的"卡"，很少来自 CPU 真的算不过来，更多来自等待。等 CPU 时间片（客户机里的 steal 时间、ESXi 上的 ready 时间）、等远端节点内存、等磁盘完成、等网络中断被处理。这四种等待在监控图上的形状完全不同，处置手段也不同，把它们混在一起笼统地说一句"机器不够了"，往往会导致错误的扩容动作——明明该加内存，结果加了一台机器。

逻辑核、物理核与超线程：先搞清楚你在卖什么

vCPU 到底是个什么东西

在 KVM 上，一个 vCPU 就是宿主系统里的一个普通线程，由 QEMU 进程创建，Linux 调度器把它当普通线程排；在 ESXi 上，vCPU 对应一个 world，由 VMkernel 的调度器排。两种实现不一样，但结论一致：vCPU 不是一块固定的硅片，它是一张"允许占用一个逻辑处理器一段时间"的凭证。

而逻辑处理器不等于物理核。开了超线程之后，一个物理核会对外呈现两个逻辑处理器，这俩兄弟共享执行单元、一级缓存、部分二级缓存以及通往内存的带宽。英特尔和 AMD 的公开架构资料都把同步多线程描述为提升吞吐的特性，收益随负载类型浮动很大：访存密集、分支密集的负载普遍能拿到两成上下的吞吐提升；而已经把执行单元吃满的负载（部分数值计算、某些加密运算），提升非常有限，个别场景甚至因为缓存争抢出现负收益。

把超线程当两个真核卖，是超卖比算错的头号原因。一台双路 32 核机器开了超线程，操作系统看到 64 个逻辑处理器，如果你按 64 做分母、对外宣称开了 4 倍超卖，实际是每一个物理核背后塞了 8 个 vCPU。听上去是四倍，干的是八倍的活，机器当然会喘。

分母到底该写哪个数

建议一律用物理核做分母，并明确写成"vCPU : 物理核"。逻辑处理器这个数只在讨论中断绑核、调度域、亲和性时才有意义。用物理核记账的好处是横向可比：换机房、换机型、换 CPU 世代，那张表还能直接用；用逻辑核记账的话，哪天有人为了降低抖动关掉超线程，同一张表立刻失效，还得全盘重算。

顺带澄清一点：vCPU 总数超过宿主逻辑处理器数并不被禁止，超卖本来就是虚拟化的设计前提。真正的约束是并发度——峰值时刻处于可运行状态的 vCPU 总数。20 个 vCPU 里同一时刻只有 3 个想跑，和 20 个同时想跑，是两台完全不同的机器，尽管配置单上一个字都不差。

坑一：按逻辑核算超卖比，把超线程当一个真核用

问题表现是机器"核数明明还很富余，客户却已经觉得慢"。原因是分母虚高：超线程带来的那部分吞吐被当成完整核的产能计入，一旦负载的执行单元占用率高，实际可用产能只有账面的六到七成。

怎么判断：在客户机里看 steal 时间（top 里的 st、/proc/stat 的 steal 字段），或者 ESXi 上用 esxtop 看 %RDY；如果物理核平均利用率才四成左右，而客户机的 steal 已经稳定在 5% 以上，基本可以确认是分母算错了，而不是机器真的不够。

怎么规避：所有超卖比按物理核记账并在文档里注明；对执行单元密集型的负载（编译、加密、数值计算）单独降档，把它们和 Web 类负载分机放置；定期用一台基准虚机跑同一段负载，观察完成时间是否随密度上升而拉长，作为密度上限的校准信号。

NUMA 是什么，跨节点访存要付多少代价

双路服务器里，每颗 CPU 连同它直连的内存条构成一个 NUMA 节点。处理器访问自己节点上的内存走本地路径，访问对面节点的内存要走 CPU 之间的互连链路——英特尔叫 UPI，AMD 叫 Infinity Fabric。这条链路有带宽上限，也有额外延迟，于是"内存离得远一点"就变成了要付费的事情。

付多少？从公开的架构资料与业内常见的量级口径看，跨节点访存的延迟通常是本地访存的 1.3 到 2 倍，可用带宽则明显低于本地带宽。这个倍数听起来不算吓人，但放在每秒要访问内存几百万次的应用上，就是实打实的吞吐落差。更麻烦的是 AMD EPYC 这类处理器支持把一颗 CPU 切成多个 NUMA 域（NPS1/NPS2/NPS4 等配置），同一台机器在 BIOS 里换一个选项，节点数量和节点大小就变了，虚机放置策略也得跟着改。

虚机的麻烦在于它是被放置的，不是自己挑位置的。如果一台虚机的 vCPU 跑在节点 0，而它的内存大部分被分配在节点 1，那么它每访问一次内存都在付跨节点的钱。更常见的情况是内存被均匀撒在两个节点上：客户机操作系统觉得自己有一块连续的大内存，实际上有一半访问要绕远路，而且这个比例在运行时还会因为宿主的内存回收行为而漂移。

看不看得出？看得出。宿主上用 numastat 观察 numa_hit、numa_miss、numa_foreign、other_node 这几个计数器，numa_miss 持续 nonzero 就说明有相当比例的访问在跨节点；用 numactl --hardware 看节点大小与距离表，用 lstopo 或 virsh capabilities 看拓扑与 CPU 编号映射。客户机一侧则表现为同样的查询时快时慢，P99 延迟飘忽，但 CPU 利用率并不高——这种"没干活却慢"的组合，通常就是访存路径出了问题。

坑二：大内存虚机跨 NUMA 节点，访存延迟翻倍

问题表现：一台配置了 128G 内存的数据库虚机，跑起来还不如别人 64G 的快，加内存之后反而更慢。原因是虚机规模超过了单个 NUMA 节点能容纳的范围，vCPU 和内存分布被迫跨节点，一半左右的访存要付跨节点代价，延迟敏感型应用对这种代价特别敏感。

怎么判断：宿主侧 numastat 看 other_node 的增长速率，配合 numactl 观察该 QEMU 进程的内存分布；客户机侧对比两套配置下同一查询的 P99 延迟，如果加了内存之后 P99 反而上升，基本可以锁定。

怎么规避：给虚机设定"不超过单节点"的规模上限——vCPU 数不超过单个节点的物理核数，内存不超过单个节点的可用内存；确需超出的，显式配置 numatune 与 vcpupin 让分布可控，或者把 NUMA 拓扑透传给客户机，让它自己按节点做内存分配决策。AMD 平台上还要先确认 BIOS 的 NPS 设置，再决定节点大小，别拿默认配置直接上生产。

CPU 绑定与拓扑透传，什么时候必须做

把 vCPU 线程钉到具体的物理核上，专业点叫亲和性设置，KVM 里是 virsh vcpupin，ESXi 里是 CPU affinity。做这件事的收益有三条：保住缓存局部性（线程不来回搬家，一级二级缓存里的热数据不白丢）、保住 NUMA 局部性（vCPU 和它访问的内存待在同一个节点）、减少调度抖动（延迟敏感负载最怕的是不可预测的暂停）。

代价同样实在。手工绑定会削弱调度器的负载均衡能力：ESXi 默认会做初始放置和周期性的 NUMA 再平衡，VMware 的公开文档也提示手工 affinity 会限制这套机制；KVM 侧一旦把所有虚机都钉死，后续新开的虚机就容易卡在碎片里——明明总核数还有富余，却凑不出一段连续的可分配核。所以绑定不是越细越好，它是拿运维弹性换延迟确定性。

什么时候必须做？三类场景躲不掉：一是延迟敏感的负载，数据库、缓存、实时转码这类，P99 比平均吞吐重要得多；二是大内存虚机，跨节点代价摆在那里；三是 vCPU 数量超过单个 NUMA 节点核数时，至少要把拓扑正确透传给客户机，否则客户机操作系统按错误的拓扑做 NUMA 均衡，等于把决策建立在假地图上。ESXi 会在一定条件下以 vNUMA 的形式把宿主拓扑暴露给客户机，而 Cores per Socket 这类参数会直接影响客户机看到的拓扑形态，调整之前务必先确认当前版本的具体行为。

还有一个高频遗漏：只绑 vCPU，忘了绑别的线程。QEMU 的设备模拟主线程（emulator）、虚拟磁盘的 iothread、内核态的 vhost 网络线程，这些不绑就会在宿主核上到处飘，它们的执行会插进 vCPU 的时间片里制造抖动。KVM 上对应 emulatorpin、iothread 的 pin 以及 vhost 线程的 taskset，VMware 侧则要把管理世界和 IO 相关线程一并纳入考虑。

再往上是核隔离：用 isolcpus、nohz_full、rcu_nocbs 之类的内核参数把几个核从宿主通用调度域摘出来专供虚机，减少定时器中断与内核回调的噪声。代价是宿主可用核减少、管理任务排队，只适合少数机器精细化运营，不宜整批铺开。

内存：大页、气球与交换的三角关系

虚拟化下的内存访问要过两层地址翻译：客户机的虚拟地址先经客户机页表到物理地址，再经 EPT（英特尔）或 NPT（AMD）到宿主真正的位置。这套机制让 TLB 的压力显著上升，而 TLB 是处理器里最金贵的缓存之一。大页的意义就在这里：把 4KB 的页换成 2MB 甚至 1GB，页表项数量骤减，TLB 命中率上去了，访存开销下来。

大页有两种给法。静态大页是在宿主上预留一块 HugeTLB 池，虚机启动时直接从池里拿，行为确定、延迟稳定，代价是这块内存被锁死，不能再被气球回收、也不能被换出。透明大页（THP）则由内核后台线程自动合并，不用预留，但合并动作会带来偶发的延迟尖刺，碎片严重时的整理过程也可能让分配卡住。对跑数据库、缓存的机器，通常宁可选择静态大页，把确定性握在自己手里。

内存气球是另一种思路：宿主要在内存紧张时通过 virtio-balloon 向客户机"要"内存，客户机驱动把一部分页面交给宿主，宿主拿去给别人用。技术上没问题，问题在于压力被转嫁给了客户机内部，而转嫁到谁头上宿主控制不了。客户机发现自己可用内存变少，先做的是清 page cache，然后是换出匿名页，最后才是 OOM——清掉的 page cache 往往正是数据库和文件服务赖以提速的东西，于是吞吐掉一截，延迟抖一段。

坑三：内存气球开太猛，客户机内部开始交换

问题表现：宿主机的内存使用率看起来很健康，客户机却频繁出现超时，客户机内部的 swap 有读写。原因是气球膨胀过度，客户机的可用内存被压到工作集以下，它只能靠换页自救，而换页的目标设备又在同一块已经被争抢的磁盘上，于是雪上加霜。

怎么判断：客户机内看 si/so、swap 使用量、主缺页中断（majflt）的增速；宿主侧看该虚机气球的当前值占最大值的比例，如果长期处于高位且仍在增长，说明这台机器的内存已经处于透支状态。

怎么规避：给气球设上限，让初始值不等于最大值、留出可膨胀空间但别让它无限膨胀；对延迟敏感和跑缓存型应用的虚机，直接不挂气球或者把 current 设为等于 maximum；内存超卖整体要保守——内存是占用型资源，CPU 是分时型资源，两者的超卖逻辑根本不同，把 CPU 那套比例照搬到内存上迟早出事。

还有两点补充。宿主自身的 swap 一旦活跃，同一台机器上所有虚机会一起抖，所以宿主通常不配 swap 或只配很小的量并压低 swappiness，把"内存不够"暴露成显式的调度失败，而不是悄悄变成全机卡顿。KSM 同页合并能省内存，代价是扫描开销与跨虚机侧信道顾虑，只在模板高度同质的测试环境里考虑。另外，内存规划不只是容量，还有通道数：同样标称 256G，插满八通道与只插四通道在访存密集负载上差距明显，这个在购买阶段就要定下来。

磁盘 IO 的争抢比 CPU 更容易被忽略

CPU 争抢是可见的，客户机里的 steal、宿主上的 run queue 都会说话；IO 争抢则藏得深。宿主上表现为 iowait 抬高，客户机里表现为 await 变长、应用超时，但 CPU 利用率并不高，看上去像"磁盘变慢了"或者"应用自己有问题"。于是排查方向一错就是好几天。

先给量级概念，按公开规格口径而非实测：7200 转的机械盘随机读写 IOPS 通常只有一两百这个量级，十几台虚机共享一块盘，只要有一台在刷日志或者跑更新，队列就满了；SATA 固态盘的随机读能到数万 IOPS 量级，但接口带宽和写放大是它的天花板；NVMe 的真正优势不在顺序带宽，而在队列数量与队列深度，能同时容纳大量并发请求。

隔离手段按从硬到软排。最硬的是物理隔离：系统盘和数据盘分盘，高 IO 的租户独占盘。其次是镜像层：raw 格式比 qcow2 少一层元数据开销，qcow2 的快照链一旦拉长，读路径要回溯多层文件，性能衰减很明显；缓存模式上，用 cache=none 配合原生异步 IO 可以避免双重缓存，代价是失去宿主页缓存的加速。再往上是限速：libvirt 的 iotune 支持分别限制总带宽、总 IOPS、读 IOPS、写 IOPS，cgroup v2 的 io.max 提供同样能力。还有独立 iothread：给每块盘配一个 IO 线程并绑核，避免所有盘的 IO 都挤在 QEMU 主线程里排队。最后是调度器：NVMe 上多用 none 或 mq-deadline，机械盘上 bfq 对交互体验更友好。

限速有个细节：带宽和 IOPS 要同时限。只限带宽挡不住小 IO 风暴——一台虚机以 4KB 随机写刷满队列，带宽可能才几十兆，IOPS 却已打满，同盘邻居全被拖垮。保底配额要给两个维度，且保底比封顶更能解决"邻居互相影响"的问题。

坑四：所有虚机共享一块机械盘做系统盘

问题表现：整台机器周期性卡顿，每次几十秒，iostat 里 %util 长期接近 100，await 是正常值的几十倍。原因是所有虚机的系统盘、日志、临时文件都落在同一块机械盘上，随机 IO 的并发能力被迅速耗尽，一台虚机的日志刷盘就能让所有邻居一起排队。

怎么判断：对比宿主的 iowait 和客户机内部的 iowait，两边同时高基本可以确认是共享盘争抢；再用 iostat -x 看平均队列长度与 await，用 iotop 定位是哪个进程在制造 IO；如果客户机的 await 远远高于宿主裸盘的实测能力，说明排队发生在共享层。

怎么规避：系统盘统一换成固态盘，优先 NVMe；高 IO 租户的镜像放独立物理盘；给每台虚机配置 IOPS 保底与封顶；把日志、备份、临时目录引导到独立的盘或者外部存储；定期合并快照链，避免 qcow2 层数过多。机械盘不是不能用，但它只适合做冷数据和大顺序读写，不适合承载一堆虚机的系统盘。

网卡队列与中断分布，软中断会吃掉哪个核

网络这块的问题形状跟 CPU 不一样：它常常不是"整体带宽不够"，而是"某一个核被吃掉了"。虚拟网卡默认可能是单队列的，所有流的收发中断都落在同一个核上；开了多队列之后，接收端缩放（RSS）会把不同的流分到不同队列，每个队列的中断可以绑到不同核，压力才摊得开。

数据面在哪也决定了谁来背这个开销。KVM 上用 vhost-net 时，收发包的处理在内核线程里完成，这个线程可以被绑核；用纯用户态的 QEMU 网络后端，则要在用户态和内核态之间来回切换，开销更高。追求极限转发性能的场景会上 SR-IOV 直通或者 DPDK，代价是牺牲热迁移和宿主侧的可见性，属于有取舍的选项，不是默认答案。

软中断是常见暗坑。收包触发的 NET_RX 软中断在处理该队列中断的那个核上运行，mpstat 里如果某个核的 %soft 长期偏高，说明网络把这个核吃掉了。更糟的是这个核同时还跑着 vCPU 线程——网络流量一上来，虚机的 CPU 时间片就被软中断抢走，客户感受到的是"业务变卡"，而 CPU 利用率看着也不高，因为大部分时间花在了软中断而不是业务上。

怎么查：mpstat -P ALL 1 看每个核的 %soft 分布，是否集中在少数核；/proc/softirqs 看 NET_RX 的增量分布；sar -n DEV 看每秒包数（rxpck/s）；ethtool -S 看各队列的计数是否均衡。小包场景里，每秒包数才是瓶颈——按公开口径推算，万兆网卡跑满 64 字节小包是千万 PPS 量级，靠单核软中断扛不住，队列数和绑核策略必须先到位。

怎么调：虚拟网卡队列数与虚机的 vCPU 数或宿主预留核数匹配；把各队列中断固定到专门的核上，必要时用 isolcpus 把这几个核从通用调度域隔离出来；vhost 线程绑到与客户机同 NUMA 节点的核，避免网络处理跨节点访存；irqbalance 会周期性迁移中断，配置了手工绑核的环境里要相应设置排除列表，否则绑了也会被挪走。VMware 侧对应的是 NetQueue 与物理网卡的队列绑定，思路一致，只是入口不同。

两套典型配置：偏计算与偏 IO 的不同取舍

配置 A：偏计算型

目标是单位核成本，典型负载是批处理、编译、渲染、离线计算。硬件上优先物理核数与内存通道，双路机型把内存通道插满，本地 NVMe 主要承担系统盘与换页缓冲，容量不必太大。策略上：vCPU 与物理核的比例控制在 1.5 到 2 比 1；开静态大页，2MB 起步，规模大的直接上 1GB；vcpupin 按 NUMA 节点整组绑定，emulator 与 iothread 单独绑到相邻核；气球关掉或者上限压得很低，因为计算型负载的工作集是稳定的，回收空间有限；cputune 里的 shares 用来决定争抢时的分配比例，quota 用来封顶，不要反过来用 quota 去"保证性能"。

配置 B：偏 IO 型

目标是延迟稳定与租户隔离，典型负载是数据库、缓存、网关、中小企业的业务系统。硬件上主频优先于核数——中断处理和单核包转发速度都吃主频；盘要多块，系统盘与数据盘分开，高 IO 租户独占；网卡选队列数多的型号。策略上：vCPU 与物理核的比例压到 1 到 1.5 比 1；每台虚机用 iotune 给 IOPS 和带宽的保底值，再配一个封顶值防止单台失控；每块盘一个 iothread 并绑核；网络队列中断绑到专用核，并给宿主留出至少两个核处理管理与中断。

裸金属作为比选对象

还有一种情况是绕开这层调度不确定性：客户对拓扑确定性的要求高于对密度弹性的要求。比如客户自己还要再开一层虚拟化、或者要跑对 NUMA 极其敏感的内存数据库，那么宿主这一层的超卖与绑定策略对他来说都是干扰项，直接给裸金属反而干净——numactl 看到的节点就是硬件节点，物理核就是物理核，没有 vCPU 这层抽象。

一万网络（朗玥科技旗下）深耕 IDC 19 年（成立于 2007 年），深圳南山总部，自营机柜最快 1 分钟上架，裸金属机型从 E5-2620 32G/1T 的 ¥999 到双路 E5-2698v4 32G/1T 的 ¥3999（海外节点买 1 送 1，价格以官网实时价为准），做比选时可以直接把这两档当成上下界。裸金属换不来的是密度弹性与分钟级克隆，所以判断标准在于这台资源是长期独占还是反复拆分——长期独占的往裸金属上放，反复拆分的留在虚拟化池里。

超卖比怎么定：按负载类型分档而不是按经验

分档之前先把观测指标立起来。KVM 客户机看 steal 时间，ESXi 用 esxtop 看 %RDY、%CSTP 和 %MLMTD。三个值含义不同：%RDY 是"想跑但排队"，说明 CPU 争抢真实存在；%CSTP 是多 vCPU 虚机里兄弟 vCPU 互相等待的时间，它偏高往往说明这台虚机的 vCPU 给多了，减配反而更快；%MLMTD 是被人为限额挡住，属于策略性限制而不是资源不足。按常见的运维经验，%RDY 长期超过 5% 到 10% 就该回头看负载形状，但这个阈值不是普适标准，交易类和批处理类的容忍度差得很远，需要结合业务确认。

有了指标，就可以按负载类型分档，而不是按"老张说三倍没问题"来定。同一台机器上混装不同档位的负载时，取最严格那一档作为整机的密度约束，或者干脆把不同档位分机放置——把延迟敏感型和批处理型放在一台机器上，是密度上去了、体验下来了。

坑五：宿主机自身没有预留 CPU 与内存

问题表现：账面资源还有富余，宿主却开始出现管理操作卡顿、备份任务超时、监控丢点，严重时宿主上的管理进程被 OOM 杀掉，整台机器失联。

为什么会发生：宿主自己也在吃资源。QEMU 的设备模拟线程、IO 线程、vhost 网络线程、中断处理、监控代理、备份与快照合并任务，ESXi 侧还有 VMkernel 与各类管理服务；内存方面则是页表、网络缓冲、virtio 环形队列、快照缓存这些开销，它们不体现在任何一台客户机的用量里，但都是实打实的占用。

怎么判断：看宿主的 load、%sys 与 %soft 的长期水平，看 available 内存与 slab 占用，看历史 OOM 记录里被杀的是不是宿主进程；如果宿主自身的负载长期不低，说明预留不足。

怎么规避：预留两个核或者总核数的百分之十给宿主，内存按机器规模预留固定的数G；对备份、快照合并、镜像转换这类批处理任务做限速并安排在低峰；把监控代理的采集频率与数据量控制住，别让观测行为本身成为负载。

落地流程：取一周峰值监控，算出并发可运行 vCPU 的百分之九十五分位，按上表选档，先灰度三到五台跑两周，再复核 steal、await、气球膨胀三项，确认无异常后按同样密度铺开。密度会跟着业务负载漂移，每季度重算一遍比较稳妥。

什么时候应该加机器而不是继续超卖

四个信号值得单独拎出来。其一，steal 或 %RDY 的峰值与业务高峰严格同步，而不是随机出现——这说明争抢是结构性的，不是偶发。其二，气球长期处于膨胀状态，且客户机内部已出现 swap 读写，说明内存透支。其三，await 与队列长度持续偏高但吞吐没有增长，说明排队时间在吃掉产能。其四，单机故障域过大：这台机器一旦宕机，受影响的客户数量超出可承受范围。

扩容顺序上，先垂直后水平通常是更划算的。内存是最先到瓶颈的资源，加内存往往比重开一台机器便宜；换 NVMe 能一次性解决系统盘争抢；加网卡队列或升级网卡能解除 PPS 瓶颈。单台机器的升级成本一般低于新增一台机器的固定成本（机位、带宽、IP、运维管理都要再付一遍），但垂直扩容有硬上限——NUMA 节点大小、内存通道数、PCIe 槽位都会拦住你。

需要转向水平扩容的判断也很清楚：新增虚机的规模已经无法放进单个 NUMA 节点；或者密度继续提升带来的单位成本下降，已经小于投诉处理与客户流失带来的成本上升；或者单机故障域超出可承受范围。这三个条件出现任意一个，就该加机器，而不是继续往老机器上塞。

预算有限时的做法是把余量而不是密度当目标：按峰值预留三成余量开机，业务上来之后横向扩展。一万网络（朗玥科技旗下）深耕 IDC 19 年（成立于 2007 年），提供华南、华东、华北、中国香港及海外多节点，支持按需扩展，配套 7×24 中文工单（5 分钟响应）与硬件故障 10 分钟自动迁移、系统盘每日免费快照与 30 秒回滚，这类能力把"把超卖比定高一点赌一把"替换成了"密度留余量、需要时按量加机"，风险与预算两头都好交代。价格与规格以官网实时报价为准。

宿主机配置的验收方式

先说结论，成本这一侧的逻辑是这样的：超卖带来的单位成本下降有明确拐点，越过之后，故障处理和投诉的成本会反过来吃掉节省下来的钱。举个测算的例子（这是假设口径，不是实测数据）：一台机器承载 30 台虚机时，单台的月度硬件摊销为 A；把密度提到 45 台，摊销大约降到 A 的三分之二，看着很划算；但如果因此让 CPU 排队和 IO 排队抬升，每月多出十几张性能工单、再叠加一次客户流失，省下的那部分就被抵消掉了。所以真正该问的不是"还能不能再开几台"，而是"再开一台带来的边际毛利，是否大于它带来的边际投诉成本"。这两个数只要有一个测不准，密度就该停在原地。

验收要落到可执行的动作上。上线前压测：用接近峰值的负载跑三十分钟，指标按五分钟粒度记录，压测负载要包含小包网络、随机写、并发访存这三类，不能只跑 CPU 算力。验收阈值：客户机 steal 的百分之九十五分位控制在 5% 以内；await 相对空载的增幅不超过约定倍数；气球膨胀比例不超过设定上限；各核的 %soft 分布没有明显倾斜；客户机内关键接口的 P99 与基线一致。

灰度与回滚：新密度先放三台，观察两周，同期保留老密度作为对照；机器上始终留出百分之二十的空位作为缓冲，遇到突发负载可以直接吃掉。日常复核按月做一次，把密度变化曲线和投诉量曲线叠在一起看，两条线开始同步上扬，就说明拐点到了。

把超卖比当成一个需要持续校准的运行参数，而不是开机时填一次的静态数字，这一条比本文里任何一个具体比例都重要。比例会过时，负载会变化，只有校准机制是长期有效的。

超卖比开多少、要不要绑 NUMA、什么时候该加机器

超卖比开多少合适？

没有脱离负载类型的通用数字。按物理核做分母，静态展示类可以到 4 到 8 比 1，中小企业 Web 类 2 到 3 比 1，数据库与批处理类压到 1 到 1.5 比 1。同一台机器混装多类负载时取最严格的那一档。定完之后要验证：客户机 steal 或 ESXi 的 %RDY 在峰值时段的百分之九十五分位控制在 5% 以内，超过就要降密度或者把重的负载迁走，不要靠加 CPU 配额硬扛。

要不要开超线程？

建议开，但按逻辑处理器数量记账而不是按它当真核卖。超线程对访存密集、分支密集的负载通常能带来两成上下的吞吐提升，对已把执行单元吃满的负载收益很小。开了之后，物理核与逻辑处理器的对应关系要在文档里写清楚，绑核、中断分配都依赖这个映射；如果某台机器跑的是对抖动极其敏感的计算任务，可以单独关掉超线程换取确定性。

NUMA 一定要绑吗？

不是所有虚机都要手工绑，但必须保证分布可控。小规模、低占用的虚机交给调度器自动放置更省事；vCPU 数超过单个 NUMA 节点核数、或者内存规模较大的虚机，必须显式约束分布，至少要透传正确的拓扑让客户机自己做决策。手工绑定会削弱宿主调度器的再平衡能力，所以绑定要有节制，配套做好碎片管理。

大页该怎么配？

延迟敏感、内存规模大的虚机用静态大页，2MB 起步，规模特别大的考虑 1GB；规模小、密度高的通用虚机可以依赖透明大页，但要留意后台合并带来的偶发延迟尖刺。静态大页预留之后不能被气球回收也不能被换出，容量要按峰值虚机数一次性算够，还要把宿主自身需求一并计入。

宿主机内存留多少？

CPU 可以超卖，内存要谨慎，留白更要充足。宿主自身要预留固定数G用于页表、网络缓冲、virtio 队列和管理进程，规模大的机器按比例上浮；在此之上再给气球留出不超过设定上限的膨胀空间，并保留一部分完全空闲的内存应对突发。判断标准是宿主自身不出现 swap 活动、不出现因内存不足导致的管理进程异常。

磁盘怎么隔离？

物理隔离优先：系统盘用固态盘，高 IO 租户独占盘，日志与备份引导到独立设备。物理隔离做不到时用限速补：给每台虚机同时配置 IOPS 与带宽的保底和封顶，只限带宽挡不住小 IO 风暴。镜像层用独立 iothread 并绑核，定期合并快照链，避免 qcow2 层数过多拖慢读路径。

什么时候该加机器？

看三个条件：新增虚机的规模已经放不进单个 NUMA 节点；密度继续提升节省的成本小于投诉与客户流失增加的成本；单机故障域超出可接受范围。在此之前，先做垂直扩容——加内存、换固态盘、升级网卡，通常比重开一台机器划算。加机器的判断要基于峰值时段的百分位指标，别用平均值做决策。

本篇数据来源与口径说明

一万网络官网价目与节点说明（裸金属机型档位、服务基线、多节点分布）：https://www.idc10000.net/ ，价格以官网实时报价为准。

libvirt 官方文档（域 XML 中 cputune、numatune、iotune、memory backing 等配置项的含义与取值）：https://libvirt.org/formatdomain.html 。

KVM 与 QEMU 官方 wiki（vCPU 线程模型、vhost-net、virtio-balloon 与 virtio-scsi 的工作方式）：https://www.linux-kvm.org/ 与 https://www.qemu.org/documentation/ 。

VMware vSphere 官方文档《Resource Management》（CPU 调度、ready time、co-stop、NUMA 与 vNUMA 拓扑、CPU affinity 对 NUMA 再平衡的影响）。

英特尔与 AMD 公开架构资料（同步多线程、UPI 与 Infinity Fabric 互连、EPYC 的 NPS 配置选项）。

Linux 内核文档（HugeTLB 与透明大页、IRQ 亲和性与 SMP IRQ affinity、cgroup v2 的 io 控制器、调度器隔离参数）。

口径说明：本文中的比例与阈值为常见运维经验区间，需结合具体业务验证；磁盘与网卡的性能描述为公开规格的量级推算，非实测数据；价格均标注为参考价或需询价，实际以下单核算为准。