真正决定内存是否耗尽的是free命令中的available字段，而非top的used或free值；available反映当前可立即分配给新进程的物理内存，而used包含可回收缓存，易造成误判。
别用 top 看内存是否“耗尽”——它显示的 used 值包含缓存，会严重误导你。 真正决定系统是否缺内存的，是 free 输出里的 available 字段，不是 used 或 free。
为什么 top 的内存数据不能直接判断内存是否不够用
top 第四行（KiB Mem）里 used 是总分配量，含内核缓存、slab、buffers 等，这些大多可被回收；free 又只算完全未用页，太保守。两者都不反映“此刻还能给新进程分配多少物理内存”。
常见误判场景：
- 看到
used: 1.5G / total: 2G就以为快爆了，其实available还剩 1.1G - 杀掉一个“高 %MEM”进程后系统反而更卡——因为清掉了它的缓存，触发大量磁盘读
-
top里%MEM排序只能看单个进程占比，但多个小进程合起来吃光available才是真瓶颈
free -h 怎么看才对：盯死 available 和 buff/cache
运行 free -h，重点只看两行：
-
Mem:行末的available—— 这是内核估算的、当前可立即分配给新进程的物理内存（已扣除不可回收 slab、page cache 中可回收部分等） -
buff/cache值高不等于有问题；只要available> 10%total，通常无需干预 - 如果
available持续低于 5%total，且swap used在增长，才是内存真正紧张的信号
示例输出片段：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
Mem: 1.8G 330M 813M 739M 1.4G
这里 1.4G 是 available（不是最后一列的 avail Mem 字样，而是第五列数值），说明还有充足余量。
top 里哪些字段真有用，哪些该忽略
top 不适合看总体内存水位，但对定位“谁在吃内存”很有效，前提是看对字段：
- 按
Shift+M排序后，优先关注RES（实际物理内存占用），不是VIRT（虚拟地址空间，含 mmap、swap、未分配页） -
%MEM是RES / total physical memory，仅作相对参考；RES绝对值（单位 KiB）才决定影响大小 - 忽略
SWAP列（旧版top可能有）——它显示的是进程 swap-in/out 速率，不是当前 swap 占用量 - 发现某个进程
RES异常高，再用cat /proc/<pid>/status | grep -E "VmRSS|MMUPageSize"</pid>确认是否真的泄漏
当 available 确实很低时，下一步查什么
不要急着 kill 进程或加 swap，先确认是不是缓存策略导致的假警报：
- 检查
/proc/meminfo中MemAvailable和Buffers、Cached、SReclaimable的关系，验证free的估算逻辑 - 运行
vmstat 1 5，看si/so（swap in/out）是否持续非零——这才是 swap 被真实使用的证据 - 用
smem -w查看各进程的USS（唯一驻留集），比RES更准地反映“独占内存” - 注意容器环境：
docker stats或cgroup的memory.current才是容器真实用量，宿主机top会失真
缓存机制本身是 Linux 的优化手段，强行 echo 3 > /proc/sys/vm/drop_caches 只会让后续 IO 更慢，除非你明确知道缓存内容已过期且不可再生。
