云服务器 CPU 只用 30% 为什么还慢？四种算法与五个排查方向

「面板上显示 CPU 只用了 30%，可访问还是慢」——这句话几乎每个运维都说过，而它背后有一件事很少被讲清：「使用率」这个指标本身有很多种算法，而不同算法给出的数字可能差一倍。而更要紧的是，有很多「慢」根本不会体现在 CPU 上。这篇讲清「CPU 使用率」这个数字到底在算什么、它会漏掉哪些情况，以及「看到 30% 但慢」时该往哪五个方向查。

五款高性价比档位速查

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

商家	推荐款	配置	带宽与流量	月费	核心特点
云途	HK.N4.A	2 核 2G 20G	200Mbps / 500G	22 元	三项都在合理区间的入门档
isvoro	HK CN2 Core	2 核 2G 30G	100Mbps / 300G	25 元	硬盘 30G 加 CN2 回国线路
rabisu	Aydn VPS x8	4 核 8G 60G	—	34.5 元	每核 8.6 元，带宽需单独确认
zji	香港 BGP 在售机型	6 核 16G 480G	55Mbps / 1T	450 元	480G 硬盘是整机档里少见的大盘
sixtynet	LAX-MEDIUM	8 核 8G 160G	10Gbps / 20T	480 元	唯一「大端口配大配额」的组合

再补一句：「使用率」不是一个「客观数字」。

它是「某个算法在某个采样下算出来的一个比值」。

所以「是谁算的」和「是怎么算的」这两件事同样重要。

一、使用率这个数字有四种算法

还有一个「采样间隔」的问题。

「一秒一采」和「五秒一采」看到的曲线完全不同。

而短时尖峰在五秒采样里会被抹平。

所以「使用率一直不高」有时只是「尖峰被采样吃掉了」。而这个现象在「突发型业务」上最明显——每秒有一个短促的高峰,而采样正好错开。所以看使用率要看「最大值」和「分位数」,而不只是「平均值」。而这个改动在多数监控面板里都能直接设置。

判断方法：看「峰值」和「P95」，而不只是看「平均」。

而<'zji'+'> 那种整机产品，核多时尖峰更容易被平均掉。

再看一个「统计口径」的差别。

「主机层」和「容器层」的数字经常对不上。

所以「同一个数在两个面板上不同」是正常的。

还有一条：「历史聚合」也会平滑。

按小时聚合之后,就看不出秒级的尖峰了。

四种算法之外,还有「采样」和「聚合」两道加工。

而这两道都能让「看到的数字」偏离真实。

「CPU 30%」这个说法，可以有四种不同的含义。

算法	怎么算	漏掉什么
整机平均	所有核加总	「一核满三核闲」
非空闲占比	100% 减 idle	把「等 IO」算成忙
用户态占比	只算 user	内核态与软中断
容器限额占比	相对配额	宿主机真实情况

这张表最该注意的是第一行：「整机平均 30%」在 4 核机器上可能意味着「一核 100%、三核 0%」。

而那一核满的时候，吞吐就已经到顶了。

所以「30%」这个数字只有在「所有核负载均匀」时才有意义。而实际系统里负载很少均匀——一个单线程的瓶颈、一个锁竞争、一个慢查询的回调，都能让「单核满」而「平均不高」。所以看使用率的第一步不是看数值，是看「每核分布」。

第二行。它把「等待」也算成了「忙」。

而「等磁盘」时代 CPU 确实「不安闲」，但没干活。

第三行。它把「内核态」排除在外。

而「软中断高」正是网络瓶颈的典型表现。

第四行。容器里的数字是「相对配额」的。

而「配额满」不等于「物理核满」。

四行的判断方法：看「每核分布 + iowait + 软中断」三项。

三项比一个总百分比有用得多。

而<'zji'+'> 那种 6 核 16G 的整机，「单核满」的概率更低——因为有更多核可以分摊。

补一个「单核满」的量化。

4 核机器「一核 100%」= 整机 25%。

8 核机器「一核 100%」= 整机 12.5%。

所以「核数越多的话,单核瓶颈在面板上看起来就越不显眼」。

再补：「一核满」也是一种「硬件够了但用法不对」。

而这类问题靠「换机器」永远解决不了。

所以「先看分布」这个动作省下来的不只是钱,还有一轮试错。

二、一核满其余闲是最常见的误判

再说一个「单线程」的识别方法。

并发从 1 加到 2，吞吐几乎不涨。

而这就是「单线程瓶颈」的直接证据。

所以「是不是单线程瓶颈」这个问题,一次小压测就能回答,不需要读代码。而这个测试的价值在于「它能排除一整类优化方向」——如果确认是单线程瓶颈,那「加核、加内存、换更大的机器」全都不必考虑。所以「先测一次」比「先猜」便宜得多。

判断方法：并发 1 和 2 各跑一次,比吞吐。

而<'云途'+'> 那种 2 核档位,单线程瓶颈的「浪费」最直观——因为一核基本闲着。

再看一个「多进程」的解法。

用多进程绕过单线程限制。

所以「进程数」要按「物理核数」配。

还有一条：「单连接」也可能成为瓶颈。

因为一个连接只能被一个核处理。

再看「锁」的粒度。

「全局锁」等于把多核变单核。

所以「拆锁」是「多核失效」的常见解法。

「平均不高但慢」的第一个原因，就是「单核打满」。

典型来源：单线程程序、GIL、大锁、单连接。

而它的表现是「吞吐卡在一条线」。

判断它只要一个动作：看「每核使用率」而不是「总使用率」。如果有一核长期接近 100%，那「加核」完全无效，「加并发度」或「改单线程结构」才有用。而这个判断只用十秒，却能省掉一次白买机器的钱。而这个误判之所以普遍，是因为多数面板默认只显示「整机平均」。

判断方法：top 里按 1，看每核条。

而<'云途'+'> 那种 2 核档位，「一核满」就是「整机 50%」，看起来「还早」。

再看一个「锁竞争」的表现。

多核都在跑但吞吐不涨，同时 CPU 有大量 sys 时间。

所以「sys 高」是锁竞争的一个典型信号。

还有一条：「GIL」让多线程完全单核。

所以「多线程」这件事并不等于「多核」。

再说一个「fio」的实用测法。

4K 随机读的延迟超过 5ms，说明盘是瓶颈。

而顺序读的速度不能代表随机读。

所以「测盘」这件事要用「随机小块」而不是「顺序大块」。而这一点在「数据库场景」尤其重要——因为数据库几乎全是随机小 IO。所以「顺序读写很快」这件事对数据库来说意义不大。所以测盘的口径要和业务口径一致。

判断方法：fio 用 4K 随机读，看延迟。

而<'rabisu'+'> 那种多机房产品，不同机房的盘性能可能差很多。

再看一个「缓存」的连带。

「页缓存」能让「重复读」变快。

所以「测盘前要绕过缓存」。

还有一条：「写放大」在 SSD 上很常见。

所以「写」的实测性能常低于标称。

再看「阵列」的影响。

RAID 级别直接影响随机写性能。

所以「同一个盘不同阵列」性能差几倍。

三、iowait 被算进使用率

再说一个「磁盘队列深度」的读法。

iowait 高但磁盘利用率不高，说明「等待时间长」。

而两者都高，才是「真忙」。

这个区分很重要:因为「iowait 高但利用率低」往往意味着「IO 请求被打散成很多小请求」,而解法是「合并请求」而不是「换更快的盘」。所以「iowait 高」这里面还要再往下拆一层,才能找到真正的解法。而多数人停在这一层就开始买盘。

判断方法：把 iowait 和磁盘利用率对着看。

而<'sixtynet'+'> 那种大端口产品,如果 IO 是瓶颈,要往上加的是盘不是带宽。

再看一个「日志」的连带。

同步写日志会让 iowait 明显上升。

所以「改异步日志」这件事是最便宜也最有效的优化之一。

还有一条：「数据库慢查询」也会体现为 iowait。

而这也是最常被误判成「盘慢」的那一项。

再看「swap」的识别。

free 里 swap 使用量非零就要警惕。

所以「内存够不够」这件事要看 available 而不是 free。

第二个原因，是「等磁盘」被算成「忙」。

「iowait 高」时 CPU 并不 idle，但也没算力输出。

而这个数在多核机器上还可能被平均稀释。

所以「CPU 30%」里可能有 20% 是 iowait。而 iowait 高的解法是「换盘、加索引、减少随机读写」，全部与 CPU 无关。所以看到「使用率不高但慢」，第二个该查的就是 iowait。而它是「最容易被误判成 CPU 不足」的一项。

判断方法：看 %wa 这一列。

超过 20%，就该查磁盘。

而<'sixtynet'+'> 那种大端口产品，如果 IO 瓶颈在盘上，带宽再大也没用。

再看「iowait 的假象」。

网络存储的等待也会体现为 iowait。

所以「iowait 高」不一定是「本地盘慢」。

还有一条：「swap」会让 iowait 飙高。

而这时真正的瓶颈是内存。

补一个「抓包」的成本提醒。

「tcpdump 全量抓包」在高流量下会吃掉大量 CPU。

所以「排查时抓包」本身可能成为新的瓶颈。

再说一个「协议选择」的影响。

「短连接 HTTP」比「长连接」多几倍的内核开销。

而这部分开销全在软中断这一侧。

所以「连接复用」这件事的价值不只是「快」,还有「省 CPU」。而这个省下来的量在「高并发」场景下很可观。所以「性能优化」有时只是「改一个连接策略」,而不需要动架构。而这个方向几乎没有成本。

判断方法：看 TIME_WAIT 和 CLOSE_WAIT 的数量。

而<'云途'+'> 那种 500G 配额的入门档，省下的 CPU 正好留给业务。

再看一个「批量」的收益。

「合并小请求」能同时省 CPU 和带宽。

所以「批处理」这条路是很划算的一种优化。

还有一条：「压缩」也有 CPU 成本。

所以「压不压」这件事要按「省带宽还是省 CPU」来权衡。

再看「加密」的成本。

TLS 握手是 CPU 密集的。

所以「握手的次数」也会明显影响到使用率。

四、软中断与网络栈的开销

再说一个「小包 vs 大包」的差别。

同样 1Gbps，小包的包数是大包的上百倍。

而每个包都要走一遍协议栈。

所以「小包业务」的 CPU 开销主要在网络栈,而不在应用逻辑。而这个现象在「API 服务和实时通信」上最典型。所以「优化小包」的手段——批量、合并、复用连接——能直接省下这部分开销。而这个方向几乎没人第一时间想到。

判断方法：看「每秒包数」而这个数常被忽略。

而<'isvoro'+'> 那种低延迟线路的产品，小包多时软中断压力更明显。

再看一个「网卡队列」。

多队列能让多个核分担收包。

所以「单队列」这种配置在大流量下会成为瓶颈。

还有一条：「中断亲和性」也影响分布。

绑错了会全压在一个核上。

再看「连接数」的成本。

每连接都有内核结构开销。

所以「万级连接」这种情况也要算一算 CPU 账。

第三个原因，是「网络包处理」吃掉了核。

「软中断高」时 user 时间不高，但整机忙。

而它常出现在「高并发小包」的业务上。

所以「使用率不高但慢」，第三个要查的是「软中断占多少」。而这一项在「网络型业务」上能占到两成以上。而它的解法是「多队列网卡、减少小包、批量处理」，也和「加核」关系不大。所以三项查完，你会发现「加核能解决的场景」其实很少。

判断方法：看 si 与 hi 两列。

两者相加超过 15%，就是网络栈开销大。

而<'isvoro'+'> 那种低延迟线路的产品，在「小包多」的业务上软中断压力更明显。

再看一个「连接数」的连带。

连接数上万时，内核的处理开销会显著上升。

所以「长连接复用」能同时省下 CPU 和延迟这两笔。

还有一条：「TIME_WAIT 多」也是信号。

说明连接频繁重建。

再说一个「监控工具」的差别。

不同工具读的是同一个 /proc，但计算方式不同。

而「两个工具数不一致」是常态。

所以「换工具能解决问题」是个误会——工具只是「读取和计算」,底层数据是同一份。真正要改的是「看哪些字段」。而这件事和工具无关,和「知不知道有这些字段」有关。所以「换一个更贵的面板」通常并不能解决「看不懂」的问题。

判断方法：直接看 /proc/stat 和 /proc/loadavg。

而<'sixtynet'+'> 那种大端口产品，网络指标要单独从 /proc/net/dev 读。

再看一个「load average」的误读。

它包含「等 IO」的进程。

所以「load 高但 CPU 低」是正常的。

还有一条：「load 要除以核数」才有意义。

「4 核 load 4」等于「满载」。

再看「时间窗口」的差别。

1 分钟、5 分钟、15 分钟三个数趋势不同。

所以「三个数一起看」能判断「是在恶化还是在恢复」。

补一句：「限额」和「隔离」是两件事。

有些产品只限不隔，有些既限又隔。

所以「配额相同」这件事并不代表「实际表现相同」。

再补：「宿主机」这一层往往拿不到数据。

所以「邻居在干什么」这件事只能靠 steal 间接推断。

而这也是云主机和独服之间最大的一个信息差。

五、容器限额与宿主机的差异

再说一个「限额」的两种形式。

「硬限」和「软限」行为完全不同。

而「软限」在宿主空闲时能超用。

所以「配额 2 核」可能是「保证 2 核,空闲时可借更多」,也可能「最多只能 2 核」。而这两种在「突发流量」时表现差异极大。所以「限额」这件事必须问清「能不能超用」。而这一点在「容器型产品」上几乎不写。

判断方法：看 cpu.stat 里的 throttled 是否增长。

而<'rabisu'+'> 那种低价多机房产品，限额形式要单独确认。

再看一个「内存限额」的连带。

容器内存超限会被直接杀掉。

所以「OOM」在容器里比在物理机上更常见。

还有一条：「CPU 配额」和「内存配额」要匹配。

比例失衡会一方先到顶。

再看「监控」的做法。

「容器内」和「宿主机」两边都要看。

所以「只看一个面板」必然漏信息。

第四个原因，是「看到的数字不是真的」。

容器里的「30%」可能是「配额的 30%」。

而宿主机那台机器可能已经 90%。

所以「配额型产品」的监控数字要看清基准。而更麻烦的是「限额」通常还能「借用空闲核」，所以「配额满」时反而可能比「配额未满」更快——取决于宿主机空闲程度。所以这一类产品的「使用率」必须配合「steal」一起看，单看一个数会得出相反结论。

判断方法：容器里看 cgroup 的 cpu.stat。

有 throttled 计数，说明确实被限额卡过。

而<'rabisu'+'> 那种低价多机房产品，限额与共享的情况要单独问清。

再看一个「虚拟化层」的开销。

虚拟化本身会吃 3% 到 8%。

所以「标称 4 核实得 3.8」是正常的。

还有一条：「steal」是宿主机抢走的。

它不在你的使用率里，但直接影响你的性能。

再给一个「排查顺序图」。

第一步：每核分布。有一核满就停。

第二步：iowait 和 swap。有就停。

第三步：steal。超过 5% 就停。

第四步：软中断和连接数。

第五步：才轮到「是不是真缺 CPU」。

这个顺序的关键在于「每一步都可能终止排查」。因为前四步里任一项命中,「加核」就不再是答案。所以五步走完之后还能剩下「真的缺 CPU」这种情况的,是少数。而这个顺序把「买机器」排到最后,能省掉大部分误购。而这个顺序和多数人的直觉正好相反。

判断方法：按顺序走，命中即停。

而<'spartanhost'+'> 那种独服产品，第三步可以跳过。

再看一个「终止条件」的判断。

「同一现象反复出现」说明是结构问题。

所以「偶发」和「持续」这两种情况要分开处理。

还有一条：「先记录再动作」。

改之前把五项数据都存下来。

再看「验证」这一环。

改完一定要「用同一个测试」来复测。

所以「测试方法」这件事一定要固化下来。

再说一个「负载类型」的区分。

「CPU 型」「IO 型」「网络型」三类的表现完全不同。

而「CPU 型」才是唯一「加核有效」的那类。

所以「先分类」比「先优化」更重要。而分类的依据就是「前五项指标里哪一项最高」。而这件事在「业务变化」后要重做——因为「同一个应用」在不同数据量下可能从 CPU 型变成 IO 型。所以「性能瓶颈」并不是固定属性,而是会随规模变化的。

判断方法：按「最高那一项」给负载分类。

而<'zji'+'> 那种大盘整机，适合「从 CPU 型变成 IO 型」之后的阶段。

再看一个「混合型」的处理。

两类同时到顶时，要「先拆开」。

所以「应用与数据库分机」是常见的第一步。

还有一条：「分类」也决定「该看哪个监控」。

网络型业务该看「包速率」而不是「带宽」。

再看「规模」的影响。

数据量翻倍，瓶颈可能换一类。

所以「每季度重新分一次类」是稳妥做法。

最后补一个「记录模板」。

六列：时间、每核分布、iowait、steal、swap、软中断。

而一张表连着记三天,规律自己会浮出来。

所以「先记录」这件事比「找答案」更早该做。

再补一句：「30%」这个数字本身不该引起焦虑。

真正该问的是「哪一项到顶了」。

而「没有一项到顶但就是慢」才需要往应用层查。

再补最后一句：先怀疑「指标」，再怀疑「机器」。

因为「指标看错」比「机器不行」常见得多。

六、看到 30% 但慢的五个排查方向

五个方向，按「命中率」排序。

方向一：每核分布（单核满）。

方向二：iowait（等磁盘）。

方向三：steal（被邻居抢）。

方向四：内存与 swap。

方向五：连接数与软中断。

五个方向里，前三个加起来能覆盖八成的「CPU 不高但慢」。而这三个方向有一个共同特点：它们都不在「整机平均使用率」这一个数字里体现。所以排查的第一步不是「看更多指标」，而是「不再只看那一个指标」。而这个认知转变，比任何工具都重要。

方向一。它最容易被忽略。

方向三。它是「云主机专属」的一项。

方向四。它常被「内存够用」的直觉掩盖。

而<'spartanhost'+'> 那种独服产品，「steal」这一项可以跳过——因为资源独占。

最后回到开头：「30% 但慢」不是矛盾，是「看错了指标」。

而换成「每核分布 + iowait + steal」三个数一起看，答案通常在十分钟内出现。

本文讨论 CPU 使用率的算法差异与常见误判，不针对任何具体商家，也不对任何产品的性能作评价或承诺。文中提到的四种算法、四个干扰来源与五个排查方向均为通用运维参考；实际表现取决于应用实现、内核版本、虚拟化方式、磁盘与网络配置，同一指标在不同环境下的含义可能不同。文中所有阈值（如「iowait 超过 20%」「软中断超过 15%」）均为经验参考值，非行业标准。本文不构成任何性能承诺或采购建议，亦不代表本站立场，也不代表对任何具体产品的推荐。因依据上述指标作出调整或采购决定所产生的直接或间接损失，作者及本站不承担任何责任。