linux负载值（如2.45, 2.18, 1.92）表示过去1、5、15分钟处于可运行或不可中断睡眠（d状态）的平均进程数，反映系统资源排队压力，需结合cpu核心数判断是否过载。
Linux uptime 和 top 显示的三个负载值到底代表什么
这三个数字（如 load average: 2.45, 2.18, 1.92）不是 CPU 使用率，而是过去 1、5、15 分钟内处于可运行状态或不可中断睡眠状态（D 状态）的平均进程数。它反映的是系统“排队等资源”的压力程度。
关键判断基准是逻辑 CPU 核心数（nproc 或 lscpu | grep "^CPU(s)"）。若 5 分钟负载长期 > 核心数 × 1.5，说明系统已明显承压；> 核心数 × 3 通常意味着严重排队，需立即排查。
-
uptime最简快看，但无进程细节 -
top实时刷新，默认按 CPU% 排序，按Shift+L可显示负载行，按1可展开各 CPU 核心使用率 - 注意：负载高 ≠ CPU 高——I/O 等待（如磁盘卡顿）、大量 D 状态进程（如 NFS 挂载卡死）也会推高负载
用 ps 和 pidstat 找出吃掉负载的罪魁进程
单纯看 CPU% 容易误判。真正拖高负载的，往往是那些频繁创建子进程、卡在 I/O 或锁上、或陷入 D 状态的进程。
先筛 D 状态进程（最可疑）：ps aux | awk '$8 ~ /^D/ {print $0}'
再看哪些进程产生最多新线程/进程：ps -eo pid,lwp,nlwp,%cpu,%mem,args --sort=-nlwp | head -10（nlwp 是线程数）
-
pidstat -w 1：每秒输出进程上下文切换（cswch/s）和任务创建（proc/s）次数，异常高的进程要重点查 -
pidstat -d 1：看 I/O 等待（%iowait）和读写速率，确认是否磁盘瓶颈 - 注意：容器环境里，宿主机看到的 D 进程可能来自某个失控的容器，需结合
docker ps -q | xargs docker inspect --format='{{.Name}} {{.State.Status}}'关联排查
iostat 和 iotop 确认是不是磁盘 I/O 拖垮了负载
当 top 中 %wa（I/O wait）持续 > 20%，或 pidstat -d 显示某进程 rkB/s 或 wkB/s 异常高，基本可锁定 I/O 问题。
用 iostat -x 1 关注关键指标：%util > 90% 表示磁盘几乎满负荷；await > 50ms（机械盘）或 > 10ms（SSD）说明响应延迟大；avgqu-sz 长期 > 1 表示队列积压。
-
iotop -o直接列出当前正在做 I/O 的进程和速率，比ps更直观 - 注意：某些 RAID 卡或 NVMe 设备在
iostat中可能显示为多个设备（如nvme0n1p1,nvme0n1p2），需整体看nvme0n1汇总项 - 临时缓解可用
ionice -c 3 -p <pid></pid>降低进程 I/O 优先级，但治标不治本
排查中容易被忽略的底层因素
负载高却找不到明显耗资源进程？可能是以下隐蔽原因：
- 内核模块或驱动 hang 住，导致大量进程卡在 D 状态（如旧版
qla2xxx光纤卡驱动在链路抖动时会触发） - 内存严重不足引发频繁 swap，
swapon --show+vmstat 1看si/so列是否持续非零 - 文件系统元数据锁争用（如 ext4 在大量小文件并发 create/unlink 时），
cat /proc/fs/ext4/<device>/stats</device>查discard或lock相关计数突增 - 容器或虚拟机内核参数未调优，如
vm.swappiness=0在 K8s 节点上反而加剧 OOM 压力，需结合 workload 类型评估
负载本身不报错，但它是系统失衡的第一个通用信号。盯住它背后的真实状态——是 CPU、内存、磁盘、网络，还是内核态的某种等待——才能真正止住恶化。
