Linux系统资源压力指标查看及监控方法全攻略

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