Linux tmpfs缓存目录的容量与重启清空边界

Linux 的 tmpfs 适合放可重新生成的缓存、编译中间文件和短期 socket 文件，但“放在内存里”不等于“固定占用一半内存”。它按实际写入量增长，同时受挂载参数限制；默认上限通常是物理内存的 50%，内容在卸载后会消失。生产环境应显式设置 size，再根据文件数量补充 nr_inodes，不要把数据库、上传文件或唯一日志放进 tmpfs。

先确认tmpfs的容量上限和实际占用

排查“缓存目录突然写满”时，先看挂载参数，不要只看宿主机的总内存。下面的命令把文件系统类型、上限和当前使用量放在一起；注释只解释示例意图，不代表一张真实终端截图。

# 查看挂载类型、size、inode上限和当前使用量
findmnt -no TARGET,FSTYPE,OPTIONS /var/cache/myapp
df -h /var/cache/myapp
df -i /var/cache/myapp

# 创建一个有明确容量和权限边界的缓存挂载点
sudo mkdir -p /var/cache/myapp
sudo mount -t tmpfs -o size=2G,nr_inodes=200k,mode=0750 tmpfs /var/cache/myapp

df -h 显示的是已使用和可用空间，df -i 用来发现“小文件很多但容量还没满”的 inode 瓶颈。size 可以使用字节或百分比；没有显式设置时，内核文档给出的默认上限是物理内存的 50%。这个上限只是该实例的限制，真正的内存消耗随文件内容变化。

用容量、inode和swap共同做边界

只设置 size 还不够。大量小文件可能先耗尽 inode；共享目录还需要用 mode、uid 和 gid 限制访问。tmpfs 默认允许在内存压力下使用swap，因此它不是“永远只占RAM”的保证。Linux 6.4及更新内核支持 noswap，但应先确认应用能承受更早的写入失败。

需要调整上限时可以重新挂载，不必先删除现有文件；但新上限不能低于当前使用量。容量调整属于资源治理的一部分，建议先观察应用的峰值文件量，再把余量写进部署配置。

# 仅提高上限；新值不能小于当前已用空间
sudo mount -o remount,size=3G,nr_inodes=300k /var/cache/myapp

# 查看内核记录的tmpfs/shmem相关统计，辅助判断内存压力
grep -E 'Shmem|SwapFree|MemAvailable' /proc/meminfo

卸载、重启与自动挂载不是同一件事

tmpfs 的内容没有磁盘副本。执行卸载、系统关机或挂载实例被移除后，目录里的缓存就不再可用；再次挂载只会得到一个新的空实例。把配置写进 /etc/fstab 只能保证系统按参数重新挂载，不能恢复旧文件。

# /etc/fstab：应用缓存允许丢失，重启后由服务重新生成
tmpfs /var/cache/myapp tmpfs rw,nosuid,nodev,noexec,size=2G,nr_inodes=200k,mode=0750 0 0

因此部署时要同时检查三件事：应用启动前挂载点已经存在；应用启动后能重新生成缓存；监控同时观察 df -h、df -i 和主机内存。若目录保存的是用户上传内容、任务唯一中间结果或需要跨重启恢复的数据，应改用磁盘文件系统，并把缓存淘汰策略放在应用层。

按场景选择tmpfs的检查清单

• 适合：可重建的热点缓存、短生命周期构建产物、临时解压目录。
• 谨慎：大量小文件、容器共享目录、没有swap且内存余量很小的主机。
• 不适合：唯一业务数据、需要跨重启恢复的队列、审计日志和用户上传原件。

可以把决策简化为一句话：数据能否无损重建，决定能不能接受tmpfs清空；峰值内存和文件数量，决定 size 与 nr_inodes；是否允许换出，决定是否采用 noswap。三个答案都明确后，再把挂载参数固化到发布配置。

常见问题

tmpfs设置了2G是不是马上占用2G内存？

不是。2G是该挂载实例的上限，实际占用会随文件内容增长，并可能受到swap策略影响。

为什么df显示还有空间却无法创建文件？

常见原因是 inode 达到 nr_inodes 上限，使用 df -i 检查；也要排查权限和只读挂载状态。

重启后tmpfs文件还能找回来吗？

不能把它当作持久存储。重启后通常得到重新挂载的空目录，应用应负责重新生成缓存。