系统是否真正面临压力，不能仅凭单个数值高低判断，而需要通过多个指标交叉验证。例如，在 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 满，或者把内存泄漏当作临时缓存占用。
