云服务器 CPU 没跑满却越来越卡：用 loadavg、run queue 与 steal 判断该升核、换实例还是限流

云服务器监控显示 CPU 只有 40%70%接口却在高峰期越来越慢uptime的 load average 不断升高重启服务后暂时恢复过一会儿又卡。此时直接购买更多 vCPU可能有效也可能完全没有解决真正的等待来源。Linux 的负载不仅包含正在使用或等待 CPU 的可运行任务还包含部分不可中断等待任务。容器 CPU 配额、磁盘 IO、热点单线程和虚拟化 steal time都可能制造“CPU 看起来没满服务却在排队”的现象。本文给出一套只读优先的诊断流程帮助你判断应该优化线程与查询、调整容器配额、限流和自动伸缩还是升级或更换云服务器实例。一、适用场景云监控 CPU 平均值不高但接口 P95/P99 延迟持续上升uptime负载明显高于平时却找不到单个 100% CPU 进程Docker、Kubernetes 或 systemd 服务在宿主机有空闲时仍被限速同一规格云服务器偶发抖动需要判断是否与 steal time 相关准备升核、换实例族或增加副本希望先证明瓶颈大促、批任务或定时任务期间服务排队需要设计限流和自动伸缩。排查时要保留业务时间线请求量、错误率、P95/P99、队列长度和系统指标必须落在同一个时间窗口。二、load average 高不等于 CPU 一定不够先查看 CPU 数量、负载与当前可运行任务datenprocuptimecat/proc/loadavg/proc/loadavg前三列分别是 1、5、15 分钟负载。Linux 手册说明负载统计包含运行队列中的任务R 状态以及等待磁盘 IO 等不可中断任务D 状态。因此“负载高于 vCPU 数量”只能作为需要继续检查的信号不能单独证明应该升核。可对照proc_loadavg(5)和uptime(1)。第四列形如3/642前一个数字是当前可运行调度实体数量后一个是系统中现有的调度实体总数。它适合观察瞬时排队但仍要和连续采样结合。三、第一步用 vmstat 区分 CPU 排队和 IO 等待连续采样 60 秒并跳过“自开机以来平均值”的第一行vmstat-y160|teevmstat-$(date%F-%H%M%S).log重点看这些列r可运行、正在运行或等待 CPU 的任务数b等待 IO 完成而阻塞的任务数us/sy用户态与内核态 CPU 时间id空闲时间waIO waitst虚拟机被宿主机占用的时间也就是 steal timecs每秒上下文切换次数。字段定义可参考vmstat(8)。判断时不要套用“一旦 r 大于核数就必须扩容”的硬阈值短时突发很常见关键是r是否持续偏高并与接口延迟同步。如果 b 和 wa 高先查 IOiostat-xz160ps-eostate,pid,ppid,comm,wchan:32--sortstate|awk$1 ~ /^D/如果大量进程处于 D 状态磁盘延迟、网络存储、数据库刷盘或文件系统可能才是负载来源。此时加 vCPU 通常不是第一选择应继续核对云硬盘 IOPS、吞吐、队列和应用 IO 模式。四、第二步用 mpstat 和 pidstat 找到排队来源安装sysstat后观察所有 CPU 核mpstat-PALL160pidstat-u-w-t160需要重点区分所有核心都持续繁忙可能是真正的总计算能力不足只有一个核心接近满载可能是单线程热点、锁竞争或任务没有并行化%system高检查软中断、系统调用、网络包处理或内核路径%steal持续升高保留证据继续与云监控和应用延迟对齐cswch/s、nvcswch/s异常增长可能存在调度、锁竞争或线程过多。快速查看最忙的线程ps-eLopid,tid,psr,pcpu,stat,comm--sort-pcpu|head-30一个进程拥有大量线程不代表这些线程都在有效并行。还要结合应用 profiler、运行时指标、慢查询和锁等待定位热点。五、第三步正确理解 steal timevmstat的st和mpstat的%steal表示虚拟机原本可以运行、但 CPU 时间被虚拟化宿主机占用的比例。它是重要线索但不能凭一次瞬时峰值就认定“邻居抢资源”或云平台故障。建议这样取证mpstat-PALL1300|teempstat-steal.logvmstat-y1300|teevmstat-steal.log同时记录同一时间段的请求量、P95/P99 和错误率steal 是否连续出现而非单个采样点不同业务时段是否能重复观察是否同时存在 IO wait、cgroup 限流或单线程热点云平台实例监控、维护事件和工单信息。只有在多次采样中steal 持续升高并与延迟同步而且其他瓶颈被排除后才适合评估更换实例规格、实例族、宿主位置或向云平台提交工单。六、第四步检查容器和服务是否被 CPU 配额限流宿主机有空闲不代表容器可以无限使用 CPU。先确认 cgroup 版本stat-fc%T /sys/fs/cgroup在 cgroup v2 中cpu.stat可提供usage_usec、nr_periods、nr_throttled和throttled_usec等字段。以 systemd 服务为例先找控制组路径systemctl show-pControlGroup nginx再读取对应文件路径按实际输出替换cat/sys/fs/cgroup/system.slice/nginx.service/cpu.statcat/sys/fs/cgroup/system.slice/nginx.service/cpu.max对 Docker 可先看dockerstats --no-streamdockerinspect--format{{.HostConfig.NanoCpus}} {{.HostConfig.CpuQuota}} {{.HostConfig.CpuPeriod}}CONTAINERnr_throttled和throttled_usec都是累计值必须在相同业务窗口读取前后差值。Linux 内核的 cgroup v2 文档也明确说明了这些字段的统计范围。如果宿主机空闲、容器延迟升高且 throttling 增量明显优先检查cpu.max、容器 CPU 配额、服务副本数和请求并发不必立即升级整台云服务器。七、如何决定升核、换实例、限流或横向扩容1. run queue 持续高所有核心都繁忙先优化明显热点慢 SQL、序列化、压缩、日志、加密、锁竞争和无效重试。优化后r仍持续偏高并且 CPU 与业务延迟同步上升才评估增加 vCPU、选择更合适的计算型实例或增加服务副本。2. 单核热点明显如果总 CPU 只有 40%但一个核心长期接近满载单纯增加更多核心可能收益有限。需要确认应用能否并行、线程数是否合理、任务是否被单线程事件循环或全局锁限制。可扩展时再通过多进程或多副本利用新增核心。3. 短时突发导致排队请求突发但持续时间短优先评估队列、限流、熔断、缓存、异步化和自动伸缩。为了极少发生的尖峰长期保留大量空闲 vCPU未必是最合适的方案。4. steal 持续升高且可复现保留 5 分钟以上的采样、云监控和应用延迟时间线向云平台核验实例运行环境再比较更换实例、实例族或迁移后的相同压测结果。不要在没有对照数据时宣称某种实例一定存在资源争用。5. cgroup throttling 增量明显调整服务或容器 CPU 配额或增加副本。变更前确认资源边界和邻近服务影响避免取消限制后拖慢整台主机。八、变更后的验证方法变更前后使用相同流量模型和采样窗口至少比较接口 P50、P95、P99、超时率和错误率vmstat r/b/wa/st的持续时间与峰值所有核心的利用率和热点线程分布cpu.stat中nr_throttled、throttled_usec的增量磁盘 await、队列与 IOPS/吞吐单实例吞吐、总副本数和单位请求资源成本。压测机应与业务机分离逐级增加并发并设置停止条件。不要为了验证扩容效果把生产系统直接压到不可用。九、常见误区load average 高就立即升核负载还包含 D 状态等待看平均 CPU不看单核单线程热点会被总平均值稀释看到一次 steal 峰值就换云必须连续采样并排除其他瓶颈只看宿主机 CPU容器可能已被自己的配额限流把 iowait 当作 CPU 算力不足应继续查磁盘与依赖存储增加核心却不改应用并行度更多 vCPU 不一定被有效利用没有基线就比较升配效果必须保留相同时间窗口和流量模型。十、云服务器选购与升级建议购买、续费或升级云服务器时不要只依据一个 CPU 百分比。建议同时整理 730 天的 vCPU 利用率、run queue、steal、IO wait、容器 throttling、热点线程、请求 P95/P99 和高峰持续时间。持续的计算排队适合评估更多 vCPU、计算型实例或横向扩容单核热点先看应用能否并行容器限流先调整配额与副本IO 等待则应把预算放到云硬盘、数据库和存储路径steal 需要连续证据和迁移对照。把真正的等待来源找出来再选择云服务器规格才能让每一次升配都有可验证的收益。