【VPS 硬件选型指南 (CPU 篇) 07】VPS 为什么卡：vCPU 超售与 steal time 揭秘，独享 CPU vs 共享 CPU

延伸阅读

更多相关攻略推荐：泛域名 SSL 证书自动化避坑：Acme.sh + DNS API 、BGP 是互联网的"高德地图"：打开网页时，数据是这样找路的、【优化线路 02】BGP / AS4837 常规线路年付 10 美元、高级玩家玩出花：如何在 VPS 上广播自己的 IP 地址？BYOIP、计算机科学两大难题之一：缓存失效与 CDN 瞬时刷新奥秘。

一、你遇到过这种"无理由卡顿"吗

你有没有遇到过这种情况：网站平时跑得好好的，一到晚上八九点访问高峰就明显变慢；或者你在服务器上编译一个项目，明明 top 里显示 CPU 使用率才六成、根本没跑满，可编译速度就是比预期慢一大截。这种"明明没满载却还是卡"的现象，很多时候并不是你程序写错了，也不是内存不够，而是有别的租户正在和你抢同一颗物理 CPU 的核心。这就是虚拟化世界里最容易被忽视、却最影响体感的问题：vCPU 超售带来的 steal time。

不少人第一反应是加内存、换机房、或者怪程序写得太烂。但这些办法往往治标不治本，因为根子不在你的进程里，而在虚拟化层的资源分配上。理解了 vCPU 是怎么被切出来、又是怎么被邻居分走的，你才能选对机型、用对命令、少花冤枉钱。

二、先分清：你买的 vCPU 到底是什么

在裸金属服务器上，你手里的是实实在在的物理 CPU 核心，算力归你独享，想怎么用就怎么用。但便宜 VPS 上的 vCPU 不是物理核，它是虚拟化层从一颗物理核里切出来的一段"时间片"。打个比方，vCPU 就像合租公寓里分给你的水电额度：纸面上你有一份，但整栋楼晚高峰都在用水用电时，你能实际用到的量就被摊薄了。物理核的算力是恒定的，可它上面的 vCPU 数量往往远多于物理核数量，大家轮流用、互相挤。

这里还有几个容易混的概念。物理核是 CPU 里真正干活的单元；超线程是让一个物理核伪装成两个逻辑核、分时复用内部资源的技术；而 vCPU 是虚拟化层呈现给客户机的"虚拟处理器"。云厂商卖给你的 vCPU，背后可能只对应物理核的一小部分时间，也可能对应一个完整逻辑核——区别就在套餐是否"独享"。理解这一点，是看懂后面所有"卡顿"的前提。

再换一个生活化的比喻：把物理核想成快餐店的厨师，vCPU 想成取餐窗口。超售的本质，就是窗口数量比厨师多。你下了单（进程就绪），但厨师正在给隔壁窗口做菜，你的单就只能排队。这段你等不到厨师的时间，就是 steal time。

三、核心概念：steal time 是被谁偷走的 CPU 时间

Red Hat 对 steal time 有一个权威定义：它是指客户虚拟机本该拿到、却被宿主机分配到别处（比如另一个客户机）的那部分 CPU 时间。换句话说，你的进程已经准备好运行了，调度器却因为物理核正忙着服务邻居，没把时间片分给你——这段你"等不到的 CPU 时间"就是 steal time。

在 Linux 上，steal time 出现在 /proc/stat 的 CPU 时间统计字段里，top、vmstat 这类工具会自动把它算出来，显示为 %st 一列。一个关键事实是：steal time 是无法被关闭的，它是内核记账的一部分，你改不了也藏不掉。Red Hat 也明确说过，大量的 steal time 意味着 CPU 争用，会拉低客户机性能。

要分清的是，%st 和你自己的 %us（用户态）、%sy（系统态）、%wa（I/O 等待）不是一回事。前三者是你自己进程的消耗，慢了多半是你自己的锅；而 %st 是"被邻居偷走"的部分，是外部环境造成的，你靠优化代码解决不了。看 top 时如果 %us 不高、%wa 也不高，唯独 %st 在往上爬，那基本可以断定：问题不在你，在邻居。

四、超售是怎么发生的：一台 32 核物理机卖 100 多个 vCPU

云厂商敢于超售，赌的是"大多数租户不会同时跑满"。一台 32 核的物理机，完全可能切出 100 多个 vCPU 卖出去，因为厂商预期同一时刻只有一小部分租户在重度用 CPU。平时大家低负载，相安无事；一旦晚高峰或某个邻居开始跑批处理，公平调度器下你能分到的份额就缩水。

超售的影响是可以量化的。有基准测试机构测算过：一个标称 2 vCPU 的 VPS，如果跑在严重超售的宿主机上，有效算力可能只剩 1.4 到 1.7 个 vCPU——也就是三成以上的算力被邻居"偷"走了。表现层面上，最直观的是响应尾延迟（p95、p99）变长，编译和数据库查询变慢，任务队列开始堆积，极端时机器几乎停滞。

对延迟特别敏感的业务，差距会是数量级的。有外汇 EA 的实测：在重大行情发布的瞬间，共享 VPS 执行延迟 50 到 300 毫秒、滑点 1 到 3 个点；而独享 VPS 仅 3 到 10 毫秒、滑点 0.2 到 0.5 个点。类似的，游戏服的世界模拟往往跑在单一主线程上，多核帮不上忙，邻居一抢核就卡。这些案例说明，超售不是"慢一点"那么简单，对某些业务是"能不能用"的差别。

五、怎么判断你的 VPS 被超售了：动手命令与阈值

最直接的办法是看 steal time。在终端里运行 top，观察 CPU 行里的 %st；或者用 vmstat 1，看输出第 8 列 st；更直观的是 mpstat -P ALL 1，可以按每个 CPU 看 %steal；也可以直接读文件拿到 steal 字段，命令是 awk 然后匹配 cpu 行打印第 8 个字段 /proc/stat。另外 iostat -x 1 能看磁盘 await，NVMe 正常应低于 2 毫秒，高于 10 毫秒往往说明存在磁盘争用。

经验上的量级口径是：配置良好的独享或低超售主机，steal time 通常持续低于 1%；中度超售的共享主机在有负载时能到 5% 到 15%；严重超售或高峰时段可能超过 30%，极端案例里甚至在 AWS t2 实例上实测到过 76.5%。实用的红线是：如果 steal time 持续超过 5%，基本就可以判定主机在超卖。中文社区的经验也类似：低于 10% 一般可放心，若超过 10% 且持续二三十分钟，体感就会明显变慢。

更稳妥的判定还有一套"三步法"。第一，连续 7 天监控 steal time，任何持续 15 分钟以上超过 5% 的时段都说明超售。第二，跑 5 分钟以上的持续 CPU 基准，和 30 秒的突发跑分对比，如果 5 分钟均值远低于突发值（比如 1500 掉到 900，跌了四成），说明持续算力被限制。第三，分时段跑（凌晨对比晚高峰），如果分数差三到五成，说明邻居在你高峰时抢资源。

六、实测对比：同样价钱，共享与独享差多少

很多人听过"某厂商单核 482、某厂商单核 1442"的说法。这里必须澄清一个常见误会：那两个数字并不是 UnixBench，而是 Geekbench 6 的单核跑分。具体来说，有 2026 年的实测显示，Contabo 某档机型的 Geekbench 6 单核约 482 分，Hetzner 某档约 1442 分，差距接近三倍。而真正的 UnixBench 单核跑分是另一套基准，比如 Hetzner 较老机型的 UnixBench 单核曾在 1387 到 1910 之间，和前面那组数字不是同一个量尺，不能直接并列比较，否则会误导读者。Geekbench 6 和 UnixBench 是两套不同的基准，分数不可混写。

在厂商定价上，共享与独享的差距也很直观。以 Hetzner 为例，它的 CX、CPX、CAX 系列是共享资源套餐，计算资源在物理机上所有实例间分配，提供基线性能并允许临时 burst 到基线之上；而 CCX 系列是独享资源套餐，1 个 vCPU 就等于 1 个物理 CPU 线程，性能连续可预测，官方也推荐它用于高生产负载和 CPU 密集型应用。价格上，同核数的 CCX 大约比 CX 贵三到四倍——CCX13 约 38 到 43 美元每月（2 个独享 vCPU 加 8GB 内存），而 CX23 约 9 美元每月（2 个共享 vCPU 加 4GB 内存）。

Vultr 这边，Cloud Compute 是共享 vCPU，其中的 High Frequency 线虽然频率更高（3GHz 以上、用 NVMe），但本质上仍是共享 vCPU；真正独享的是 Dedicated Cloud 与 Optimized Cloud Compute，用完全独享的新一代 AMD EPYC vCPU。所以"高频"不等于"独享"，买之前一定要看清套餐说明里到底写的是 shared 还是 dedicated。

七、独享 CPU 与共享 CPU：到底怎么选

选共享还是独享，核心看你的负载对"算力稳定性"的要求。下面这些场景用共享 vCPU 通常就够了：个人博客、访问频率不高的 API、开发与测试环境、以及内存型应用（瓶颈在内存而非 CPU）。这些负载要么本身很轻，要么峰值短暂、能靠 burst 顶过去，花共享的钱完全合理。

而以下场景建议上独享 CPU：数据库与 OLTP、编译与 CI/CD、高并发 Web 服务、实时或低延迟应用、以及游戏服务器。它们要么需要长时间把 CPU 跑满，要么对尾延迟极其敏感，共享主机的波动会直接变成用户的抱怨。

一个反直觉的事实是：Contabo 的 4 核套餐可能比 Hetzner 的 2 核还便宜，但 Hetzner 的 2 核往往实测更快。核数多不等于算力强，便宜 VPS 爱拿"核数多"当卖点，常常是一种障眼法——你真正该看的是单核性能和是否会被邻居抢。与其盯着 vCPU 数量，不如问清楚它到底是不是独享、单核跑分多少。

八、哪些场景千万别省：必须上独享 CPU

展开说几个最不该省的场景。数据库（MySQL、PostgreSQL）有大量随机读和锁等待，对延迟极其敏感，steal time 一高，查询就排长队，连接池被打满。编译和构建需要长时间把 CPU 跑满，共享主机的持续算力被限，一次本该几分钟的构建可能被拖到十几分钟，CI/CD 流水线整体变慢。

高并发 API 的 p99 延迟直接受 steal time 影响，对外的接口变慢会层层传导到前端。游戏服和交易服往往把世界模拟或撮合逻辑跑在单一主线程上，多核帮不上忙，邻居一抢核就卡顿掉线。前面提到的外汇 EA 实测很说明问题：在重大行情发布的瞬间，共享 VPS 执行延迟 50 到 300 毫秒、滑点 1 到 3 个点；而独享 VPS 仅 3 到 10 毫秒、滑点 0.2 到 0.5 个点。

这就是为什么对延迟敏感的业务，独享不是奢侈，是刚需。把独享 CPU 当成"省钱可选项"是常见误区，正确思路是按业务风险定价：能容忍偶发变慢的，共享足够；一旦变慢会造成真实损失（丢单、掉线、超时），就该为稳定的算力买单。

#VPS #CPU #steal_time #超售 #独享CPU

💡 延伸阅读：关于架构与基础设施的更多深潜指南，请前往 VPS 主题导读中心 (Hub) 获取全盘策略。