“Linux 会把空闲内存拿去做缓存，所以 free 很低不用管。”这句话在缓存可回收、业务仍有足够内存余量时成立，但不能直接作为排除故障的依据。在美国服务器上看到空闲内存偏低，真正需要区分的是：内存只是暂时用于提高访问效率，还是系统已经在回收、换页甚至终止进程。

判断是否主要是缓存占用，应同时看 MemAvailable、缓存构成、持续换页情况，以及进程和 OOM 记录。如果 free 很低，但 available 足以覆盖业务正常波动，没有持续的内存压力或异常换页，进程占用也没有不断增长，通常属于正常缓存利用；如果这些条件不成立，就不能仅凭 buff/cache 很大判断安全。

“空闲少”不等于“可用少”，遗漏的是统计口径

以下操作适用于常见 Linux 发行版，先执行只读检查，不修改内核参数、不清缓存、不重启服务。基础命令通常来自 procps 或 procps-ng；查看其他用户的进程详情和内核日志可能需要管理员权限。

free -h
grep -E '^(MemTotal|MemFree|MemAvailable|Buffers|Cached|SReclaimable|SUnreclaim|Shmem|Dirty|Writeback|SwapTotal|SwapFree):' /proc/meminfo

重点区别如下：

Linux 会用暂时闲置的内存保存文件数据、文件系统元数据等，减少重复读取。应用需要更多内存时，内核可以回收其中符合条件的部分，因此 MemFree 很少也可能是正常状态。

比起给 free 设置统一百分比阈值，更有意义的是判断 MemAvailable 能否覆盖业务接下来的内存需求。稳定的小服务和存在批量任务的服务，对余量的要求不同。不同版本的 free 对 used 等列的计算可能有差异，不宜只拿一个“已用百分比”跨系统比较。

较老的内核或工具可能没有 available 列。此时不要直接用“空闲加缓存”作为精确替代，应结合后面的换页、进程和业务表现判断。

“缓存都能释放”并不完整，要看缓存里是什么

缓存大可以说明 Linux 正在利用内存，但缓存是否容易回收，还取决于它的类型和状态。

• 干净的文件页缓存：内容已存在于存储中，通常可以直接丢弃，需要时再读取。
• 脏页及正在回写的数据：需要完成写回后，相关页面才更容易被回收。如果写回受阻，回收可能伴随等待。
• 可回收的 Slab：SReclaimable 表示潜在可回收的内核对象内存，不代表能瞬间全部释放。
• 不可回收的 Slab：SUnreclaim 不属于可随意释放的文件缓存，持续增长值得进一步检查。
• 共享内存和 tmpfs：涉及 Shmem，也会影响缓存统计，但不能像普通干净文件缓存一样直接丢弃。

这些字段存在统计关联，不能全部相加后当作“可释放内存”。同样，应用自己维护的内存缓存通常属于进程占用，并不等于内核页缓存。

如果怀疑 tmpfs 占用，可先只读查看：

findmnt -t tmpfs
df -h -t tmpfs

这里需要区分容量上限和实际使用量：tmpfs 的挂载大小不等于已经消耗的内存。若实际使用持续增长，再定位对应目录和使用它的进程；不要因为名字里有“临时”就直接删除文件。

“Swap 用了就是内存不够”，遗漏的是时间维度

交换空间中存在数据，可能只是过去某次内存紧张留下的结果。内存压力下降后，不常访问的页面未必立即回到物理内存，因此 Swap 已用量和当前换页强度必须分开看。

在业务正常运行或问题出现时采样：

vmstat 1 10

这个命令每秒输出一次，共输出十次。第一行通常反映启动以来的平均情况，判断当前状态主要看后续采样行：

• si：从交换空间读回的速率。
• so：向交换空间写出的速率。
• b、wa：可辅助观察阻塞和 I/O 等待，但不能单独归因于内存。

如果 Swap 已用量不为零，但后续 si、so 基本没有活动，MemAvailable 也保持稳定，不能据此认定正在发生内存故障。反之，若持续换入换出，同时可用内存低、请求延迟增加，则应按真实内存压力继续排查。

没有启用 Swap 时，si、so 为零也不能证明安全：系统仍可能频繁回收文件页，甚至触发 OOM。

支持 PSI 的内核还可以查看内存压力：

if [ -r /proc/pressure/memory ]; then
    cat /proc/pressure/memory
fi

some 表示至少有部分任务因内存压力停顿，full 表示所有非空闲任务同时因内存压力停顿的情况；avg10、avg60、avg300 是不同时间窗口的压力占比。应结合业务基线和故障时段解读，不宜套用统一阈值。文件不存在可能是内核未提供或未启用该功能，不代表没有压力。

短时采样只能判断当前窗口。若问题只在定时任务或访问高峰出现，应在对应时段重新采样。

“缓存很大，所以不用查进程”，遗漏的是共同增长

缓存占用和进程异常可能同时存在。一次内存快照不能证明泄漏，但可以先找出主要占用者：

ps -eo pid,ppid,comm,rss,vsz --sort=-rss | head -n 16

在常见 procps 实现中，RSS 和 VSZ 以 KiB 展示：

• RSS 是进程当前驻留在物理内存中的部分，适合初步排序。
• VSZ 是虚拟地址空间大小，不能直接当作物理内存消耗。
• 多个进程可能映射相同的共享页面，不能把 RSS 简单相加当作实际总占用。

对排名靠前的进程，应在相近负载下重复观察。业务量回落后占用仍持续上升，才更值得怀疑泄漏、应用缓存无上限或任务堆积；运行时保留已申请内存，也可能导致 RSS 不立即下降，需要结合应用自身指标判断。

需要进一步区分共享页和私有页时，可读取目标进程的 /proc/PID/smaps_rollup，将 PID 替换为实际进程号：

grep -E '^(Rss|Pss|Private_Clean|Private_Dirty|Swap):' /proc/PID/smaps_rollup

该文件在部分老内核上不存在，读取其他用户的进程也可能需要管理员权限。Pss 会按比例分摊共享页，更适合辅助比较；这类检查需要遍历内存映射，不宜对大量进程高频轮询。

如果 available 下降，却没有明显增长的大进程，还应回看 SUnreclaim、Shmem 等字段。进程 RSS 排名不能覆盖全部内核和共享内存消耗。

“没看到内存耗尽就没问题”，还要核对 OOM 和容器限制

OOM 可能在瞬间发生。进程被终止后，内存随即释放，此时再看 free，数值反而可能正常。因此有异常退出、任务中断时，应检查对应时段的日志。

使用 systemd 且可读取日志的系统，可以执行：

journalctl -k --since "24 hours ago" --no-pager | grep -Ei 'out of memory|oom-kill|killed process|memory cgroup'

没有可用 journal 时，可辅助查看：

dmesg -T | grep -Ei 'out of memory|oom-kill|killed process|memory cgroup'

这些操作只读，但可能需要权限。日志轮转、权限不足或内核缓冲区覆盖，都可能造成记录缺失；没有匹配结果不能完全排除 OOM。出现记录时，还要区分全局 OOM 和内存控制组 OOM，并核对被终止的进程及时间。

对于容器或设置了内存限制的服务，宿主机可用内存充足，不代表该服务还有可分配额度。在 cgroup v2 环境中，可以依据目标进程的 /proc/PID/cgroup 和实际 cgroup2 挂载点找到所属目录，检查：

• memory.current：当前内存使用量。
• memory.max：硬限制，max 表示本级未设置硬上限，但仍可能受父级限制。
• memory.events：观察 max、oom、oom_kill 等计数是否在问题期间增加。

这些计数是累计值，非零不等于当前正在发生故障。cgroup v1 的文件名和语义不同，不能直接套用上述检查项。

不必清缓存来证明，保留原状态更容易判断

主动执行 drop_caches 后，空闲内存上涨，只能说明释放了一部分缓存，不能证明原先没有压力，也不能解决进程泄漏或容器额度不足。缓存重建还可能增加读取和响应等待，因此不应把清缓存、关闭交换或重启作为第一步验证手段。

一次有效判断应保留同一时段的关联信息：

在美国服务器上判断 Linux 是否只是缓存占用，最终依据不是“缓存够不够大”，而是可用余量、回收与换页压力、进程趋势及业务表现能否相互印证。这些条件持续成立时，低空闲内存通常无需处理；若出现峰值分配、容器限制或 OOM，则必须进入对应分支排查，不能继续用“Linux 会做缓存”解释所有现象。