linux服务器响应迟缓但cpu使用率不高时，本质是系统负载高而非cpu繁忙，需重点排查d状态进程、i/o等待（wa）、运行队列（r）、上下文切换（cs）及锁竞争等非cpu瓶颈。
如果您观察到Linux服务器响应迟缓、服务超时，但CPU使用率显示不高，则可能是系统负载过高所致。负载高并不等同于CPU繁忙，它反映的是等待运行或不可中断睡眠的进程数量。以下是针对该问题的多路径排查步骤：
一、理解负载平均值与CPU使用率的本质区别
系统负载（Load Average）是单位时间内处于可运行状态（R状态）和不可中断睡眠状态（D状态）的平均进程数；而CPU使用率仅统计CPU时间片的实际占用比例。二者数值无直接换算关系，高负载可能由I/O阻塞、锁竞争或进程排队引起，而非CPU计算密集。
1、执行 uptime 或 top 命令，查看第一行末尾的 load average 三个数值。
2、通过 grep -c 'model name' /proc/cpuinfo 获取逻辑CPU核心总数。
3、判断是否异常：若1分钟负载值持续大于CPU核心数，且wa、st指标未显著升高，则需进一步排查D状态进程或资源争用。
二、定位高负载根源——检查I/O等待（wa）与不可中断进程
I/O等待是导致负载升高却CPU空闲的最常见原因。当进程因磁盘读写、网络收发或设备驱动阻塞而进入D状态时，它们计入负载但不消耗CPU周期。
1、运行 top，观察%Cpu(s)行中的 wa 字段百分比。
2、若 wa > 5%，执行 iostat -x 1 3 查看各设备的await、%util及r/s、w/s指标。
3、执行 ps aux | awk '$8 ~ /D/ {print $0}' 列出所有D状态进程及其命令行。
4、对D状态进程执行 cat /proc/[PID]/stack 获取内核调用栈，确认阻塞点（如ext4_writepages、nfs_wait_on_request等）。
三、识别高负载进程——使用top命令精准排序与过滤
top命令默认按CPU使用率排序，但负载高时需关注进程数、线程数及运行队列长度，而非仅看%CPU。
1、启动 top 后，按下 1 键显示各CPU核心独立使用率，确认是否存在单核饱和。
2、按下 Shift+H 切换线程视图，使每行显示一个轻量级进程（LWP），便于发现多线程应用内部热点。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
3、按下 f 进入字段管理界面，启用 PGRP（进程组ID）、WCHAN（等待内核函数）和 TIME+（CPU总耗时）字段。
4、按下 O 键按WCHAN排序，快速识别大量进程阻塞在同一内核函数（如jbd2_log_wait_commit）的情况。
四、分析运行队列与上下文切换——定位调度瓶颈
运行队列过长（r值高）或上下文切换频繁（cs值高）表明内核调度压力大，常由大量短生命周期进程、线程竞争或锁争用引发。
1、执行 vmstat 1 5，观察输出中 r（运行队列长度）列是否持续大于CPU核心数。
2、检查 cs（context switch）列数值，若单秒超过10万次，需怀疑存在高频唤醒或自旋锁滥用。
3、执行 pidstat -w 1 5 获取各进程每秒任务切换次数（cswch/s）与自愿切换次数（vszch/s）。
4、对cswch/s异常高的进程，使用 perf record -e sched:sched_switch -p [PID] -g -- sleep 10 捕获调度事件并分析调用路径。
五、排查虚拟化偷取时间与内核锁竞争
在虚拟机环境中，st（steal time）过高说明宿主机CPU资源被其他虚拟机抢占；锁竞争则导致进程在内核态长时间等待，推高负载但不增加us/sy。
1、在 top 输出中确认 st 值是否大于1%，若是，联系云平台管理员检查宿主机负载。
2、执行 cat /proc/lock_stat | head -20 查看锁统计摘要，重点关注 wait_total 和 wait_max 较高的锁名。
3、启用锁统计功能（若未启用）：echo 1 > /proc/sys/kernel/lock_stat，再重复上一步采集。
4、执行 ls /sys/fs/cgroup/cpu/ 检查是否启用cgroups v1/v2，确认是否存在CPU配额限制导致进程排队。
