Linux服务器CPU负载过高如何排查？top命令使用技巧【详解】

服务器响应变慢，服务时不时超时，一看监控，CPU使用率却不高？这种情况在运维排查中其实挺常见的。问题的核心往往不在于CPU本身“忙不忙”，而在于系统的“负载”太高了。负载高和CPU繁忙是两码事，它反映的是那些等着运行或者因为某些原因（比如等磁盘I/O）而“卡住”的进程数量。下面，我们就来系统地梳理一下，当遇到这种“高负载、低CPU”的诡异状况时，应该从哪几个方向入手排查。

一、理解负载平均值与CPU使用率的本质区别

首先得厘清一个基本概念：系统负载（Load A verage）和CPU使用率到底在衡量什么。负载平均值统计的是单位时间内，处于可运行状态（R状态，就绪等着被CPU调度）和不可中断睡眠状态（D状态，通常是在等待I/O操作完成）的平均进程数。而CPU使用率，仅仅是CPU时间片被实际占用的比例。这两者之间没有直接的换算公式。一个系统负载很高，完全可能是因为大量进程在排队等待磁盘读写（I/O阻塞）、争抢同一把锁，或者单纯就是进程数太多调度不过来，而不是CPU在进行密集计算。

排查的第一步，通常是执行 uptime 或 top 命令，看看第一行末尾的 load a verage 三个数值（分别代表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），对于分析Ja va、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中，这种限制也可能导致进程在运行队列中排队，从而表现为高负载。