生产环境排查 Linux 系统平均负载 Load Average 畸高但 CPU 使用率极低（D 状态进程阻塞）实战定位

一、背景与线上故障现象

在 Linux 生产服务器运维过程中，系统监控报警经常会遇到一种看似“矛盾”的异常现象：通过监控看板或 uptime、top 命令观察，系统的 1 分钟、5 分钟平均负载（Load Average）飙升到了几十甚至上百（远超 CPU 核心数），但同时观察 CPU 整体使用率（%Cpu(s)）中的 us（用户态）和 sy（内核态）均极低，总占用甚至不足 15%，且 CPU 的 id（空闲率）高达 80% 以上。业务层开始出现偶发请求超时、接口响应耗时陡增。

二、Linux Load Average 内核计算模型剖析

很多初学者容易将 Load Average 与 CPU 使用率画等号，但实际上在 Linux 内核调度体系中，二者有着本质区别：

1. CPU 使用率：反映的是 CPU 在指定采样时间段内，处于忙碌状态（执行进程指令、内核中断等）的时间百分比。

2. Load Average（平均负载）：反映的是在特定时间间隔内，处于可运行状态（Running，即 R 状态）和不可中断休眠状态（Uninterruptible Sleep，即 D 状态）的平均进程数总和。

其核心数学模型基于指数衰减加权移动平均，Linux 源码在 kernel/sched/loadavg.c 中实现：

active_tasks = count_active_tasks();
calc_load(load, exp, active_tasks);

关键在于：Linux 为了将磁盘 I/O、硬件等待等对系统吞吐能力的影响纳入考量，刻意将 TASK_UNINTERRUPTIBLE（D 状态）计入了负载统计中。当进程处于 D 状态时，进程通常在等待关键的硬件资源（如快速磁盘读写、NFS/SAN 存储网络响应、内存脏页刷盘或内核级信号量锁），内核为了防止驱动硬件处于不一致状态，不响应任何异步信号（包括 kill -9 亦无法终止）。一旦存在大量处于 D 状态的进程堆积，Load Average 就会异常飙升，而 CPU 却可能无事可做处于闲置。

三、生产环境全流程排查与定位实战

1. 第一步：快速确认当前系统中是否存在 D 状态进程

首先通过 vmstat 1 5 观察系统运行队列：

$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1 18      0 128452 489201 184512    0    0  8420   320 1200 3400  4  6 78 12  0

重点关注两列指标：

• r 列：表示正在等待 CPU 调度的进程数（R 状态）。若数值远小于 Load Average，说明负载主要不是由 CPU 计算密集任务引起。
• b 列：表示处于不可中断休眠的进程数（Blocked/D 状态）。若该值高达十几个甚至几十，且 wa（I/O 等待百分比）升高，即可 100% 确认是 I/O 或内核等待引发的 D 状态进程堆积。

2. 第二步：精准捕获所有处于 D 状态的进程清单

使用 ps 命令按进程状态进行过滤，并输出具体的进程 ID、命令名称及其父进程：

$ ps -eo state,pid,ppid,user,args | awk '$1 ~ /D/ {print $0}'
D   14285  1  root  /usr/bin/rsync -avz /data/backup/ /mnt/nfs_share/
D   14312  1  mysql [mysqld]
D   14389  1  root  sync

通过上述命令，可以直接锁定卡死在不可中断休眠状态的进程命令与 PID。

3. 第三步：读取进程内核调用栈（/proc/PID/stack）

要确定进程究竟在等待哪一步系统调用或驱动锁，最权威的手段是直接读取内核暴露的调用栈：

$ cat /proc/14285/stack
[<0>] nfs_wait_client_init_complete+0x42/0x80 [nfs]
[<0>] nfs4_proc_lookup_common+0x140/0x2c0 [nfsv4]
[<0>] nfs_lookup+0x7b/0x180 [nfs]
[<0>] path_openat+0x520/0x1030
[<0>] do_filp_open+0x9b/0x140
[<0>] do_sys_openat2+0x9b/0x160
[<0>] __x64_sys_openat+0x53/0x80
[<0>] do_syscall_64+0x33/0x80
[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xae

由上述内核调用栈清晰可见，rsync 进程在执行 openat 时，进入了 nfs_lookup，并阻塞在 nfs_wait_client_init_complete，说明后端的 NFS 存储服务端发生了网络断开或 RPC 超时无响应，客户端发起的系统调用挂起在内核层，进而累积了连锁反应。

四、常见成因归纳与线上无损处置方案

1. 网络挂载点（NFS/CIFS）失联：

• 若 NFS 服务端宕机或网络中断，客户端所有访问该挂载点的进程都会瞬间变为 D 状态。建议线上挂载时务必配置 soft,timeo=30,intr 参数，避免使用默认的 hard 无限阻塞等待。
• 若已经挂死，可尝试强制卸载：umount -l -f /mnt/nfs_share（延迟强制卸载）。

2. 物理磁盘 I/O 硬件坏道或只读卡死：

• 使用 dmesg -T | grep -E "I/O error|EXT4-fs error|xfs_error" 查看底层硬件总线状态。
• 若磁盘介质出现响应超时，I/O 请求在驱动层重试堆积，需及时将流量切换至备份实例并下线故障盘。

3. 内存回收与脏页回写阻塞：

• 当系统内存紧张且脏页占比过高时，新申请内存的进程会被迫进入直接内存回收（direct reclaim）及 congestion_wait 等待脏页写回，导致批量变为 D 状态。可通过合理调优内核参数 vm.dirty_background_ratio（建议 5-10）与 vm.dirty_ratio（建议 15-20），使脏页平滑异步刷盘，避免突发大 I/O 堵塞。

五、总结与防范规范

排查 Load Average 畸高而 CPU 空闲的生产故障，关键在于迅速破除“负载即 CPU 压力”的误区。遵循三步排查法：vmstat 确认 b 队列阻塞 -> ps 定位 D 状态进程清单 -> /proc/PID/stack 洞察内核等待点，即可快速切中要害，保障生产环境的高可用稳定运行。