Linux tmpfs 使用率高时怎么判断是缓存还是空间不足

Linux 上看到 /dev/shm、/run 或自定义 tmpfs 的使用率很高，先不要急着把它当成“内存泄漏”。df 高说明这个 tmpfs 挂载实例的块空间接近上限；是否已经造成物理内存压力，还要结合 /proc/meminfo 里的 Shmem、MemAvailable 和 swap。若 df 明显高于 du，再查删除后仍被进程打开的文件。

最实用的判断顺序是：df -h 看挂载空间，du -x 看可见文件，df -i 看 inode，Shmem 看系统级共享内存，最后用 lsof +L1 解释“看不见但没有释放”的占用。

先区分 tmpfs 的上限、已用块和真实内存压力

tmpfs 把文件放在内核的内存文件系统中，页面在有 swap 时也可能被换出。这里有三个容易混淆的数字：挂载参数中的 size 是“最多允许分配多少”，df 的 Used 是“这个实例已经分配了多少”，而系统是否紧张要看全局可用内存和换页活动。没有显式指定 size 时，Linux 内核文档给出的默认值是物理内存的 50%，但这只是上限，不是预留量。

# 把 MOUNT_POINT 换成实际的 tmpfs 挂载点
MOUNT_POINT=/dev/shm

# 查看文件系统类型、大小、已用、可用和挂载选项
findmnt -no TARGET,FSTYPE,SIZE,USED,AVAIL,USE%,OPTIONS "$MOUNT_POINT"
df -hT "$MOUNT_POINT"

# 观察系统级共享内存、可用内存和 swap，而不是只看 tmpfs 百分比
grep -E '^(MemAvailable|Shmem|SwapFree|SwapTotal):' /proc/meminfo
free -h
swapon --show

如果 df 已到 90% 以上，但 MemAvailable 仍充足、swap 没有持续增长，优先把它视为挂载容量或文件生命周期问题；如果 Shmem 同时很大、可用内存持续下降并伴随换页，再按内存压力处理。要注意，Shmem 是系统级统计，除了 tmpfs 还可能包含 System V/POSIX 共享内存和共享匿名映射，不能直接当成某一个挂载点的精确用量。

用 df、du 与 df -i 对照块空间、可见文件和 inode

把三个命令的角色分开，排查会快很多。df -h 从文件系统角度看块空间；du -xhd1 沿目录树统计能看到的文件；df -i 看 inode 是否先耗尽。tmpfs 里小文件很多时，容量尚有余量但 inode 接近 100%，同样会导致创建失败。

# 先确认目标挂载点的块空间和 inode
df -h "$MOUNT_POINT"
df -ih "$MOUNT_POINT"

# -x 不跨到其他文件系统；按一级目录汇总可见文件
du -xhd1 "$MOUNT_POINT" 2>/dev/null | sort -h

# 继续定位最大的可见目录或文件
du -xah "$MOUNT_POINT" 2>/dev/null | sort -h | tail -n 20

常见组合可以这样读：df 高、du 也高，通常是可见文件确实占满了空间；df 高、du 低，重点转向已删除仍打开的文件或统计范围不一致；df -i 高而块空间不高，则优先检查小文件数量。du 统计的是可见目录树，所以不要用它单独证明“内存已经释放”。

当 df 高而 du 低：查删除后仍打开的文件

进程打开文件后，即使路径被 rm 删除，只要文件描述符还在，文件内容仍可能被进程使用；目录树看不到它，挂载统计却还没有下降。这是“清理过了但空间不回来”的典型线索。

看到结果后不要直接杀进程。先确认 PID 属于哪个服务、文件是否是日志或临时数据，再选择让应用执行日志 reopen、关闭句柄，或在维护窗口重启服务。若服务没有优雅的 reopen 能力，重启前要评估连接、队列和未落盘数据。处理后重新比较 df 和 du，只把空间下降作为释放完成的信号。

按证据选择清理、限额调整或应用修复

不要用“把 size 调大”替代定位。若可见文件增长是业务缓存失控，先加生命周期和清理策略；若 inode 紧张，减少碎片化小文件或调整文件组织；若删除后仍打开，修复日志轮转或句柄关闭；只有确认机器有足够内存、swap 策略也符合预期时，才考虑 remount 调整上限。

临时文件的内容在卸载 tmpfs 后会丢失，因此清理或卸载前必须确认它不是共享内存、运行时 socket 或应用正在使用的数据。生产环境最好把 df 使用率、inode 使用率、Shmem、MemAvailable 和 swap 使用趋势分别监控，避免把挂载容量告警和内存告警混成一条。

相关问题

tmpfs 使用率高是不是一定会触发 OOM？

不一定。它首先说明挂载实例的空间接近上限；是否触发 OOM 还取决于系统可用内存、swap、其他进程和实际分配压力。

为什么 du 显示很小，df 却接近 100%？

先确认两者针对的是同一个挂载点和同一目录范围，再用 lsof +L1 查删除后仍打开的文件，同时排除 inode 耗尽和权限导致的统计不完整。

参考：Linux Kernel tmpfs 文档、tmpfs(5)、proc_meminfo(5)。