云服务器 CPU 只用了三成为什么还卡？五类等待、两种给法与四个替代指标

「监控说 CPU 用了八成，业务却一点都不卡」——反过来也有「CPU 只有三成，用户天天喊慢」。这两件事同时存在，说明「CPU 使用率」这个指标本身，在虚拟化环境下已经不太说明问题。

而真正该看的是「谁在等谁」：等 CPU、等磁盘、等网络、等锁。这篇文章讲清「使用率为什么不可靠」、给出「四类等待」的辨识方法、说明「份额制与配额制对指标的影响」，最后给一套「看哪一个数才知道机器忙不忙」的替换方案。

五款高性价比档位速查

有需要云服务器的，可以先看这一张表——五个价位段每款都是高性价比，价格从 22 元拉到 480 元。

商家	推荐款	配置	带宽与流量	月费	使用率可读性
云途	HK.N4.A	2 核 2G 20G	200Mbps / 500G	22 元	核少，使用率跳得最厉害
isvoro	HK CN2 Core	2 核 2G 30G	100Mbps / 300G	25 元	同核数，指标可信度相近
rabisu	Aydn VPS x8	4 核 8G 60G	—	34.5 元	核多，单核打满也不到三成
zji	香港 BGP 在售机型	6 核 16G 480G	55Mbps / 1T	450 元	物理核，指标最接近真实
sixtynet	LAX-MEDIUM	8 核 8G 160G	10Gbps / 20T	480 元	核太多，使用率被摊平

一、使用率是平均值

再补一句：「使用率」的定义本身就有好几种。

「含等待」和「不含等待」能差一倍。

所以「两个工具给出不同的数」是正常的。

而<'云途'+'> 那种小机器，这个差异最容易被察觉。

再补一个「为什么老板喜欢看使用率」。

「它是一个 0 到 100 的数,最好懂」。

而「好懂」正是它「不准确」的原因。

所以「把复杂系统压成一个数」必然丢信息。

而<'云途'+'> 那种 2 核档，压成一个数之后失真最大。

再看「换个说法」。

「排队有多长」比「用了多少」更像人话。

所以「讲队列」比「讲使用率」更容易对齐。

还有一条：「非技术人员也能理解队列」。

「排队的人比窗口多」这个比喻通用。

再看「沟通」。

「用比喻讲」比「贴截图」有效。

所以「换指标」也是「换沟通方式」。

而这四件事说明「指标选择」不只是技术问题。

再说一个「统计间隔」的问题。

一分钟采样会把「三秒峰值」抹掉。

而「三秒峰值」恰恰是用户卡顿的那三秒。

所以「采样间隔太粗」等于「看不见卡顿」。

而<'云途'+'> 那种小核数机器，三秒峰值来得更猛。

再看「峰值与均值」。

「峰值是均值三倍」很常见。

所以「按均值规划容量」一定不够。

还有一条：「短时峰值」也能触发限流。

而「限流」在图上看起来只是「一个尖点」。

再看「多核平均」。

「八核里一核满、七核闲」是两成左右。

所以「两成使用率」可能是「已经卡住了」。

而这四件事都指向「单一数字表达不了多核系统」。

所以「看分布」是唯一可行的方向。

「CPU 使用率」这句话里，藏着一个「平均」。

看到的	实际可能是
整体三成	单核跑满，其他核闲着
整体八成	大部分时间空闲，短时峰值很高
整体一半	在等磁盘，根本没有在算

「三成却慢」和「八成却不卡」这两件事，答案都在第一行和第三行：一个请求只用一个核，所以「多核平均」会稀释掉「单核打满」；而「等在磁盘上」的时间，在多数统计里不计入使用率。所以「使用率」这个数既不告诉你「单核满不满」，也不告诉你「在等什么」。而它被当成主要指标用了太多年。

第一行。「单核打满」是「单线程程序」的常态。

所以「四核机器上跑单线程」永远只有两成半。

而<'rabisu'+'> 那种多核低主频的机型，最容易出现这种「看着闲其实满」。

第三行。「等磁盘」这件事要单独看。

所以「等待类指标」比「使用率」更能定位。

判断方法：先看「单核曲线」,再看「整体」。

而<'zji'+'> 那种物理核机器，单核曲线最有参考价值。

二、四类等待

再补一句：「等待」这个词比「占用」准确。

因为机器的能力不是「被用掉了」,是「被卡住了」。

所以「按等待分类」比「按资源分类」更接近真相。

而<'rabisu'+'> 那种多核机型，等待藏在「核与核之间」最难看。

再补一个「等内存」这一类。

「内存不足」也会造成等待。

而「它表现为换页,而不是报错」。

所以「换页频率」是「第五类等待」。

而<'云途'+'> 那种 2G 内存档，换页最容易发生。

再看「换页的代价」。

「一次换页等于一次磁盘往返」。

所以「内存紧张时磁盘也会跟着忙」。

还有一条：「换页不会报错,只会变慢」。

而「变慢」最容易被误判成「CPU 不够」。

再看「缓冲」。

「文件缓存占满」是正常现象。

所以「内存看起来用了九成」不一定有问题。

而第五类让等待的分类从四类变成五类。

而「五类」之后,排查就有了完整的地图。

再说一个「怎么区分等 CPU 和等磁盘」。

「等 CPU」时进程状态是「可运行」。

而「等磁盘」时是「不可中断睡眠」。

所以「看进程状态」就能分开这两类。

而<'rabisu'+'> 那种大内存机器，等磁盘的概率通常更低。

再看「等网络」。

「连接数飙升但 CPU 不动」是典型。

所以「连接数」是网络等待的直接指标。

还有一条：「重传率」比「带宽占用」更能说明问题。

因为「带宽没满但重传多」等于「线路在丢」。

再看「等锁」。

「线程多、CPU 低、响应慢」三件同时出现。

所以「这个组合」几乎可以直接断定是锁。

而四类等待排查顺序建议「先排磁盘,再排锁」。

而因为这两种最容易被误判成「CPU 不够」。

机器「忙」的本质是「在等」，而等待分四类。

等 CPU：可运行队列变长。

等磁盘：磁盘队列变长。

等网络：连接数与重传变多。

等锁：线程数堆高但 CPU 不高。

四类等待有一个共同特征：它们都会让「响应变慢」，但只有第一类会推高「使用率」。所以「响应慢而使用率不高」的时候，答案一定在后三类里。而这个结论把「加 CPU」这个最常见的错误动作直接排除了。而「加 CPU 没改善」这件事，反过来正是「瓶颈不在 CPU」的证据。

第一类。「可运行队列」是最直接的指标。

所以「队列长度大于核数」就是真的忙。

而<'云途'+'> 那种 2 核档，队列一长立刻体感变慢。

第二类。「磁盘队列」反映 IO 排队。

所以「写日志多的业务」最容易卡在这。

第三类。「重传」比「延迟」更能说明网络问题。

所以「有重传就是线路质量有问题」。

第四类。「锁」是最难查的一类。

所以「CPU 不高、线程很多」就是这个信号。

四类的方法：「按「队列在哪排队」分类」。

而<'isvoro'+'> 那种同配置档位，正好用「同类对比」排除机器本身的问题。

三、份额制与配额制的差别

再补一句：「配额」在高峰期的价值最高。

因为高峰期「份额制」被邻居挤压得最厉害。

所以「高峰期的表现」才见真章。

而<'isvoro'+'> 那种写明配额的档位，高峰期最好预判。

再补一个「怎么看自己属于哪种」。

「跑满一段时间后,速度是平的还是掉的」。

而「掉的」多半是份额制加限流。

所以「跑一次持续压测就能分辨」。

而<'rabisu'+'> 那种多档位产品，正好用来对比「不同档的限流点」。

再看「限流的痕迹」。

「曲线出现平台」就是限流。

所以「平台」比「下降」更像限流。

还有一条：「平台高度」就是「你的真实配额」。

而这个数,商家页面通常不写。

再看「记录」。

「把平台高度记下来」,以后就能验证「有没有偷偷改」。

所以「记录」是「长期可用性」的保障。

而两种模式最实际的差别是「你能预测多少」。

再说一个「超卖的体感」。

「份额制 + 超卖」会让「高峰期不可预测」。

而「不可预测」比「一直慢」更难忍。

所以「稳定」这一项值得多花点钱。

而<'zji'+'> 那种物理核整机，可预期性最好。

再看「怎么测超卖」。

「同一时刻跑两次压测」看是否互相影响。

所以「自己和自己打架」就是超卖。

还有一条：「邻居」这个词在面板上看不见。

而它恰恰是你抖动的一大来源。

再看「选择」。

「问一句超卖比例」比「问多少核」实在。

所以「能否给出明确答复」本身就是筛选标准。

而这两种模式并不是「好与坏」,而是「贵与便宜」。

而「按业务敏感度选」才是对的。

云主机上，CPU 有两种给法。

份额制：按比例分，空闲时能超用。

配额制：硬上限，超过就限流。

两种给法会让同一个「使用率」代表完全不同的东西。份额制下，「三成」可能意味着「邻居忙的时候你被压到一成」；配额制下，「三成」是「你只用了三成,还有余量」。所以「使用率低」这一件事，在两种模式下含义相反。而在选择时，问一句「是份额还是配额」比问「多少核」更实在。

判断方法：问「超用会不会被限流」。

而<'sixtynet'+'> 那种大端口机器，配额通常给得很足。

份额制。「空闲时快、高峰时慢」是它的特征。

所以「白天测快、晚上测慢」就是份额制。

配额制。「永远不超过某个值」。

所以「超过就被限流」是配额制。

两种之外还有「第三种」:绑定物理核。

而「绑定」意味着「不会被邻居影响」。

所以「绑定」最贵,也最可预期。

四、该看哪几个数

再补一句：「四个数」不是「四个都要优化」。

而是「四个一起看,才能知道该优化哪个」。

所以「看全」比「看深」优先。

而<'spartanhost'+'> 那种整机产品，四个数都拿得到。

再补一个「免费工具够不够」。

「系统自带的命令」就能拿到这四个数。

而「不需要商业监控」。

所以「成本为零」。

而<'zji'+'> 那种独立整机，随时能登上去看。

再看「采集频率」。

「十秒一次」是合理频率。

所以「太密会增加自身开销」。

还有一条：「采到的数据要落盘」。

「只显示不留存」等于「没法复盘」。

再看「复盘」。

「卡顿之后回看」比「实时盯」更有价值。

所以「留存」是这套东西的地基。

而四个指标加起来只需要「一个脚本 + 一个文件」。

而「简单」是它能长期跑下去的原因。

再说一个「面板怎么改」。

「把四个数放一排,使用率放最后」。

而「位置决定注意力」。

所以「顺序」也是一种设计。

而<'sixtynet'+'> 那种大端口，网络类指标要单独放一栏。

再看「告警阈值」。

「按队列设告警」比「按使用率设」准确。

所以「队列超过核数就告警」。

还有一条：「告警太多等于没有告警」。

而「按使用率设阈值」正是告警泛滥的主要原因。

再看「历史留存」。

「保留一年」才能做「同比」。

所以「对比去年同期」比「看昨天」有用。

而换指标这件事最大的成本不是技术,是「习惯」。

而「习惯」只要一周就能换过来。

把「使用率」换掉，换成这四个数。

一：单核峰值。

二：运行队列长度。

三：磁盘等待时间占比。

四：P99 响应时间。

这四个数里，前两个回答「CPU 够不够」，第三个回答「磁盘够不够」，第四个回答「用户感受如何」。而「使用率」一个都回答不了。所以「换指标」这件事不需要花钱，只需要改监控面板。而多数人宁可买新机器，也不愿意改面板——因为「买」比「想」简单。

判断方法：把面板上的「使用率」换成这四个。

而<'spartanhost'+'> 那种整机产品，磁盘等待时间尤其值得看。

第一项。「单核峰值」比「整体」有用得多。

所以「单核常打满」就是「该升主频」。

第三项。「磁盘等待占比」高就是「该换盘」。

所以「换 SSD」比「加核」有效。

四项之后「使用率」只留作「粗看」。

而「粗看」没问题,「细查」就不该用它。

五、四个误判

再补一个「最典型的场景」。

「三成使用率、用户说卡、加了两核没用」。

而「加核之后使用率降到两成,速度没变」。

所以「使用率下降」反而证明了「瓶颈不在核」。

而<'rabisu'+'> 那种多核产品的老用户，最容易遇到「加核无效」。

再看「这个场景的真相」。

大概率是「磁盘」或「锁」。

所以「查这两项」比「再加核」有用。

还有一条：「这个场景很常见」。

而它每次都在浪费时间与预算。

再看「预防」。

「装机器第一天就把队列指标接上」。

所以「预防成本是一次配置」。

而这个场景本质上就是「不换指标」的代价。

而「换一次指标」就能永久避免。

再补一句：「误判」的根子是「指标太单一」。

而「单一指标」必然引出「单一解释」。

所以「多两个数,就多两种可能」。

而<'zji'+'> 那种物理核机器，指标本来就干净,误判更少。

再补一个「告警疲劳」。

「使用率告警一天响五十次」。

而「响五十次之后,没人再看了」。

所以「误报」的代价是「真报警也被忽略」。

而<'isvoro'+'> 那种档位明确的机器，告警可以减少一半。

再看「阈值怎么定」。

「按业务可接受的响应时间反推」。

所以「阈值来自业务,不来自直觉」。

还有一条：「告警要带上下文」。

「哪个指标、哪台机器、多久」三样齐了才可行动。

再看「分级」。

「可行动」和「仅记录」要分开。

所以「分级」是减少噪音的关键。

而四个误判其实都可以用「换指标 + 分级」一起解决。

再说一个「加核无效」的现实。

「单线程程序加核,响应时间几乎不变」。

而「使用率反而下降」,看起来像「变好了」。

所以「使用率下降」可能是「钱花了没效果」。

而<'spartanhost'+'> 那种单核主频高的整机，对单线程业务反而更合适。

再看「加内存」。

「内存不足」会表现为「CPU 不高、频繁换页」。

所以「换页也是等待的一种」。

还有一条：「换页时磁盘也忙」。

所以「磁盘等待高」可能根子在内存。

再看「加带宽」。

「带宽不是瓶颈时加带宽毫无效果」。

所以「先确认瓶颈,再加资源」。

而四个误判合起来说明一件事:「加资源」比「找瓶颈」简单,所以大家先加资源。

而「简单」的代价就是「反复加还没修好」。

这四个误判，几乎都来自「只看了使用率」。

误判一：使用率低所以还能加业务。

误判二：使用率高所以要加核。

误判三：使用率波动大是机器不稳定。

误判四：使用率与响应时间成正比。

四个误判里，第四个最误导人。因为「响应时间」是由「排队」决定的，而「排队」在「使用率接近打满」时会指数上升——也就是说，使用率从五成到七成可能没什么感觉，从七成到九成会突然崩。所以「使用率与响应」不是线性关系，而是「有一个拐点」。而盯着使用率看的人，往往在拐点前一秒还在说「还有余量」。

判断方法：找到「响应开始变陡」的那个使用率。

而<'zji'+'> 那种物理核机器，拐点位置最可预测。

第一句。「余量」要按「峰值」算。

所以「平均三成、峰值九成」= 已经满了。

第二句。「单核满」加核也没用。

所以「先判断是不是单线程」。

四个误判之外还有「第五个」:把「CPU 使用率」当「负载」。

而「负载」是「队列长度」,不是「使用率」。

六、什么时候该换机器

再补一句：「换机器」之后仍要「重测一遍」。

因为「换了之后是否真好」要验证。

所以「换完不复测」等于「换了个寂寞」。

而<'sixtynet'+'> 那种大端口，换完之后带宽项最容易验证。

再补一句：「换机器」是最后一步,不是第一步。

因为「换」的成本远高于「改」。

所以「先改配置,再改程序,最后换机器」。

而「这个顺序」能省掉大部分不必要的迁移。

再补一个「预算有限的顺序」。

「先加内存,再加硬盘,再加核」。

而「这个顺序是「按性价比」排的。

所以「同样的钱,先动便宜的项」。

而<'sixtynet'+'> 那种大内存大配额，一次性把前两项都覆盖。

再看「加核的收益」。

「程序能并行」时加核才有效。

所以「第一步要先问「这个程序能不能并行」」。

还有一条：「并行也有上限」。

「并发到某个点之后,加核反而变慢」。

再看「测法」。

「逐步加并发,看延迟拐点」。

所以「拐点之后的核是白买的」。

而这三条合起来就是「按性价比加资源」。

而「不是按「最贵的先加」」。

再说一个「换机器的成本」。

「换机器要迁移」,而迁移本身有风险。

而「能改配置解决的,不要换机器」。

所以「升级」优先于「搬家」。

而<'isvoro'+'> 那种支持在线升配的产品线，顺序上更省事。

再看「升配的边界」。

「单核主频」是升配升不了的。

所以「单核瓶颈」只能换机型。

还有一条：「换机型」要重装。

而「重装」就要迁移。

再看「局部替换」。

「把最重的那个环节单独拆出去」。

所以「拆分」比「整机升级」更省。

而四条判断最终都回到「先定位,再动手」。

而「定位」的成本只有「改一次面板」。

最后给一个判断标准。

「单核常打满」→ 换主频更高的。

「磁盘等待高」→ 换 NVMe 的。

「队列长但 CPU 不高」→ 查锁和 IO。

「使用率八成、响应正常」→ 什么都不用换。

四条里最后一条最反直觉，也最省钱：使用率高本身不是问题，排队才是问题。所以「八成但不卡」是完全正常的状态——说明资源用得很充分。而「三成但卡」才是该动手的信号。而这两种情况，靠「使用率」一个数根本分不开，必须看队列。而这就是「换指标」的实际价值。

判断方法：先看队列,再看使用率。

而<'isvoro'+'> 那种档位，换机器前先确认「是不是真瓶颈」能少花一笔。

第二句。「磁盘」是最容易换错的一项。

所以「换盘前先看等待占比」。

第三句。「锁」的问题换机器也治不好。

所以「并发问题要找代码」。

最后提醒：「忙」这件事要看「在等什么」,不是「用了多少」。

而「在等什么」,才是能修的那个东西。

本文讨论服务器 CPU 使用率指标在虚拟化环境下的局限与替代观测方法，不针对任何具体商家，也不对任何产品的性能、超卖策略或稳定性作评价与承诺。文中提到的四类等待、两种资源给法与四个替代指标均为通用参考；实际表现取决于平台实现、负载特征与程序结构，同一指标在不同平台含义可能不同。文中所有比例与关系均为经验判断，非行业标准或任何商家的承诺。本文不构成任何购买建议或性能承诺，亦不代表本站立场。因依据本文内容作出判断所产生的直接或间接损失，作者及本站不承担任何责任。