内存告警关键看available是否低于总内存10%及swap中so是否持续>0；free -h查available、buff/cache、swap used；htop按m键查高res进程；cat /proc/meminfo查sunreclaim判断内核泄漏；dmesg和vmstat验证oom与换页。
内存告警不是“用了多少”，而是“还能不能稳住新任务”。关键看 available 值是否持续低于总内存的 10%，以及是否已开始动用 swap（尤其是 so 持续 >0）。
快速定位：从 free -h 开始，盯紧三个数
执行 free -h 后，跳过 used 和 free 列，直接看：
- available：真正可分配给新进程的内存。若该值长期低于 500MB（小内存机器）或不足总内存 10%，说明实际可用资源紧张；
- buff/cache：这部分通常可回收，高不等于问题，但若 available 极低而 buff/cache 也同步萎缩，说明缓存已被大量挤占，系统已在强压状态；
- Swap used：只要非零且随时间增长，就表明物理内存已不够，系统被迫换页——这是性能拐点，必须干预。
追查元凶：按内存排序找活跃消耗者
运行 htop（没装可 yum install htop 或 apt install htop），按 M 键按 RES（实际物理内存占用）降序排列。重点关注：
- RES 超过 500MB 且长期不释放的进程；
- 同一服务多个实例（如 Java 应用）累计 RES 占比过高；
- 用户为 root 但命令名异常（如
curl、python、node等脚本类进程），这类常因逻辑缺陷导致内存缓慢爬升。
辅助命令：ps aux --sort=-%mem | head -10 可快速列出内存占用 Top10。
深挖内核层：确认是否内核对象泄漏
当 top/htop 显示用户进程内存正常，但 available 持续走低、Slab 占用飙升，需检查内核内存：
- 执行
cat /proc/meminfo | grep -E "^(Mem|Slab|SUnreclaim)"，关注 SUnreclaim 值（不可回收 slab）。若其超过 1GB 且随时间上涨，大概率存在内核对象泄漏； - 运行
slabtop -o（实时排序），观察 dentry、inode_cache、sock_inode_cache 等是否异常偏高； - 典型案例：旧版 curl + NSS 在高频 https 探测中会累积 dentry，不重启进程无法释放。
验证交换行为与OOM风险
内存告警常伴随 OOM Killer 启动，留下痕迹：