资源水位最直观、不易误判的指标组合是“负载均值 + 可运行进程数（r列）+ 不可中断进程数（D列）”，单看CPU使用率或内存使用率，几乎必然会在I/O瓶颈和短时尖峰上翻车。
linux 资源水位怎么看？先分清“能用”和“好用”
很多运维新手看服务器,第一个动作就是敲top，然后盯着%CPU那一栏发呆，CPU使用率80%算高吗？不算，30%算低吗？也不一定，问题出在CPU使用率只反映了计算单元忙不忙，完全没体现进程在等什么，一台服务器如果CPU使用率只有15%，但页面响应要3秒，你猜卡在哪？大概率卡在磁盘I/O或者网络等待上，CPU在空转等数据，这种状态在CPU%上根本看不出来。
行业内对“资源水位”有一个相对统一的观察口径：不是看某一项指标高不高，而是看请求进来后，系统能不能在合理时间内消化掉，能消化，水位再高也是健康水位；消化不了，哪怕CPU只有5%，也是危险水位，第一步不是选指标，而是先明确你的判断尺度。
- 能用：所有指标都在阈值内，页面能打开，接口能返回，但延迟已经开始波动
- 好用：负载平稳，请求被快速处理，任何一项资源指标上升到可疑位置时，能找到明确的原因
判断“好用”比判断“能用”难得多，这就是为什么需要一套不易误判的指标组合。
为什么 cpu 使用率最容易误判
行业共识认为,CPU使用率是所有监控指标里最容易被误读的一个，没有之一。
linux 看 cpu 还是 load average，结论不是二选一
“Linux看CPU还是负载”这个问题在百度上长期有人问，答案其实很清晰：两者都要看，但要以负载均值作为主要判断依据，CPU使用率适合看“瞬时变化”，比如代码上线后CPU突然从20%跳到90%，这能快速定位是哪个进程在作妖，但如果你拿它来判断整机水位，就麻烦了。
举个例子：一台4核服务器跑MySQL，磁盘是普通SATA盘，业务高峰期CPU使用率稳定在40%上下，看着很健康，但实际上磁盘队列已经堵到几十，SQL查询全在等I/O，此时如果你按CPU使用率去扩容，加再多CPU都没用，卡顿依旧，反过来，你加一块SSD，CPU使用率反而会升上去，因为查询不再等I/O了，这才开始真正干活。
CPU使用率低不是没事，CPU使用率高也不一定有事，判断资源水位，重心必须从“CPU忙不忙”转移到“系统有多少活儿没干完”上来。
多核场景下，负载均值要除以核数来看
load average是Linux内核维护的三个数字，分别代表过去1分钟、5分钟、15分钟的平均活跃进程数，注意，这里的“活跃”包含正在跑的进程和排队等待的进程。
单看负载数字没有意义,需要做一层换算：负载均值 ÷ CPU核数，比值在0.7以下属于健康水位；在0.7到1.0之间属于临界区，开始有排队；超过1.0意味着任务量已超过CPU处理能力，队列开始积压。
有个细节容易踩坑：不同云厂商的ECS（云服务器）实例，核数不一定等于你买时的vCPU数，部分超卖实例的CPU带宽有限，跑高负载时会限流，业内专家指出，排查资源水位前，先用lscpu确认真实核数，再看负载，否则容易误判。
对于运行数据库、消息队列这类有状态服务的机器，5分钟和15分钟负载值比1分钟值更值得关注，1分钟负载高，可能只是定时任务拉起的瞬时尖峰；5分钟、15分钟都高，才是真问题。
短时尖峰，别急着下结论
运维的人都有这种经历：某天下午CPU飙到100%，你赶紧上去查，登录到服务器上发现已经掉下来了，一切正常，这就是短时尖峰，负载均值1分钟值会快速响应这种变化，但如果你用top去抓现场，往往抓到的是“事后现场”。
正确的做法是看负载的趋势组合：
- 1分钟负载 > 5分钟负载，且5分钟负载 > 15分钟负载，说明负载在爬坡，任务正在堆积
- 1分钟负载 < 5分钟负载，且两个值都偏高，说明高峰已经过去，系统正在消化积压任务
- 三个数值都差不多高,且都超过核数，说明系统已经持续过载很久，不是偶发尖峰
这比查看单个时刻的CPU使用率要稳得多,CPU使用率的瞬时波动受采样间隔影响很大，采样1秒和采样5秒，看到的最大值能差出一倍去。
| 指标 | 直观性 | 误判风险 | |
|---|---|---|---|
| CPU使用率 | CPU计算单元忙闲 | 高 | 高（忽略I/O等待） |
| load average | 活跃任务排队总量 | 中 | 中（需除以核数） |
| r列（可运行进程数） | 正在等待CPU调度的任务数 | 高 | 低 |
| 行（不可中断进程数） | 卡在I/O上的任务数 | 高 | 低 |
三个指标配合，才能定位瓶颈方向
Load average回答“系统堵不堵”，r列回答“是不是CPU不够”，D列回答“是不是I/O卡住”，三者配合，才是完整的水位判断逻辑。
用 vmstat 区分 cpu 忙还是 io 忙
vmstat是判断资源水位的核心工具，比top更直接，常用命令是vmstat 1 5，每1秒采样一次，采样5次，重点看输出里的三列：
- r：运行队列长度，代表正在等待CPU调度的进程数
- b：阻塞进程数，一般指等I/O的进程，正常情况下应该接近0
- wa：CPU等待I/O所花的时间占比
一个经典判断场景：r列数值长期超过核数，说明CPU调度不过来，看wa通常是0或者很低，CPU核心在处理计算任务，这就是
纯CPU瓶颈；如果r列不高，但b列有值且wa高于20%，说明进程全堵在I/O阶段，CPU在空转，这就是I/O瓶颈。
注意,vmstat输出的wa是个平均值，对于多核机器，某一核wa高、其他核正常，不代表整机I/O有问题，需要再结合pidstat -d 1看看具体是哪个进程在等待块设备。
进程状态 D 和 R，比单纯看百分比更直接
top里进程状态这一列很多人直接忽略，其实它是资源水位的实锤证据。
- R（Running）：进程正在CPU上运行，或在运行队列里等待，R状态进程数持续大于CPU核数，就是CPU过载
- D（Uninterruptible Sleep）：不可中断睡眠，通常是进程在等磁盘I/O，D状态进程数长期大于0，说明I/O子系统有瓶颈
D状态是个容易误读的点,少量D状态进程出现是正常的，MySQL刷脏页、Kafka落盘都可能短暂D住，但如果D状态进程数长期超过核数的一半，且负载均值持续走高，那基本可以断定是I/O带宽或者存储延迟的问题。
还有一种更隐蔽的情况：CPU使用率高，同时D状态也高，这往往发生在存储服务上，比如本地SSD带宽被打满，正在读数据的进程显式地占用CPU做校验，另一部分进程等在I/O上，这时只看任何一个指标都会得出错误结论，必须看组合。
采样时长决定判断是否误判
很多监控系统默认采样周期是30秒甚至5分钟一次,对于水位判断来说，间隔太长，系统负载在几十秒内剧烈波动是常态，你采到一个峰值，可能就是一次全链路超时的导火索。
实操上给一套参考步骤：
- 先跑
uptime，看1分钟、5分钟、15分钟负载值，建立基线 - 紧接着跑
vmstat 1 10，连续采样10秒，确认r列和b列的真实水平 - 再用
top -bn1 | head -20，快照一次进程状态，统计R和D的数量 - 最后用
pidstat -d 1 3，定位哪个进程在消耗I/O
这套命令组合执行下来,误判率比单看top的CPU%低很多，但要注意：如果服务器已经卡到命令都敲不进去，说明问题已经很严重，这时候优先重启慢查询或者停掉大查询，而不是继续采样。
吞吐量上不去是哪些指标在拖后腿
这是排查资源水位时最常见的一个反推场景,某个服务性能测试，并发一上来，吞吐量就卡在一个台阶上不去，这时候逐项排查指标，才能还原全局。
线程池打满但负载不高？看上下文切换
Java应用线程池满了,接口超时，但top看CPU使用率不高，负载也不高，这时候容易误判为“系统很闲，是应用层的问题”，实际用vmstat看cs（上下文切换）列，如果数值异常高，比如每秒几十万次，说明线程在疯狂切换，CPU时间都耗在调度上，没干正事。
继续用pidstat -w 1可以看到某个进程每秒的主动上下文切换次数，定位到具体线程，这种问题加机器没用，要么调大线程池，要么减少锁竞争，要么换协程。
磁盘io饱和但cpu使用率不高？看await
MySQL实例性能下降,一堆慢查询，此时CPU使用率不到40%，load average（或平均负载）却顶到核数附近，用iostat -x 1看%util和await：
%util接近100%，但await只有几毫秒，说明设备本身忙，可能是持续小IO压榨了IOPS%util不算高，但await几十毫秒甚至更高，说明设备本身有延迟问题，比如磁盘坏道、RAID重建、或者云盘底层的邻居“吵闹”
这种情况下,调整vm.dirty_ratio和vm.dirty_background_ratio内核参数，可以缓解部分写放大问题，但对读延迟明显的情况没什么用，只能考虑本地盘还是网络盘的选择。
大量短连接，负载值虚高？看r列分布
如果服务器部署了高并发的短连接服务,比如Nginx直连PHP-FPM，你会看到负载值被拉得很高，但进程状态大部分是S（睡眠），这时候负载均值虚高的概率不小因为每个请求进来都会创建一个临时的活跃进程，请求处理完就退出，虽然都是“活”，但每一个都只干了一瞬间的活。
这种情况下,r列反而比较稳定，因为在任意时刻真正排队等CPU的进程并不多，判断依据应该是“每秒钟完成的请求数×平均响应时间”这个业务指标，而不是盯着负载值，这也是为什么一直强调“组合指标”：负载值高不一定等于CPU不够，它也可能只是说“任务切换很频繁”。
Q&A：资源水位怎么看？三个高频误区解答
负载均值超过核数，一定代表CPU不够用吗？
不一定，负载均值涵盖所有“活跃”任务，包括等I/O的任务，如果r列（可运行进程数）接近核数，b列（阻塞进程数）明显大于0，说明CPU还没饱和，I/O才是瓶颈，先看r列与b列的比例关系，再下结论。
CPU使用率只有10%，但接口延迟很高，该查什么？
先查vmstat 1 5的wa列和b列，再做iostat -x 1看磁盘await和%util，大概率是I/O等待把CPU的空闲时间消耗光了，如果磁盘正常，再排查网络延迟和线程池配置，CPU使用率低，但请求排队，通常是资源被某个环节阻塞住了，而不是计算单元空闲。
监控面板上用什么指标做告警最不容易误报？
不建议用CPU使用率单指标告警，用负载均值除以核数的比值作为主告警，配合r列和D列数量作为辅助判断，比值连续5次采样超过1.0，且r列持续高于核数，才触发告警，如果只看CPU使用率，wa偏高但CPU计算并不繁忙的场景下，会漏报。