第4章关键性能指标

4、关键性能指标：内存使用率、可用内存、缓存与缓冲区、内存泄漏指标

聊到内存监控，很多人第一反应就是看「内存用了多少」。嗯，这话没错，但太粗糙了。我见过不少运维新人，盯着内存使用率到 90% 就慌了，结果发现是缓存占了大头，虚惊一场。

所以这一章，咱们把几个核心指标掰开揉碎了讲。你搞懂了它们，告警规则才不会乱设，排查问题才能直击要害。

内存使用率，说白了就是「已用内存 / 总内存」。但这里的「已用内存」怎么算，大有讲究。

在 Linux 系统里，用 free -m 或者 /proc/meminfo 能看到好几行数据。我习惯看的是 used 这一列，但它其实包含了缓存和缓冲区。

核心公式：

实际内存使用率 = (总内存 - 可用内存) / 总内存 * 100%

这里的「可用内存」= 空闲内存 + 缓存 + 缓冲区。为什么这么算？因为缓存和缓冲区在系统需要时可以被回收，本质上还是「可用」的。

我在项目中遇到过一件事：某台服务器内存使用率飙到 95%，开发急得跳脚。我上去一看，cached 占了 60%，实际业务进程只用了 30% 左右。这就是典型的「假性内存紧张」。所以，我建议告警阈值不要只看 raw 的使用率，要结合 available 字段来判断。

可用内存（Available Memory）才是你真正该关心的指标。它表示在不触发 Swap 的情况下，系统还能分配给新进程多少内存。

为什么强调「不触发 Swap」？因为 Swap 一用，磁盘 I/O 就上来了，性能断崖式下跌。你想想看，内存是纳秒级，磁盘是毫秒级，差了三个数量级。

我的经验：

可用内存低于总内存的 10%，就该拉黄色告警了。低于 5%，直接红色告警，准备介入。我曾经有一回没设这个规则，结果凌晨三点被叫起来处理 OOM Killer，那滋味可不好受。

监控可用内存，推荐用 /proc/meminfo 里的 MemAvailable 字段。这是内核 3.14 之后引入的，比你自己手动算要准得多。

很多新手看到缓存（Cache）和缓冲区（Buffer）占用高就紧张。其实大可不必。

指标	作用	典型场景
Cache（页缓存）	缓存文件内容，加速读写	频繁读取的大文件、数据库查询
Buffer（缓冲区）	缓存块设备元数据	文件系统操作、磁盘 I/O 排队

说白了，Cache 和 Buffer 是 Linux 内核的「好心」。它把磁盘数据提前读到内存里，下次访问就快多了。你想想看，数据库服务器上 Cache 占个几十 GB 很正常，这是好事。

但要注意一个坑：如果 dirty 页（脏页）太多，说明磁盘写 I/O 跟不上。我曾经遇到过一台服务器，Cache 占满内存，但 dirty 页持续增长，最后导致系统卡死。嗯，这时候就要关注 /proc/meminfo 里的 Dirty 和 Writeback 字段了。

避坑指南：

我曾经因为没区分 Cache 和实际使用，把告警阈值设得太低，结果半夜告警响个不停。后来我改成用 available 作为主要指标，Cache 单独监控趋势，世界清净了。

内存泄漏是最难搞的问题之一。它不像 CPU 飙高那么明显，而是「温水煮青蛙」—— 内存一点点被吃掉，直到系统崩溃。

怎么监控？我总结了三个关键指标：

实用命令：

# 查看进程内存增长趋势（每 10 秒采样一次）
watch -n 10 'ps -eo pid,rss,comm --sort=-rss | head -20'

# 查看系统内存变化
vmstat 10 10

我个人习惯在 Prometheus 里配一个 process_resident_memory_bytes 的告警规则。如果某个进程的 RSS 在 1 小时内增长超过 20%，就触发警告。当然，阈值要根据业务特点调，不能一刀切。

还有一个容易被忽略的点：内核内存泄漏。比如 slab 缓存持续增长，用 slabtop 可以看。我遇到过一回，是某个内核模块的 bug 导致 dentry 缓存只增不减，最后只能重启解决。

小技巧：

如果你怀疑某个进程泄漏，可以用 pmap -x <PID> 看它的内存映射。重点关注 heap 段的大小，如果它一直在涨，基本实锤了。

好了，这四个指标搞明白，你的内存监控体系就有了骨架。下一章咱们聊聊怎么把这些指标落地到告警规则里，以及怎么避免「狼来了」式的误报。