这条路径解决什么
内存告警出现时，第一步不是清理，而是分清「真的不够用」还是「看着满其实可回收」：Linux 会把空闲内存用作页缓存，free 一列经常很低并不等于告急，要看 available。确认紧张之后，再按进程定位大户，最后判断是配置问题、泄漏问题还是被 OOM 终止后的现场。
基本信息
| 适用场景 | 内存告警、进程被 OOM 终止、系统开始换页 |
|---|---|
| 关键工具 | free、top、ps、pmap、smaps_rollup、vmstat、dmesg |
| 核心判据 | available 是否充足、是否发生换入换出（si 与 so）、是否有 OOM 记录 |
| 处置方向 | 限制单进程内存、调整数量与并发、必要时扩容；清理缓存通常不是解法 |
典型使用场景
- 整机内存告警：先看 available 与 swap 使用，判断是否真紧张
- 进程被突然终止：确认是不是被 OOM 杀掉的
- 排查内存泄漏：按时间多次采样同一进程的内存，看是否持续增长
- 容器与 JVM 场景：确认堆大小与容器限额是否匹配
- 救火处置：定位到具体进程后先限流或重启，再谈根因
快速判断
快速判断
free -m # 重点看 available，不要只看 free 列
top -b -n1 -o %MEM | head -15 # 按内存占用排序
ps -eo pid,pmem,rss,cmd --sort=-rss | head -10
vmstat 1 5 # 看 si 与 so 是否在换入换出深入单个进程
深入单个进程
pmap -x 1234 | tail -3 # 该进程的内存地址空间构成
cat /proc/1234/smaps_rollup | head # PSS 更贴近实际占用
cat /proc/1234/status | grep -E 'VmRSS|VmSwap|VmPeak'
cat /proc/1234/cgroup # 看它属于哪个 cgroup 限额确认是否被 OOM 终止
确认是否被 OOM 终止
dmesg -T | grep -i 'killed process' | tail -n 5
dmesg -T | grep -i 'out of memory' | tail -n 5
journalctl -k --since today --no-pager | grep -i oom | tail -n 20内存指标读法
| 指标 | 含义 | 怎么看 |
|---|---|---|
| total 与 used | 物理内存总量与已用 | used 含内核与共享部分，不直接等于进程占用 |
| free | 完全空闲的内存 | 数值低很常见，单独看不说明问题 |
| available | 估计可分配给新进程的内存 | 这才是判断是否紧张的依据 |
| buff/cache | 页缓存与缓冲区 | 可回收，不是泄漏 |
| VmRSS | 进程常驻内存 | 多进程共享的库会重复计入，偏高未必真占那么多 |
| PSS | 按比例分摊后的占用 | 多进程对比与容器计量更准确 |
| si 与 so | 每秒换入与换出量 | 持续非零说明内存确实不够用了 |
进程被突然终止且退出码为 137，通常意味着收到 KILL 信号，最常见来源就是内核的 OOM 终止器。用 dmesg 里带 killed process 的记录能看到被杀进程名与内存占用，这就是最直接的证据。
不要用「清缓存」（写 /proc/sys/vm/drop_caches）来应对内存告警：页缓存是可回收的，丢掉它只会让后续读写变慢，真正的问题仍在。同理，swap 使用率高但 si 与 so 长期为 0，通常只是早前换出后一直没换回来的页，不必紧张。