Linux内存查看命令free-h详解指南

Linux内存使用常被误解，关键在于认清“used”并非真实压力指标——它错误地将可随时回收的buffers和cache计入已用内存，而真正反映系统可用性的核心指标是“available”，即能立即分配给新进程的物理内存；本文深入解析free -h输出各字段含义，澄清buff/cache高不等于内存泄漏、top中RES总和远小于used的根源，并给出从available预警、/proc/meminfo细查、smem精准归因到tmpfs/Slab排查的完整诊断路径，帮你告别盲目清缓存和误杀进程，科学定位真正的内存瓶颈。

free -h 输出里哪些字段真正反映“已用内存”

Linux 的 free -h 输出中，used 列**不是**你该盯着看的“真实已用内存”。它把内核缓冲区（buffers）和页缓存（cache）全算进去了，而这两部分在应用需要时能被立刻回收——它们是“可释放的占用”，不是“死占着不放的占用”。

真正反映系统压力的是：

• available：估算出的、能立即分配给新进程的物理内存。这个值低于总内存的 10% 就该警觉
• MemFree（来自 /proc/meminfo）：纯空闲页，通常极小，单独看意义不大
• SwapUsed > 0 且持续增长：说明物理内存确实不够，内核已开始换出内存页

例如：total=16G, used=12G, free=240M, available=5.2G —— 这不是内存快爆了，而是 Linux 正常利用了 6–7G 做 page cache，实际还有 5.2G 可用。

buff/cache 列高 ≠ 内存泄漏，但要区分类型

buff/cache 是两块内容的合集：Buffers（块设备临时缓冲）和 Cached（文件页缓存），但 free 不拆开显示。想细看，得查 /proc/meminfo：

• Cached 高：正常，尤其是频繁读写文件或数据库服务时，内核主动缓存热数据
• Slab 或 SReclaimable 异常高（比如 >2G）：可能是内核对象（如 dentry/inode）缓存堆积，常见于大量小文件目录操作
• Shmem + Shared 高：检查是否有大量 tmpfs 使用（如 /dev/shm、Docker overlay 元数据）

别一看到 buff/cache=8G 就去 echo 3 > /proc/sys/vm/drop_caches——这会强制清掉所有缓存，反而导致后续 I/O 变慢，只应在诊断或压测中临时使用。

为什么 top 和 ps 看到的 RES 总和远小于 free 的 used

这是最常让人困惑的点：ps aux --sort=-%mem 或 top 里所有进程的 RES（常驻内存）加起来可能只有 3G，但 free 显示 used=10G。差额主要来自：

• 内核自身占用（Slab, PageTables, KernelStack 等），不归属任何用户进程
• 共享内存段（Shmem）、tmpfs 文件系统（如 /run, /dev/shm）
• 未映射但尚未归还的内存页（如进程刚 exit，页还未被回收）
• 某些驱动或模块（如 NVIDIA GPU 驱动）预分配的显存映射区域

用 smem -w 可以看到更准确的内存归属，它按 USS（独占）、PSS（共享分摊）统计，比 ps 的 RSS 更接近真实消耗。

排查“内存莫名耗尽”的关键路径

当 available 持续走低、SwapUsed 上升、机器变卡，按这个顺序查：

• 先跑 free -h && cat /proc/meminfo | grep -E "^(MemAvailable|Cached|Slab|Shmem|SReclaimable)"，确认是不是 Cached 没涨但 Slab 或 Shmem 异常高
• 再用 ps aux --sort=-rss | head -10 和 smem -s rss -r | head -10 对比，看是否某进程 RSS 持续上涨（典型内存泄漏）
• 检查 ls /dev/shm 和 df -h -t tmpfs，确认有没有大文件塞在 tmpfs 里
• 最后看 dmesg -T | grep -i "out of memory\|kill process"，确认是否触发过 OOM killer

很多“内存耗尽”问题其实卡在 Slab 或 tmpfs，而不是应用本身；忽略这点直接杀进程或重启服务，往往第二天又复现。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。