看清真正可用内存应看free -h的available值，它已扣除不可回收部分；查内存大户优先用smem的pss而非ps的rss，避免共享库重复计算。
怎么看清“真正可用”的内存，而不是被缓存骗了
Linux 会把空闲内存自动用作 buff/cache（缓冲区和页缓存），所以 free 输出里的 free 列数值低 ≠ 内存紧张——它只是“没被分配”，不是“不可用”。关键看 available 字段，它是内核估算的、能立刻给新进程用的内存（已扣减不可回收部分，含可释放缓存）。
-
free -h是第一反应命令，输出中优先盯住Mem行的available值；如果它低于总内存的 10%，才真要警惕 - 别信
used = total - free这个算式——used包含了大量可回收缓存，直接减会高估压力 - 如果
available很小但buff/cache很大，大概率是正常行为；除非同时出现Swap used > 0且持续上涨，那才是物理内存确实不够了
怎么快速揪出吃内存的进程，而不是在 top 里瞎翻
top 默认按 CPU 排序，按 M（大写）才能按内存排序，但它的 RES（常驻内存）字段容易受共享库干扰；htop 更直观，支持鼠标点列头排序、树状视图、颜色高亮，装一个省半小时。
- 终端执行
htop，按F6→ 选PERCENT_MEM→ 回车，直接按内存占用百分比降序 - 若不能装
htop，用ps aux --sort=-%mem | head -10快速列出前 10 名，注意看%MEM和RSS（单位 KB），避免只看VIRT（虚拟内存，可能包含未分配空间） - Java/Python 进程
RSS持续缓慢上涨？不一定是泄漏——检查 JVM 的-Xmx或 Python 的ulimit -v是否设得过大，导致内存“占着不用还涨”
/proc/meminfo 里哪些字段真有用，哪些只是干扰项
/proc/meminfo 是所有内存工具的数据源，但字段太多，90% 场景只需关注几个：
-
MemAvailable：和free -h的available一致，是判断是否缺内存的黄金指标 -
Active(file)/Inactive(file)：区分正在活跃使用的缓存 vs 可随时回收的缓存；如果Inactive占比高，说明缓存很“干净”，系统没压力 -
Slab和SReclaimable：前者是内核对象缓存总大小，后者是其中可回收的部分；若Slab高但SReclaimable低，可能是 dentry/inode 缓存堆积（尤其小文件多的 NFS 或容器场景） - 别纠结
MemFree——它几乎永远很小，意义有限；也别一看到SwapCached就慌，它只是 swap 页被重新读入内存后缓存的副本，不等于正在换入换出
为什么 smem 比 ps 更准，什么情况下必须用它
ps 的 RSS 把共享库内存全算给每个进程，比如 20 个 Java 进程共用同一套 JVM 库，ps 会重复计算 20 遍；smem 用 PSS（Proportional Set Size）按比例分摊，更真实反映单个进程实际“净占用”。
- 安装后运行
smem -s pss -r | head -10，看谁真正拖垮内存；USS（独占内存）则适合定位纯泄漏——只增不减的进程 USS 持续涨，基本就是泄漏 - 对比
ps aux --sort=-rss | head -5和smem -s pss -r | head -5，常发现排名完全不一样：数据库连接池进程RSS高但PSS低，而某个 Python 脚本RSS中等但PSS突出——这才是真凶 -
smem依赖/proc/PID/smaps，某些容器或安全加固环境可能禁用该接口，此时会报错或缺失数据，得切回ps+top组合
最常被忽略的其实是 available 和 PSS 的组合判断：前者告诉你“系统还剩多少弹药”，后者告诉你“谁在偷偷多领弹药”。光看一个，容易误判成内存泄漏，或者放任真实问题恶化。
