当前位置：首页 > 文章列表 > 文章 > linux > Linux tmpfs 为什么占满内存：df -h /run、df -i 与 size 语义怎么核对

Linux tmpfs 为什么占满内存：df -h /run、df -i 与 size 语义怎么核对

来源：17golang原创 2026-08-19 11:56:56 0浏览收藏

服务器告警弹出“/run 快满了”，不少人第一反应就想给磁盘扩容。可如果 findmnt /run 显示文件系统类型是 tmpfs，这里看到的根本不是独立的物理硬盘，而是由内核管理、按实际内容消耗内存和交换空间的临时文件系统。排查的时候得把挂载点、块存储空间、inode和真实占用的文件逐项对应上。

先记住一句：df -h 看容量上限和已用块空间，df -i 看 inode；tmpfs 的 size= 只是允许使用的上限，不代表系统已经预先占了同等大小的内存。

要点速览

df -h /run 与 df -i /run 要搭配着跑，容量占满和inode占满是两条完全独立的故障触发线。
findmnt -T /run -o TARGET,FSTYPE,SOURCE,OPTIONS 才能看到准确的当前挂载参数，尤其是 size= 与 nr_inodes= 的配置项。
执行清理操作前先找出具体占用的目录和已被进程打开的文件；调整空间上限前要确认systemd、容器或关联服务是否对这个挂载点有特殊依赖。

先确认 /run 到底挂载了什么

不要只看 df -h 的第一列输出。它显示的设备名可能是 tmpfs，但真正需要判断的是目标路径对应的真实挂载记录。用 -T 让 findmnt 按路径解析，避免把父目录或者容器外部的挂载项误当成当前目录的挂载信息。

findmnt -T /run -o TARGET,FSTYPE,SOURCE,OPTIONS
df -h /run
df -i /run

典型输出和下面的示例差不多，注意示例数值仅做参考，现场操作要以实际机器返回的结果为准：

TARGET FSTYPE SOURCE OPTIONS
/run   tmpfs  tmpfs  rw,nosuid,nodev,mode=755,size=2G

Filesystem Size Used Avail Use% Mounted on
tmpfs      2.0G 1.6G  400M  80% /run

tmpfs 的内容通常驻留在虚拟内存里，物理内存吃紧的时候也可能被放到swap分区；它只会按照当前存储的文件内容来消耗系统资源。挂载点卸载之后，里面的所有内容都会直接丢失，所以“清空”操作和普通磁盘的空间整理完全不是一回事。

Linux /run tmpfs 的 size 上限、df 已用空间与内存消耗关系示意图

df -h 和 df -i 分别统计的是什么

系统提示“空间满了”至少有两种完全不同的情况。df -h 统计块存储空间，适合排查日志、套接字以外的大文件持续写入的问题；df -i 统计inode数量，适合排查大量小文件把文件条目耗尽的问题。后者往往在磁盘容量还剩很多的时候就直接报空间不足。

检查项	统计对象	常见症状	下一步操作
`df -h`	块空间	Use% 占比很高，写入操作返回 No space left on device	按目录逐级统计大小，定位大文件和异常增长的内容
`df -i`	inode 数量	IUse% 占比很高，但剩余容量显示仍有很多	统计小文件总量，定位异常缓存、队列或者临时目录
`findmnt`	挂载类型与选项	不知道 size/nr_inodes 参数的来源	核对当前命名空间和生效的挂载参数

如果 df -h /run 显示使用率80%，完全不能直接推出主机内存已经消耗了80%。size=2G 是这个tmpfs实例允许使用的最大上限；实际内存占用仍要结合 free -h、/proc/meminfo 的 Shmem 字段，以及目录内的真实文件情况综合判断。

free -h
grep -E 'MemAvailable|Shmem|SwapFree' /proc/meminfo
du -xhd1 /run 2>/dev/null | sort -h

定位把 tmpfs 写满的进程

先从统计目录大小开始查，别一上来就直接执行 rm -rf /run/*。/run 里面可能存着PID文件、Unix套接字、锁文件和服务运行时专属目录，不加分辨地直接删除，会让正在运行的服务出现各种难以排查的异常状态。

du -xhd1 /run 2>/dev/null | sort -h
find /run -xdev -type f -size +50M -printf '%s %p\n' 2>/dev/null | sort -n
lsof +D /run 2>/dev/null | head -80

找到大占用目录之后，再确认它是否属于systemd服务、容器运行时或者某个自定义的守护进程。碰到已经被进程打开但已经被删除的文件，目录列表里看不到文件名，但进程仍然占着对应的空间，可以用 lsof +L1 作为补充排查线索。容器环境还要注意挂载命名空间的隔离性：在宿主机执行的 df 和容器内部执行的返回结果不一定一致。

size 与 nr_inodes 怎么核对和调整

tmpfs 支持通过 size= 设置存储空间上限，通过 nr_inodes= 设置inode数量上限；如果没有显式指定这两个参数，内核会使用自己的默认值。操作前先把当前的挂载选项完整记录下来：

findmnt -T /run -o TARGET,FSTYPE,OPTIONS
mount | grep ' on /run '

如果确认是默认的容量上限太小，而且业务应用确实需要更多的临时空间，可以在维护窗口期评估重挂载操作，示例命令如下：

mount -o remount,size=4G /run

这个扩容操作不是没有代价的：设置的上限越大，出现异常写入的时候就越容易拖低整个主机的可用内存；反过来把上限调小也可能因为现有内容已经超过新的阈值而操作失败，甚至影响正在运行的服务。要让配置永久生效，还要检查发行版的systemd自动生成配置、/etc/fstab 或者容器启动参数，不能只修改当前运行时的挂载配置。

Linux tmpfs 用 df -h、df -i 和 findmnt 判断清理或调整 size 参数的排查路径

通用的安全处理步骤

记录 findmnt -T、df -h、df -i 和 free -h 的返回结果。
用 du、find、lsof 锁定异常占用的目录、文件和对应的进程。
优先按照对应服务自身的规则轮转日志、清理缓存或者重启异常的服务实例。
只有确认业务确实需要，而且主机内存预算足够的前提下，才调整 size= 或 nr_inodes= 的参数值。
完成变更后再次执行四类检查，并且观察一段时间的空间增长速度。

如果根因是某个服务持续不断生成临时文件，单纯调大tmpfs的上限只是把告警推迟触发而已。更稳妥的修复方式是限制临时文件的生命周期、修正异常重试逻辑，或者让服务把大对象写到有明确配额的持久化存储路径下。

总结

排查 Linux tmpfs 异常，核心是不要把它当成“另一块普通磁盘”，而是把挂载参数、块存储空间、inode、主机内存和具体的写入进程串起来关联分析。findmnt 负责确认边界规则，df -h/df -i 负责确认哪一类资源先到阈值，du 与 lsof 负责定位对应的责任进程。所有排查线索核对清楚之后，再决定是清理内容、修复程序逻辑还是调整资源上限。