应关注 available 而非 used：available 持续低于物理内存 10% 且伴随服务变慢、oom killer 日志时才需干预；否则属内核缓存正常占用，无需处理。
先看 available，别被 used 吓到
Linux 显示内存“爆了”，往往只是 used 高但 available 充足 。内核会把空闲内存自动用于 page cache、dentries、inodes 等缓存，这部分随时可回收，属于“聪明的占用”。真正要警觉的是：available 持续低于物理内存的 10%，同时伴随服务变慢、响应延迟、SSH 卡顿或日志里出现 Out of memory: Kill process。此时才需介入。如果 free -h 中 available 还有几 GB，swap 未启用，dmesg | grep -i "killed process" 无输出，那大概率是系统在高效工作，不用管。
定位真实吃内存的进程
用对命令才能抓准问题：
-
top→ 按 Shift+M 按 RES（实际驻留内存）降序排列，重点关注 RSS 长期上涨、不回落的进程 -
htop（推荐安装）→ 支持鼠标、颜色高亮、树状视图，更易识别子进程风暴（比如几百个lftp或curl） -
ps aux --sort=-%mem | head -10→ 快速列出内存占比前 10 的进程 - 对 Java/Python/Go 服务，单看 %MEM 不够，要结合
pmap -x [PID]看 anon-rss（堆 / 栈）、jstat -gc（Java GC 情况）或go tool pprof（Go 堆分析）
别漏掉内核态内存泄漏
当 ps 和 top 找不到大户，但 Slab 或 SReclaimable 占比异常高（比如占总内存一半以上），就要查内核侧：
-
cat /proc/meminfo | grep -E "^(Slab|SReclaimable|PageTables|Mapped)"→ 快速定位增长项 -
slabtop -o→ 按活跃对象排序，重点盯dentry、inode_cache、ext4_inode_cache -
lsof +L1或find /proc/*/fd -ls 2>/dev/null | grep deleted→ 查看是否大量已删除文件仍被打开（常见于探测脚本、旧版 curl/NSS bug） - 确认是否为已知缺陷：如
curl 7.19.7 + NSS组合存在 dentry 泄漏，可通过设置NSS_SDB_USE_CACHE=1临时修复
治理与长期防控
找到根因后，处理要有层次：
- 临时缓解：仅限应急，
echo 3 > /proc/sys/vm/drop_caches（需 root，且效果短暂，不解决根源） - 优雅处置：优先发
SIGTERM终止可疑进程；避免直接kill -9，尤其对数据库或有状态服务 - 配置约束：用
systemd的MemoryMax=限制单服务内存上限；或启用 cgroups v2 实施资源隔离 - 监控前置：部署
Prometheus + node_exporter，采集node_memory_MemAvailable_bytes和process_resident_memory_bytes，设可用内存 - 定期巡检：对长期运行的服务，加入内存趋势基线比对（如每周同时间点 RSS 增幅超 15% 自动标记）
