云服务器的资源来源很简单：一台物理机的 CPU、内存和带宽，会被切成多台虚拟机，分给不同客户使用。如果每台实例都按理论峰值预留资源，成本会高到没法定价，所以厂商普遍让售出的虚拟 CPU 总数超过物理核心数。这种做法就是超卖，英文常见说法是 overselling 或 CPU 超分配。
超卖本身不违规。它能成立，靠的是一个朴素的前提：大部分用户不会在同一时间把机器跑满。真正拉开差距的是超得多少。超得有分寸，多数人感觉不到；超得太狠，只要同宿主机上的邻居跑满，你的实例也会跟着变慢。不同产品线的隔离程度也不一样，共享型、突发性能型和独享型实例的争抢风险相差很大，选型前值得先弄清楚。
超卖在实际使用中怎么体现
最直接的判断办法是看 steal time。在 Linux 下运行 top 或 vmstat，观察 st 这一列即可。它表示虚拟机想使用 CPU，却因宿主机调度而等待的时间占比。st 长期偏高，说明宿主机上有争抢。不少团队会把 5% 当作参考线，超过就认真排查。这个数字并非官方标准，但拿来做告警阈值比较实用。
常见症状大致有这几种：
- 同一套压测脚本，白天和凌晨的结果差距明显
- 接口响应时间出现规律性尖刺，应用日志却没有异常
- CPU 使用率看上去不高，但 load average 持续偏高
- 单机性能测试在多次运行中无法复现
这些现象很容易被当成代码或数据库问题，排查方向一旦跑偏，就会浪费大量时间。
一个常见的排查场景
下面是一个示意性的场景，用来说明问题通常是什么形态。某电商团队把商品详情服务部署在共享型实例上，平时流量不大，运行一直平稳。大促前压测时，他们发现下午两点到四点之间的 P99 延迟，比凌晨高出近三倍。
团队先后排查了代码逻辑、数据库连接池和 GC 日志，都没有发现异常。之后在高峰时段连续运行 vmstat，发现 st 指标在下午明显抬高，而且时间段与宿主机上其他租户的业务高峰基本重合。延迟来自资源争抢，程序本身并没有问题。
后来团队做了两件事：核心服务迁移到独享型规格，同时对商品数据做缓存预热，并加上限流保护。延迟曲线随之趋于平稳。这类问题往往不在程序里，而在资源模型和业务峰值对不上。
突发性能实例的积分陷阱
还有一类情况容易被忽略。突发性能实例有一个基准性能，负载低时积累 CPU 积分，负载高时消耗积分。积分用完后，性能会被压回基准水平。很多人前半小时的压测数据很好，之后突然掉速，多半就是这个原因。选型时，基准性能、积分的积累与消耗机制，以及峰值能持续多久，比规格表上那几个数字更值得看。
如何应对
- 对延迟敏感的服务，选型时直接考虑独享规格。共享型更适合测试环境、个人博客和内部工具这类对波动不敏感的场景。
- 把 steal time 接入监控告警并设定阈值，不要只盯 CPU 使用率。CPU 使用率不高，也可能正在被抢占时间。
- 压测要覆盖至少两个时段，比如工作时间和凌晨。只在低峰测出的结论，大促时未必成立。
- 突发性能实例要持续压测一个完整业务周期，观察积分余额的变化，不能只看前几分钟。
- 核心链路预留弹性。高峰时能横向扩容，同时准备降级方案，例如暂时关闭非核心功能。
怎么看待超卖
超卖有它存在的道理。对不需要稳定延迟的业务，共享实例的价格通常很划算。对交易、支付这类业务，则要把超卖风险算进架构评估里，必要时为关键服务多付一些成本，换取更确定的表现。
遇到性能忽高忽低的情况，可以先看 steal time，再看程序日志。数据能很快分清问题出在程序还是邻居身上，比凭感觉判断可靠得多。
