Linux内存分布查看，free-h命令详解

Linux内存使用分析中，真正反映系统真实压力的是free -h输出中的available字段，而非容易误导的used列——后者包含了可随时回收的buffers和cache，而available才代表能立即分配给新进程的物理内存；理解buff/cache的构成（如Cached正常、Slab或Shmem异常升高则需警惕）、厘清top/ps中RES总和远小于free used的原因（内核开销、共享内存、未释放页等），并按available→/proc/meminfo关键项→smem→tmpfs→OOM日志的路径精准排查，才能避免误判内存瓶颈、杜绝盲目清缓存或重启，从根本上解决“内存莫名耗尽”的顽疾。

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学习网公众号，一起学习编程~