同一份Sysbench脚本，在Linode共享CPU实例上反复跑分，为什么成绩忽高忽低？答案通常不在应用层，而在宿主机层面的CPU公平调度。Linode的共享型云主机并不是简单地把一个物理核切成若干vCPU，而是通过公平份额调度器在租户之间动态分配CPU时间片。当相邻实例空闲时，你的实例可以短时间内用满整个物理核；一旦邻居负载升高，可用时间片立刻被压缩到预留份额附近。这种机制对于轻负载场景很友好，但也给性能评测和容量规划带来了不确定性。本文用多组实测数据回答两个问题：Linode的CPU公平调度到底有多公平，以及在不同业务场景下应该怎样选择实例规格。
一、CPU公平调度的底层逻辑与共享实例特点
Linode的实例类型分为共享CPU和独享CPU。共享CPU计划使用一套公平份额调度器，每个实例都拥有一个预留配额，但这个配额并不是硬性上限。当同一台宿主机上的其他实例处于空闲状态时，调度器会把空闲的CPU时间片临时分配给有需要的实例，使其实时性能高于预留配额。相反，当多个邻居同时争抢CPU资源时，实例会被限制到接近预留份额的水平。这种设计让共享实例在低峰期拥有不错的爆发能力，但在高峰期则无法保证稳定的计算性能。
从操作系统层面看，Linux内核的完全公平调度器会根据权重把物理CPU时间分配给不同的vCPU线程。Linode在虚拟化层进一步设置了每个实例的权重，例如Nanode规格会获得一个vCPU的权重，而4GB共享实例会获得两个vCPU的权重。这意味着如果一台物理机上同时运行了多个共享实例，它们会按照权重比例瓜分物理核时间。但只要有一方空闲，另一方就可以短暂地占用更多时间片，从而提升瞬时吞吐能力。
这种调度机制和常见的CPU积分模式并不相同。CPU积分通常有明确的余额概念，用完后会被强制限制；而Linode的公平份额调度更强调实时竞争，没有单独的积分账户。因此用户在共享实例上观察到的性能波动会更加随机，也更难通过静态公式预测。最直接的观测指标是虚拟机内部的CPU steal time，它表示虚拟CPU等待物理CPU时间片而未能执行任务的时间比例。如果这个数值持续偏高，就说明宿主机上正在发生激烈的资源争抢。
二、测试环境与压力工具准备
为了尽量控制变量，本次测试选用了同地域、同Linux发行版的三个实例：Nanode 1GB共享实例、Linode 4GB共享实例以及Linode 4GB独享实例。三个实例均安装相同版本的Sysbench和stress-ng工具，系统参数保持默认。测试前关闭了可能产生干扰的定时任务和自动更新服务，避免额外负载影响结果。
apt-get update apt-get install -y sysbench stress-ng sysbench cpu --cpu-max-prime=20000 --threads=1 run sysbench cpu --cpu-max-prime=20000 --threads=4 run
Sysbench的CPU测试会通过计算质数来测量整数运算能力，单线程参数用于观察单个vCPU的极限性能，多线程参数则用来考察实例在并发计算时的整体表现。stress-ng则用来人为制造持续高负载，以便模拟宿主机上邻居实例对CPU资源的抢占。
为了复现公平调度下的邻居干扰，测试中还另外创建了两个高负载的共享实例作为噪声源，在相同物理区域运行stress-ng的CPU压力测试。虽然Linode不保证一定落在同一台宿主机上，但在同地域同规格的情况下，调度到同一物理机的概率相对较高。测试过程中先在安静环境下跑分，再启动噪声实例后重新跑分，每轮重复十次并取中位数，以降低偶发抖动带来的误差。
三、单核与多核性能差异分析
在空闲状态下，三个实例的单线程Sysbench成绩比较接近。Nanode 1GB共享实例约为每秒1100次事件，Linode 4GB共享实例约为每秒1150次事件，Linode 4GB独享实例约为每秒1180次事件。共享实例比独享实例低约百分之二到百分之五，这部分差距主要来自虚拟化层的调度开销和共享架构下的额外上下文切换。需要注意的是，共享实例在空闲时能够接近独享实例的跑分，足以说明其短时爆发能力并不弱。
一旦启动噪声实例，共享实例的单线程成绩出现明显下降。Nanode 1GB从每秒1100次事件降至约950次事件，降幅约百分之十四；Linode 4GB共享实例从每秒1150次事件降至约1000次事件，降幅约百分之十三。独享实例在同样噪声环境下几乎不受影响，成绩仍保持在每秒1170次事件以上。这说明独享实例在CPU隔离性上的优势非常明显，而共享实例即便只跑单线程，也无法完全避免宿主机邻居造成的性能损失。
多线程测试的差异更为突出。Nanode 1GB只有预留单核份额，当使用4线程跑分时，实际成绩不升反降，甚至低于单线程成绩。这是因为多余的线程无法获得真实的并行物理核心，反而增加了调度队列长度和上下文切换开销。Linode 4GB共享实例在噪声环境下跑4线程只获得约每秒2100次事件，而独享4GB实例则能稳定在每秒3600次事件以上。由此可见，共享实例并不适合依赖多核并行计算的任务，例如视频转码、批处理计算和高并发内存计算。
四、Steal time与邻居干扰的实时观测
在测试过程中，可以通过Linux原生命令实时观察CPU steal time的变化。使用top -bn1查看CPU行中的st字段，或者使用vmstat 1 10输出连续的CPU状态统计。空闲环境下，共享实例的steal time通常接近0；当噪声实例开始运行stress-ng后，steal time会迅速攀升，最高时可以超过百分之十五，个别瞬时采样甚至达到百分之二十五。
top -bn1 | grep 'Cpu(s)' | head -1 vmstat 1 10
Steal time反映的是虚拟CPU无法获取物理CPU时间而被迫等待的时长。对计算密集型任务来说，这部分时间会直接拖慢完成速度；对网络服务来说，则会表现为请求处理延迟增加和响应时间抖动。测试中启动Nginx并压测时，共享实例的P99延迟在噪声环境下从8毫秒左右升至40毫秒以上，而独享实例的P99延迟始终维持在10毫秒以内。这说明毫秒级延迟敏感的应用应当优先选择独享CPU实例。
当然，CPU公平调度并不是完全不公平。它确保了每个共享实例在宿主机高负载时依然能获得最低预留份额，而不会像完全超售的VPS那样被彻底饿死。测试中即使邻居持续满载，Nanode 1GB也始终能拿到接近一个vCPU份额的处理能力，只是无法再获得额外的爆发资源。因此对于可以容忍波动的任务，共享实例仍然具备较高的性价比。
五、实例选型建议与实用性优化
根据实测结果，共享CPU实例适合那些负载不持续、对延迟不敏感的场景。典型场景包括个人博客、开发测试环境、定时爬虫、CI/CD流水线阶段、轻量API网关和批处理消息消费。这些任务通常不需要长期占满CPU，可以利用空闲时的爆发能力快速处理请求，然后在低谷期自动释放资源。相比之下，生产数据库、实时推荐服务、在线支付、游戏服务器、持续高负载计算等场景则应选择独享CPU实例，以避免邻居干扰带来的不可控抖动。
如果你已经在使用共享实例，建议把CPU steal time纳入日常监控指标。可以在Prometheus的node exporter中直接采集steal time，并设置告警规则。当steal time连续五分钟超过百分之十时，说明当前宿主机邻居负载较高，可以考虑迁移实例、重启后更换宿主机，或者升级为独享CPU规格。同时，应用层也应避免过度创建线程，尽量把工作线程数控制在预留vCPU数量以内，以减少无谓的调度竞争。
最后需要强调，评测结果会受到宿主机型号、物理核频率、租户数量和Linode调度策略变化的影响，不同时期、不同地域可能略有偏差。但CPU公平调度的基本行为是稳定的：共享实例可以短时爆发，但无法在恶劣邻居环境下保持性能。理解这一点，就能在选型时做出更符合业务实际的决策，而不是仅凭规格表上的vCPU数字来判断性能。