系统性能观测该不该用：先看它解决的问题是不是你的问题

load average 统计运行队列加不可中断睡眠，IO 卡住也会把它推高

它擅长的是定位变慢的根因；如果你只是容量规划，用现成的东西更省事。

先说结论

工具不缺，缺的是顺序：先确认是算、是等、还是被限流，再决定看哪个数

• 适合：定位变慢的根因
• 不适合：复现线上抖动
• 学习成本：iostat 的 %util 到 100% 不一定饱和，SSD 上要结合 await 和队列长度看
• 最大收益：vmstat 的 wa 高说明 CPU 在等 IO，这时候加 CPU 没有意义
• 最大风险：看 top 的 %CPU 超过 100% 以为中毒，其实是多核合计

它到底解决什么

load average 统计运行队列加不可中断睡眠，IO 卡住也会把它推高。

换句话说，它把「定位变慢的根因」这件事从手工变成可重复的流程。这是它真正的价值，而不是功能列表的长度。

什么时候不该用

下面三种情况，用了反而更累：

看 top 的 %CPU 超过 100% 以为中毒，其实是多核合计

用 %util 判断 SSD 饱和，结论经常是错的

在容器里跑 perf 没开 CAP_PERFMON，一直报权限错误

和替代方案比

free 的 available 才是可用内存，buff/cache 随时可以被回收。

这台工具的关键细节

几个决定长期体验的点：

• iostat 的 %util 到 100% 不一定饱和，SSD 上要结合 await 和队列长度看
• vmstat 的 wa 高说明 CPU 在等 IO，这时候加 CPU 没有意义
• pidstat -d 1 能按进程看读写，比 iotop 更适合脚本化采样

我的建议

工具不缺，缺的是顺序：先确认是算、是等、还是被限流，再决定看哪个数。

先用两周，跑一个真实的小任务；两周后你还想用它，再谈长期。

还有几处容易忽略的

都是小地方，但出问题时往往就卡在这里。

• load average 统计运行队列加不可中断睡眠，IO 卡住也会把它推高
• perf top 按周期采样，短于 1ms 的抖动基本抓不到，别拿它当证据

工具是解法，不是身份。