服务器响应变慢、服务频繁超时，监控却显示CPU使用率并不高？这是运维排查中很常见的困惑。问题的核心往往不在于CPU本身是否繁忙，而在于系统负载过高。负载高和CPU忙碌是两回事——它反映的是等待运行或因为磁盘I/O等原因被阻塞的进程数量。接下来，我们将系统梳理遇到这种高负载但低CPU的异常状况时，应从哪些方向入手排查。
一、理解系统负载平均值与CPU使用率的本质区别
首先需要厘清一个基本概念：系统负载（Load Average）和CPU使用率衡量的维度完全不同。负载平均值统计的是单位时间内，处于可运行状态（R状态，就绪等待CPU调度）和不可中断睡眠状态（D状态，通常等待I/O操作完成）的平均进程数。而CPU使用率，仅仅是CPU时间片被实际占用的比例。两者之间没有直接的换算关系。系统负载很高，完全可能是因为大量进程在排队等待磁盘读写（I/O阻塞）、争抢同一把锁，或单纯是进程数太多调度不过来，而非CPU在进行密集计算。
排查的第一步，通常是执行 uptime 或 top 命令，查看第一行末尾的 load average 三个数值（分别代表1分钟、5分钟、15分钟的平均负载）。
接着，用 grep -c 'model name' /proc/cpuinfo 命令获取服务器的逻辑CPU核心总数。
如何判断异常呢？如果1分钟负载值持续高于你的CPU核心总数，同时观察top命令中CPU那一行的wa（I/O等待）、st（偷取时间）指标又没有显著升高，那就基本可以确定，需要深入排查D状态进程或其他资源争用问题了。
二、定位高负载根源——检查I/O等待（wa）与不可中断进程
I/O等待是导致负载虚高但CPU空闲的头号嫌疑犯。当进程因磁盘读写、网络收发或设备驱动阻塞而进入D状态（不可中断睡眠）时，它们会被计入负载，却不消耗CPU周期。
首先，运行 top 命令，重点关注%Cpu(s)行中的 wa 字段百分比。如果该值持续高于5%，就需要高度警惕了。
此时，可以执行 iostat -x 1 3 命令，查看各磁盘设备的await（平均等待时间）、%util（利用率）以及r/s、w/s（读写速率）等指标，定位哪个磁盘或分区已成瓶颈。
同时，执行 ps aux | awk '$8 ~ /D/ {print $0}' 命令，可以直接列出所有处于D状态的进程及其命令行信息。
找到可疑的D状态进程后，通过 cat /proc/[PID]/stack 命令查看其内核调用栈，就能确认具体的阻塞点，比如是卡在 `ext4_writepages`（文件系统写操作）还是 `nfs_wait_on_request`（网络文件系统等待）等内核函数上。
三、识别高负载进程——使用top命令精准排序与过滤
top命令默认按CPU使用率排序，但在负载高的情况下，我们需要把目光从%CPU移开，更多关注进程数、线程数以及运行队列长度。
启动 top 后，先按下数字 1 键，这样可以显示每个CPU核心的独立使用率，有助于判断是否存在单核饱和而其他核围观的不均衡情况。
接着，按下 Shift+H 键，切换到线程视图。此时每一行显示的是一个轻量级进程（LWP），对于分析Java、Nginx这类多线程应用内部的热点问题非常实用。
然后，按下 f 键进入字段管理界面。在这里，建议启用 PGRP（进程组ID）、WCHAN（进程当前等待的内核函数）以及 TIME+（进程累积使用的CPU时间）这几个字段。
最后，按下 O 键（大写字母O），可以选择按WCHAN字段排序。如果发现大量进程都阻塞在同一个内核函数上（例如 `jbd2_log_wait_commit`，即ext4文件系统日志提交的等待函数），那问题根源就非常明确了。
四、分析运行队列与上下文切换——定位调度瓶颈
如果运行队列过长（r值高），或者上下文切换过于频繁（cs值高），都说明内核调度器压力山大。这通常由大量短生命周期进程频繁创建销毁、线程间激烈竞争或锁争用导致。
执行 vmstat 1 5 命令，观察输出中 r 列（运行队列长度）的数值。如果它持续大于你的CPU核心数，就说明总有进程在排队等待执行。
同时，检查 cs 列（上下文切换次数）。如果每秒切换次数超过10万量级，就需要怀疑是否存在进程被高频唤醒，或者不当地使用了自旋锁。
为了更精确地定位是哪个进程在折腾调度器，可以执行 pidstat -w 1 5 命令。它会展示每个进程每秒发生的任务切换次数（cswch/s，包括非自愿切换）和自愿上下文切换次数（nvcswch/s）。
对于cswch/s异常高的进程，可以使用性能分析利器perf：perf record -e sched:sched_switch -p [PID] -g -- sleep 10。这条命令会捕获该进程在10秒内的调度事件，并记录调用栈，之后用 `perf report` 分析，就能看到是哪些代码路径导致了频繁的调度切换。
五、排查虚拟化偷取时间与内核锁竞争
对于运行在虚拟机里的系统，还有一个特殊因素需考虑：宿主机资源被抢占。这体现在 st（steal time）指标上。另一方面，如果应用程序或内核模块存在激烈的锁竞争，也会导致进程在内核态长时间等待，推高负载，但不会显著增加用户态（us）或系统态（sy）的CPU时间。
在 top 命令的输出中，确认一下 st 值。如果持续大于1%，基本可判断是宿主机层面资源紧张，需联系云平台或虚拟化管理员检查宿主机的负载情况。
内核锁的竞争情况可通过查看锁统计信息来初步判断。执行 cat /proc/lock_stat | head -20，查看锁统计的摘要。重点关注 wait_total（总等待时间）和 wait_max（单次最大等待时间）比较高的锁名称。
如果系统默认没有启用锁统计，可以先执行 echo 1 > /proc/sys/kernel/lock_stat 来启用它，然后再重复上一步命令进行采集。
最后，别忘了检查cgroups的限制。执行 ls /sys/fs/cgroup/cpu/，看看是否启用了cgroups（无论是v1还是v2版本）。确认一下你的服务进程是否被放置在了某个有CPU配额（cpu quota）或份额（cpu share）限制的cgroup中，这种限制也可能导致进程在运行队列中排队，从而表现为高负载。
