搞懂 Linux 内存使用情况这件事，看着简单，实际坑不少。free命令谁都会敲，但真到了线上内存告警、服务被 OOM Kill 的时候，很多人对着free -h的输出愣是说不清到底哪儿不够用，是程序泄漏了，还是被缓存吃了，该不该清，清了会不会出事。这篇文章不打算做成命令手册，我就按实际排查的思路，把常用的几个查看内存的命令、输出里每一列的真实含义、还有那些文档里不会写的坑，一次讲透。
1. 先搞清楚一件事：Linux 内存到底该怎么“看”
很多人第一次接触 Linux 内存，是被 Windows 的习惯带偏的。Windows 的任务管理器里可用内存少了就觉得紧张，但在 Linux 上，free显示的内存被“用掉”一大半，往往是正常的，因为 Linux 的理念是“内存闲着也是闲着，不如拿来当缓存”。这就导致一个经典场景：新人跑完free -h，看到 used 占了 90% 多，吓得以为机器快挂了，其实系统稳得很。
我看内存的第一步，永远不是记参数，而是先明确三个概念：物理内存、虚拟内存、以及内核视角里的“缓存”。物理内存就是硬件条子，虚拟内存是进程眼里能看到的地址空间，跟物理内存没有一一对应关系，而缓存是内核把磁盘上的数据读进内存后留下的副本，目的是下次访问更快。这三个概念混在一起，看free输出就会一头雾水。
第二个要建立的习惯，是看“可用内存”而不是“剩余内存”。free命令输出里的available列才是真正能反映系统还能扛多少新程序的指标，它把可回收的缓存也算进去了。只看free列（真正的空闲内存）往往低估系统的承载能力，这在后面会详细拆解。
所以这篇文章的核心思路是：先把free命令每个字段的含义讲明白，再带你用top、vmstat、ps、smem这些工具做交叉验证，最后给出一套排查内存问题时的实操流程。这样你在任何一台 Linux 机器上，都能快速回答三个问题：内存够不够、是谁在吃内存、要不要干预。
2. free 命令背后的原理与字段解读
2.1 free 输出里每列每行都代表什么
free命令是最直接的内存查看工具，几乎所有发行版都自带。不加参数时默认以 KB 为单位显示，我习惯先跑free -h看一个概况，再跑free -m拿到整齐的 MB 数值。
$ free -h total used free shared buff/cache available Mem: 31G 5.2G 1.1G 245M 24G 25G Swap: 7.5G 0B 7.5G第一行 Mem 是物理内存。total 是机器物理内存总大小，但这个值并不等于你买的内存条容量，内核、固件、显存映射会占掉一部分，比如 32G 的机器 total 显示 31G，这是正常的。used 是内核统计的已使用内存，这里有个容易踩的坑：不同版本的free，used 的计算方式不一样。旧版 used 包含 buff/cache，新版（procps-ng 3.3.10 之后）used = total - free - buff/cache，也就是说缓存不计入 used。这就是为什么同样一台机器，在不同发行版上看到的 used 差很多。
shared 列是 tmpfs、共享内存这些占用的量，多进程共享的内存会重复计入这里。buff/cache 是最容易让新手误判的一列，它是块设备缓冲（buffer）和页缓存（page cache）的合并值。简单理解，buffer 是内核为块设备写的缓冲，比如你往磁盘写数据，会先攒在 buffer 里；cache 是读文件时留下的页缓存。这俩在现代内核里界限没那么清晰，free直接合并展示，我们也可以把它当作“内核能帮你回收的缓存”。
available 列才是真正回答“还能跑多少程序”的关键。这个值是一个估算，大致思路是 free 内存加上大部分可回收的缓存。它是从/proc/meminfo里的 MemAvailable 读出来的，内核会根据当前内存压力和回收成本动态估算。对于 2.6.27 之前的老内核，没有 MemAvailable，free会自己估一个值，但这种老内核在 2025 年的生产环境里几乎看不到了，不必太纠结。
第二行 Swap 是交换分区/交换文件的使用情况。Swap 是把磁盘空间当内存用的机制，进程内存不够时会先把不活跃的内存页换出到磁盘。Swap 被大量使用通常说明物理内存真的不够了，但有时候是内核的swappiness参数太激进导致的，默认 60 意味着内核有可能在物理内存还有富余时就开始换出，这在后面章节里单独讲。
2.2 常用参数组合与单位换算技巧
free的参数很简单，但有几个组合我建议你直接记死。
# 最常用：以 MB 显示，适合日常观察 free -m # 以 GB 显示，适合大内存机器 free -g # 以人类可读方式显示，适合给同事截图 free -h # 持续刷新查看，观察变化趋势 free -s 3 # 组合使用：每 3 秒刷新一次，以 MB 为单位 free -s 3 -m如果你是在写脚本，我强烈建议别用-h，因为对人类友好的输出对脚本不友好，不同版本的单位缩写还可能不一样。稳妥的做法是free -m（或free -k）固定单位，然后用 awk 或 grep 提取数值。举个例子，我想拿到当前可用内存占总量百分比：
free -m | awk '/Mem:/ {printf "%.1f%%\n", $7/$2 * 100}'这里的 $7 对应 available，$2 对应 total。写脚本时先跑一次free -m确认字段顺序，不同版本字段顺序有差异，我吃过亏，后来干脆直接解析/proc/meminfo，这个文件是系统给所有内存信息的原始来源，free也只是它的一个格式化展示：
grep -E '^(MemTotal|MemFree|MemAvailable|Buffers|^Cached|SReclaimable|SwapTotal|SwapFree)' /proc/meminfoMemTotal对应总内存，MemAvailable对应 available，Buffers加Cached加SReclaimable大致就是 buff/cache。SReclaimable 是内核 slab 分配器里可回收的部分，主要是 dentry 和 inode 缓存，这部分在排查内存问题时很重要，但free不会单独展示，看/proc/meminfo才能看到它和不可回收的 SUnreclaim 的区别。
2.3 那些“教你清理 buff/cache”的说法为什么我劝你慎用
网上搜 Linux 内存优化，一定会搜到一群人教你：
sync echo 3 > /proc/sys/vm/drop_caches执行完确实 buff/cache 大幅下降，free 显示内存“变多了”，然后弹冠相庆。但我要说，这在绝大多数生产场景下是帮倒忙。
先明白 drop_caches 到底干了什么。echo 1是清 page cache，echo 2是清 dentry 和 inode，echo 3是都清。问题是这些缓存本来就是为了加速磁盘访问而存在的，你把它们清掉，系统重启后很快又会重新积累，而清掉之后的一段时间，所有的文件读写都要重新走磁盘，性能明显下降。也就是说你用一个立竿见影的数字变化，换来了实际业务性能的隐性损失。
那什么情况才需要手动清？我可以举一个真实场景：某个程序做一次性的批量处理，需要申请非常大的内存，而系统缓存又把可用内存吃得很紧，程序启动直接 OOM。这种时候缓存的存在确实影响了新任务的执行，可以先sync把脏页落盘，再 drop_caches 腾出空间。但这是救急，不是日常操作。更体面的办法是提前用posix_fadvise之类的接口告诉内核这些文件不会被再次访问，或者直接用cgroup限制缓存占用，但这已经超出查看内存的范畴了。
另外必须提醒一点：echo 3 > /proc/sys/vm/drop_caches需要 root 权限，而且写入这个文件是不需要额外开关的，生产环境里慎用。如果你有这个习惯，我建议改成：
sync && echo 3 | sudo tee /proc/sys/vm/drop_caches不过这句话我写完自己都想笑，因为我前面刚说了别轻易清缓存。如果你真想验证缓存清了对性能的影响，可以先在测试环境里跑一下基准测试，对比再决定。
3. 深入内存细节：top、vmstat、ps 与 smem
3.1 top 的 RES 和 SHR：一个进程到底吃了多少内存
free看的是全局，要定位到具体进程，top是第一选择。启动后在 top 界面按M可以按内存占用排序，这是最常用的操作。但很多人对 top 里 VSZ 和 RES 的理解是错的，导致定位问题进程时出现偏差。
VSZ（Virtual Size，虚拟内存大小）是进程的虚拟地址空间大小，包括它映射的代码段、数据段、共享库、堆、栈，以及它 mmap 的文件。虚拟内存本来就允许比物理内存大得多，一个进程 VSZ 显示 10G，实际可能只用了 500M 物理内存，所以看 VSZ 几乎不能判断真实内存占用，它只能说明进程地址空间的规模。RES（Resident Size，常驻内存大小）才是进程实际占用的物理内存，它是个进程独占的物理页加上它和其他进程共享的物理页的总和。
RES 也有个容易误导人的地方：共享内存和共享库会被重复计入所有使用它们的进程。比如 libc 库占 2M 物理内存，100 个进程都映射了它，那么这 100 个进程的 RES 里都会算上这 2M。如果机器上只有几个小程序，加起来可能虚高几百兆。要更精确地估算进程实际“独占”的物理内存，得看 PSS（Proportional Set Size），它把共享内存按比例摊还给每个进程。top不直接显示 PSS，可以用smem工具来看，这个后面讲。
再补充一个 top 里容易被忽略的字段：%MEM，它是 RES 除以物理内存总量。用top -o %MEM可以直接按内存占比排序，比进交互界面按M更省事。我在脚本里经常这么写：
# 列出当前按内存占用排序的前 10 个进程 top -b -o %MEM -n 1 | head -n 17-b是批处理模式，-n 1只跑一次，head -n 17是因为 top 输出前 7 行是系统概况，从第 8 行开始才是进程列表。
3.2 vmstat 的 si/so 与内存压力的真相
vmstat是个被我低估了很久的工具，它用一组计数器反映整个系统的内存、CPU、IO 状态。不加参数跑一次，看到的是自开机以来的平均值，这往往不能反映当前状态，更好的方式是：
vmstat 1每秒刷新一次，连续输出。看内存主要关注三列：r（运行队列长度）、si（从 swap 换入内存的速率 KB/s）、so（从内存换出到 swap 的速率 KB/s）。如果si和so长期不为 0，基本可以判定物理内存吃紧，系统在频繁地把内存页换到磁盘、再从磁盘换回来，这种状态也叫 thrashing，性能会断崖式下跌。
free命令看不到 swap 的换入换出速率，只能看到 swap 的使用量，所以vmstat 1是观察内存压力的第一现场。我一般这么组合使用：
vmstat 1 5每秒一次，连续 5 次，既能看瞬时状态，又不会刷屏。如果si或so在某一列长期大于 1000（单位是 KB，也就是每秒 1MB 的换入换出），说明系统已经在倒腾了，得赶紧找是哪个进程的问题，或者考虑加内存。
除了 si/so，vmstat里的free列（第二行）是真正的空闲内存，它和free命令里的 free 是一个意思。在写监控脚本时，如果不想依赖/proc/meminfo，也可以直接用vmstat解析，但我个人更推荐直接读/proc/meminfo，字段更稳定，不受版本差异影响。
3.3 ps 和 smem：快速定位“内存大户”
先说一个我常用的快速定位命令：
ps aux --sort=-%mem | head -20--sort=-%mem按内存占比倒序排，一条命令拿到内存占用最高的 20 个进程。这个方法在排查疑似内存泄漏的问题时非常顺手，配合watch就能观察一段时间内的变化：
watch -n 2 'ps aux --sort=-%mem | head -15'每隔 2 秒刷新一次，如果某个进程的 %MEM 只涨不跌，或者 RSS 稳步上升，那大概率就是泄漏。这是最朴素但也最有效的观察手段。
ps输出里的%MEM和RSS列和top里的含义一致，但要注意ps aux的 RSS 列单位是 KB，写脚本统计时要换算。ps -eo pid,comm,rss --sort=-rss | head能拿到更干净的输出，适合脚本消费。
smem不是所有系统默认安装的，但它提供的 PSS 信息在碰到共享内存场景时无可替代。比如你发现某个进程 RES 显示 2G，想知道它真正独占了多少，就可以：
smem -p -s pss | head -20-p以百分比显示，-s pss按 PSS 排序。smem还可以直接列出进程的 USS（Unique Set Size，独占物理内存）和 PSS，这三个量就是进程内存的三种口径：USS 是纯独占，PSS 是加上按比例分摊的共享，RSS 是把共享全算上。如果你想判断某个 JVM 进程是不是真的用了那么多内存，smem会给出比top更接近真相的答案。
4. 实战：从一条内存告警到定位根因的完整流程
4.1 先分清楚：是缓存吃内存，还是真有进程在泄漏
运维中收到内存告警，我最常犯的错误是直接去翻进程列表，结果看了半天没找到明显异常，那是因为方向错了。第一步应该永远是全局判断：内存到底是被谁占的？被 cache 吃掉了，还是一堆进程的 RSS 垒起来的？
拿到告警后，我会先跑下面这组命令：
free -h cat /proc/meminfo | head -20重点看 MemAvailable。如果 MemAvailable 还很大（比如总内存 64G 还有 40G 可用），但 MemFree 很小，同时 buff/cache 占了 XXG，这说明内存都被缓存占了，属于正常现象，系统在内存压力变大时会自动回收缓存，完全不需要人工干预。此时如果你看到top里某个进程 RES 很高也不会太紧张，因为高 RES 很可能是 mmap 了大文件，并不是真的吃了这么多物理内存。
反过来，如果 MemAvailable 也很低，比如不到总内存的 10%，而且ps aux --sort=-%mem里能看到持续走高的大进程，那才是真有问题。接下来进入第二步：确认是不是 OOM Killer 在动手。如果你的服务日志里出现 “Out of memory: Kill process” 之类的字样，或者相邻时间段内某个进程意外退出，那基本就是物理内存耗尽引发内核强制杀进程了。查看内核环形缓冲区是最直接的证据：
dmesg -T | grep -i 'out of memory\|oom-kill'在 systemd 系统上也可以用journalctl -k查看内核日志，效果一样。这一步确认之后，再去top或smem里找那个进程，才算真正进入“抓元凶”阶段。
4.2 案例拆解：一个 Java 服务的 RSS 从 1G 涨到 8G 的排查过程
我碰到的一个典型案例，是某 Java 服务在运行两天后 RSS 从 1G 涨到 8G，触发了告警。第一反应是 JVM 堆泄漏，但top里看到 RSS 高不代表堆就大，因为 JVM 的 RSS 还包含线程栈、metaspace、DirectByteBuffer 和 JIT 编译产物等。我当时的排查流程如下：
先看 JVM 堆的设置：
ps aux | grep java # 看到 -Xmx4g，说明堆上限只有 4G，但 RSS 涨到了 8G，那一定有堆外的内容接着用smem -k -p -s pss | grep java看这个进程的 PSS，如果 PSS 明显小于 RSS，说明共享内存占用也不小，还需要用/proc/<pid>/smaps进一步看每一段映射的匿名内存。这里有个小技巧：
grep -A 5 '^Size' /proc/<pid>/smaps | sort -k 6 -n -r | head # 或者更直接 sudo cat /proc/<pid>/smaps_rollupsmaps_rollup是 Linux 4.14+ 内核提供的汇总文件，一次就能看到这个进程 Rss、Pss、Shared_Clean、Shared_Dirty、Private_Clean、Private_Dirty 的总和。比逐个解析 smaps 高效太多。我看到 Private_Dirty 很高，说明有大量未命名的私有内存，也就是堆、栈、mmap 匿名映射这些。
再定位到线程看线程栈，ps -L -p <pid> -o pid,tid,rss能看到每个线程的 RSS，但很多线程栈默认只有 1M，8G 肯定不会全是线程栈。最后用pmap -x <pid>把所有地址段打出来，发现疑似是堆外的 DirectByteBuffer 占了大头，于是用/usr/bin/time -v java ...重新启动一次，观察它的 Maximum resident set size 和程序的退出信息，顺藤摸瓜找到是某个 NIO 组件没有显式释放 DirectByteBuffer 导致堆外内存泄漏。这个案例里如果没有用 smaps_rollup 和 pmap，光靠 top 的 RES 很容易误判成堆内泄漏，耗时多几倍。
总结这个排查流程，其实核心就三步：
- 全局看
free和/proc/meminfo，确认不是缓存造成的假象。 - 用
ps --sort或top -o %MEM找到嫌疑进程。 - 用
smem、/proc/<pid>/smaps_rollup、pmap下钻到进程内部，区分堆内、堆外、共享、私有。
4.3 一个容易被忽略的细节：SReclaimable 与不可回收的 slab 缓存
free命令里看不到 slab 的详细构成，即便cat /proc/meminfo也只给三个数：SReclaimable、SUnreclaim、Slab。Slab 是内核用来管理对象的内存池，比如文件系统的 dentry、inode 都是 slab 对象。SReclaimable 是可以回收的，内存压力大时内核会自动释放；SUnreclaim 是不可回收的，它持续上涨往往和内核模块或驱动 bug 有关。
排查内存问题时这个小细节能救命。我之前遇到过一个 NFS 客户端服务器，内存一天比一天少，free里看着还好，但SUnreclaim持续增长，最后查到是某个内核版本的 NFS 模块在特定负载下产生了不可回收的 slab 缓存泄漏。这类问题你用进程维度的工具是查不到的，因为罪魁祸首不在任何用户态进程里，而在内核态。
查看 slab 的分布可以这样：
cat /proc/slabinfo | sort -k 2 -n -r | head -20第一列是 slab 名称，第二列是活动对象数，第三列是总对象数。看到某个对象数量异常多，比如dentry、inode_cache或某个驱动相关的 slab 对象数暴涨，就有方向了。如果你不想手动看，也可以装个slabtop工具，交互式地看 slab 排序。
提示：
/proc/slabinfo里面的信息在不同内核版本里有差异，重点是看“哪个 slab 占的内存最多”，而不是死记某个 slab 的意义。
另外多提一句，free里的available已经考虑了 SReclaimable，所以 MemAvailable 低通常意味着 SUnreclaim 或者进程 RSS 飙升，这也是判断“是不是 slab 泄漏”的一个快捷信号。
5. 常见问题速查：命令、场景与避坑经验
下面这张表是我平时排查内存问题时最常用到的命令组合，整理出来方便查询。它不是man手册，是基于真实排查场景的“更快路径”。
| 场景 | 命令 | 关键点 |
|---|---|---|
| 看全局概况 | free -h | 注意 available 才是可用内存 |
| 看原始数据 | cat /proc/meminfo | MemAvailable、SReclaimable、SUnreclaim 都在这看 |
| 持续监控全局 | vmstat 1 | 看 si/so 是否频繁交换 |
| 按内存排序找进程 | `ps aux --sort=-%mem | head -20` |
| top 实时查看 | top -o %MEM | 直接在启动时按内存排序 |
| 看进程真实独占内存 | smem -p -s pss | PSS 比 RSS 更能反映真实占用 |
| 单进程内存汇总 | sudo cat /proc/<pid>/smaps_rollup | 效率高，一目了然 |
| 下钻进程内存布局 | pmap -x <pid> | 看堆、栈、mmap 分布 |
| 查内核 OOM 杀进程 | dmesg -T | grep -i 'oom' | 确认是否有进程被内核杀掉 |
| 查内核 slab 占用 | cat /proc/slabinfo | sort -k 2 -n -r | head | 排查内核态内存异常 |
5.1 我踩过的最典型的 5 个坑
第一个坑是把 Linux 的缓存当作“用掉的内存”去报警。我见过有同事脚本里判断条件是free -m | awk '/Mem:/ {print $2 - $7}'超过总量的 90% 就告警，结果一台跑数据库的机器全天候告警，但业务完全正常。正确做法是监控available，也就是$7那一列。
第二个坑是手动清理drop_caches。前面说过这是杀鸡取卵，清完缓存后一段时间内所有文件 IO 都要重新走磁盘，很多数据库在这之后反而变慢了。除非你有明确的一次性大内存需求，否则不要碰这个文件。
第三个坑是把top里的 RES 当作进程实际独占内存。碰到共享内存多的场景，比如 PostgreSQL、Redis 集群，RES 加起来可能严重超过物理内存，但互相之间共享的部分被重复计算了。用smem的 PSS 才能更接近真相。如果你环境里没装 smem，也可以直接看/proc/<pid>/smaps，把 Pss 字段加起来：
awk '/Pss:/ {sum += $2} END {print sum}' /proc/<pid>/smaps不过更省事的方法是用 smaps_rollup，里面直接有 Pss 总和，一行就拿到了。
第四个坑是忽略 swap 导致误判。有些容器或虚拟机的 swap 被关闭，free里 Swap 显示 0B，这本身不一定是问题，但有的人看到 si/so 一直为 0 就觉得内存很宽裕，结果 OOM Killer 照样把进程杀了。因为 swap 关闭不代表内存不紧张，只是没有换出这个“缓冲垫”，一旦物理内存耗尽，内核只能直接杀进程。所以判断内存状态要看 MemAvailable，不是看 swap 有没有用量。
第五个坑是只盯用户态进程，不关心内核态内存。SReclaimable 也好，SUnreclaim 也好，都是内核消耗。如果你发现 MemAvailable 很低但用户态进程加起来 RSS 也没那么多，一定要去看 /proc/slabinfo 和内核模块的占用，别在用户态那层浪费时间。
5.2 内存告警阈值的经验值
很多初次接触监控的同学会问，告警阈值到底怎么设。我根据多年经验给一个可参考的基线，但你要结合业务调整：
- 可用内存低于总内存 10%：先观察，不一定是问题，因为内核会缓存回收；但如果是数据库这类内存敏感型业务，可能已经开始出现延迟。
- 可用内存低于总内存 5%：建议触发告警，开始排查进程和缓存构成。
- si/so 持续不为 0：基本可以确认内存不足，需要立即定位和扩容，或者优化应用内存模型。
- OOM Killer 出现：已经出事，说明之前的阈值设得太高了，也应该检查是不是有内存泄漏。
如果是裸机跑虚拟机，宿主机还得留一部分内存给虚拟化层，阈值要更保守一些。容器场景建议直接看 cgroup 里的 memory 事件，cat /sys/fs/cgroup/memory.events（cgroup v2）能看到oom_kill是否触发过，阈值可以基于应用的 QPS 或连接数变化来调。
5.3 容器和虚拟化环境下的内存查看
容器场景下，在宿主机里直接跑free看到的还是宿主机整体内存，不是容器限额。要精确查看容器能用到多少内存，得进容器内部看/sys/fs/cgroup/memory.max（cgroup v2）和memory.current，或者用docker stats这类封装好的工具：
docker stats --no-stream容器里的free命令在部分环境下会显示宿主机内存，这会让很多人误判。如果你在容器里看到 total 和宿主机一样大，而你的容器限额只有 2G，那这个free输出不能用来判断容器可用内存，必须看 cgroup 数据。另外 cgroup v1 和 v2 的文件路径不同，v1 是/sys/fs/cgroup/memory/memory.limit_in_bytes，v2 是/sys/fs/cgroup/memory.max，容器平台不同差异还挺大，排查前先确认用的哪个版本。
Kubernetes 环境里，更直接的做法是kubectl top pod，它基于 cgroup 统计，能反映 pod 实际用量。但要注意它反映的是“已经用的”，不是“会不会超限”，真正判断是否接近 limits 要看 metric-server 的数据和 cgroup current。
6. 写出自己的“查内存风格”
工具和信息都摆出来了，最后聊聊怎么把这些变成你自己的习惯。我的做法是，在每台机器上必装一套“基线工具箱”：htop（交互式看进程树和内存）、smem（看 PSS）、sysstat包（带pidstat和sar）。sar可以看历史趋势，sar -r 1看内存利用率，sar -B看页交换统计数据，这在排查“凌晨内存突然飙升但当时没人盯着”这类问题时有奇效。
日常巡检，我一般一行命令就够：
free -h && echo '---' && ps aux --sort=-%mem | head -8先看全局，再扫一眼排名前几的进程，有没有异常的。如果怀疑有细微变化，就用pidstat -r 1盯某个进程的 RSS 变化。万一需要看历史趋势，sar -r -f /var/log/sa/saXX补上。这些都是简单但养成了会非常省心的习惯。
还有个小技巧是给free起个别名，省得每次敲参数。我在~/.bashrc里加了：
alias freeh='free -h' alias memtop='ps aux --sort=-%mem | head -12'一行别名能少敲不少字母，而且在排查线上问题时，少敲几个命令就是少几秒的等待。
最后再分享一个价值观层面的体会：内存查看工具的终极目的不是把数字看明白，而是把系统的运行状态和变化趋势建立直觉。熟练之后，你扫一眼free、top、vmstat的输出，就能大致判断当前系统是健康运作、正在承受压力、还是即将出事。这种直觉来自对底层原理和字段含义的透彻理解，而不仅仅是背命令参数。希望这篇文章能帮你把这把尺子磨得锋利一点。
