为什么需要监控CPU与内存？
说实话，我刚入行那会儿，觉得监控就是个锦上添花的事。只要服务能跑，看一眼负载不高就完事了。结果有一次线上压测，流量一上来，CPU直接飙到 100%，然后整组机器都 hang 住了。我连问题在哪都找不到，因为根本没留下历史曲线。
那次教训让我明白——监控不是为了好看，是为了在出事之前能「看到信号」。CPU 和内存是系统的两大核心资源。CPU 不够，请求就排队，延迟飙升；内存不够，系统就会用 swap，性能直接跳水。你想想看，一个 2C4G 的云服务器，跑 Java 应用，内存用到 90% 以上，GC 频率翻倍，吞吐量掉一半——这都是我亲眼见过的。
所以，监控这两样东西，说白了就是回答三个问题：
- 资源还够不够用？
- 有没有异常消耗？
- 瓶颈在哪，该怎么调？
核心指标一览
指标很多，但真正常用的就那么十几个。我把常用的CPU和内存指标整理了一张表，方便你对照。
| 类别 | 指标 | 说明 | 我常用的命令 |
|---|---|---|---|
| CPU | CPU使用率 | user + system + nice + iowait + irq 的总占用百分比 | top, mpstat |
| Load Average | 1/5/15分钟的平均运行队列长度。超过CPU核数说明过载 | uptime |
|
| 上下文切换（context switch） | 每秒发生多少次进程/线程切换。太高说明锁竞争或线程数过多 | vmstat 1 |
|
| 中断（interrupts） | 硬件中断与软中断。网络包太多会导致软中断飙高 | cat /proc/interrupts |
|
| CPU Steal | 虚拟化环境下，宿主机偷走的时间。超过10%说明宿主机超分严重 | top 中的 %st |
|
| 内存 | 总内存 / 已用 / 可用 | 可用内存 = 空闲 + buffer/cache（可回收部分） | free -h |
| Buffer / Cache | Buffer是块设备缓存，Cache是文件页缓存。Linux会尽量用满来提升IO | free -m |
|
| Swap 使用率 | 一旦开始用swap，性能就会下降。建议关闭或把swappiness调低 | swapon --show |
|
| 缺页异常（page fault） | major fault（磁盘IO）和minor fault（内存分配）。major高说明频繁缺页 | sar -B |
dstat 来同时看CPU、内存、网络、磁盘，比分别开几个窗口方便很多。dstat -c -m -n -d 1 一秒一刷，很直观。
理解CPU使用率——别被数字骗了
很多人看CPU使用率只看一个数，比如 80%。其实这里头水挺深的。你用 top 看，会分成 us（用户态）、sy（内核态）、id（空闲）、wa（iowait）、st（steal）。
我记得有一次线上告警说CPU 90%，我跑上去一看，wa 占了 70%。那不是CPU不够用，是磁盘太慢了。程序在做大量随机IO，CPU都在等磁盘响应。你加CPU核数根本没用，得换SSD或者优化IO路径。
# 用 mpstat 看CPU分解，1秒一次
$ mpstat -P ALL 1
Linux 5.15.0-91-generic (host01) 03/21/2025 _x86_64_ (2 CPU)
10:21:30 CPU %usr %nice %sys %iowait %steal %idle
10:21:31 all 12.50 0.00 3.50 35.25 0.00 48.75
10:21:31 0 15.00 0.00 4.00 41.00 0.00 40.00
10:21:31 1 10.00 0.00 3.00 30.00 0.00 57.00看到没？%iowait 比 %usr 还高。这时你应该去查磁盘的 iops 和 await，而不是盯着CPU。
另一个容易踩的坑是 Load Average。很多人以为 Load 超过 1 就危险了。其实得看 CPU 核数。比如 8 核的机器，Load 跑到 6 都还算正常。如果不到核数的一半，基本上很轻松。我习惯用 uptime 看这三个数字，配合 CPU 使用率一起判断：
- 如果 load 高但 CPU 空闲率也高 → 很可能是在等 IO（iowait 高）
- 如果 load 高且 CPU 使用率也高 → 真的是计算密集型负载
- 如果 load 很高但CPU很低 → 大量进程在 D 状态（不可中断睡眠），查磁盘
理解内存使用——free 输出的坑
free -m 的输出，新手一般只看第二行「used」和「free」。但 Linux 的内存管理机制很聪明：它会尽量把空闲内存用作 cache，来加速文件读写。所以你看「free」列可能只有几百 MB，但实际系统并不缺内存。
应该看的是第二行 available 列。这个值才是真正可用的内存，包括可回收的 cache。如果 available 低于总内存的 10%～20%，就要警惕了。
$ free -h
total used free shared buff/cache available
Mem: 7.6G 2.1G 1.2G 124M 4.3G 5.1G
Swap: 2.0G 0B 2.0G这里 total 7.6G，free 只有 1.2G，但 available 有 5.1G。说明系统很健康，cache 占了 4.3G，随时可以释放。
另一个我特别关注的点是 swap。只要 swap 被用了，哪怕只有几十 MB，我都觉得是危险的信号。因为 swap 意味着内存不够，部分数据被换到磁盘上了。而磁盘速度比内存慢几个数量级，一旦访问到换出的页，就会产生 major fault，应用延迟瞬间升高。
sysctl vm.swappiness=1），让内核尽量不用 swap，除非逼不得已。对于数据库、缓存类的服务，我甚至直接 swapoff -a。
知识体系图：CPU与内存监控全景
下面这张图梳理了整个监控体系的脉络。你可以把它当作自己脑子里的一份地图——从应用层到底层硬件，每个环节都有对应的指标。
记住这张图，以后不管是排查 CPU 飙高，还是内存泄漏，你都能快速定位问题出在哪一层，然后去查看对应的指标。后面几节我们会逐步深入每个指标的使用方法和调优技巧。