系统是否有压力需多指标交叉验证：若load average持续超cpu核心数、%iowait＞15%、available内存低于总内存10%，则可判定系统承压；load反映就绪队列长度，关键看与逻辑核心数比值；%wa高表明i/o等待而非cpu忙碌；内存压力看available和swap used，而非used字段；dstat可同步观测多维度指标关联性。
系统有没有压力，不是看单个数字高不高，而是多个指标交叉验证出来的。光看 top 里 CPU 90% 不一定真有压力，可能只是某个短时任务；但若同时 load average 超过 CPU 核心数、%iowait 持续 >15%、available 内存低于总内存 10%，那基本可以断定系统正在承压。
怎么看 load average 是否超标
负载值本身没单位，它反映的是“就绪队列长度”，即等待 CPU 或不可中断状态（如磁盘 I/O）的任务数。关键不是绝对值，而是和逻辑核心数比：
-
uptime或top第一行的load average: 2.45, 2.10, 1.88分别对应 1/5/15 分钟平均值 - 用
nproc查当前可用逻辑核心数（含超线程），比如输出8，那长期 >8 就算压力明显 - 注意：单核机器上
load >1就已排队；但多核下load=4对 4 核是满载，对 8 核只是 50% 利用率 - 如果 1 分钟值远高于 15 分钟值（如
5.2, 2.1, 1.9），说明压力是新近爆发的，不是持续积压
怎么区分 CPU 忙还是 I/O 等待忙
%us 和 %sy 高，说明程序或内核在干活；%wa（或 %iowait）高，说明 CPU 在干等磁盘或网络响应——这才是典型瓶颈信号：
- 在
top里按1展开所有核心，观察第三行的%Cpu(s): ... wa字段 - 用
mpstat -P ALL 1看每个核心的%iowait，某核心长期 >20% 且其他核心空闲，可能是该核心绑定了高 I/O 进程 -
vmstat 1中的wa列和io列（bi/bo）要一起看：如果wa高但bi/bo很低，可能是网络或锁竞争导致的伪等待 - 真正磁盘瓶颈还会伴随
iostat -x 1中的%util接近 100% 和await显著升高（>10ms）
内存压力不能只看 used
free -h 的 used 列会把缓存（buffers/cache）全算进去，误导性很强。真正关键的是 available 和 swap 使用：
-
available是内核估算的“可立即分配给新进程”的内存，低于总内存 15% 就该警惕 -
Swap:行中used不为 0 且持续增长，说明物理内存已不够，内核开始换出页——这是内存压力的硬证据 - 配合
vmstat 1看si（swap in）和so（swap out）：只要这两列非零且波动，就说明系统在频繁换页 -
cat /proc/meminfo | grep -E "^(MemAvailable|SwapTotal|SwapFree)"可绕过free的四舍五入，获取原始字节数
为什么 dstat 比单独用 top/iostat 更快定位问题
dstat 把 CPU、内存、磁盘、网络、上下文切换等维度压缩在同一时间轴上刷新，避免来回切窗口猜关联：
-
dstat -c -m -d -n -r --disk-util会并列显示各资源实时百分比，一眼看出是否“CPU 高时磁盘也在转”或“网络吞吐飙升时内存突然下降” - 当看到
cpu列wait高 +disk列util接近 100% +net列流量平稳，基本锁定是磁盘 I/O 瓶颈 - 如果
ctxt（上下文切换）列数值远高于正常值（比如 >50k/s），再结合pidstat -w 1查哪个进程在疯狂 fork/exit，往往指向配置错误的服务或死循环脚本 - 注意：
dstat默认不安装，CentOS/RHEL 用yum install dstat，Debian/Ubuntu 用apt install dstat
真正的压力诊断从来不是靠单个命令输出，而是把 load average、%iowait、available、si/so、await 这几个数字放在同一时间点对照——它们之间的关系比各自绝对值重要得多。漏掉任意一个维度，都可能把磁盘慢误判成 CPU 满，或者把内存泄漏当成临时缓存占用。
