一、tmpfs 到底是什么Linux 内核文档将 tmpfs 定义为一种将文件保存在虚拟内存中的文件系统。tmpfs 文件的内容由内核管理可以驻留在物理内存也可以在允许 Swap 且发生内存压力时被换出。它不依赖一个普通的块设备文件系统来保存这些临时文件。卸载该文件系统后里面的文件会丢失。[1]与传统磁盘路径相比它有四个重要特征按需分配size1G指容量上限不代表 mount 时立即消耗 1 GiB 的物理内存。可限制size和nr_inodes等选项能够限制可使用的文件数据空间及 inode 数量。可能 Swap默认允许 tmpfs 页面被换出Linux 6.4 起支持noswap挂载选项但须确认实际内核支持。[1][2]生命周期短取消挂载或主机重启后不能依赖文件保留。重新挂载时看到的是新文件系统实例。tmpfs、ramfs、RAM Disk、Page Cache 的区别技术文件内容位置容量控制可使用 Swap数据持久性tmpfs虚拟内存、物理 RAM允许时可进入 Swap支持默认可以无ramfs内核缓存 / 物理 RAM不提供 tmpfs 式限额不可以无块设备 RAM DiskbrdRAM 中的模拟块设备初始化时设定大小不可以无ext4/XFS Page Cache内存缓存 后端磁盘受文件系统容量约束文件内容有持久化后端按文件系统语义持久化最容易产生误解的是最后一项。使用 SSD 存储文件并不表示每次读取都要访问 SSD。热数据可能已经在 Page Cache 中因此“tmpfs 读取必然比 SSD 文件快几十倍”并不是可直接成立的结论。真实收益需要以工作负载为准。二、底层原理VFS、shmem 和内存页怎么协作应用调用open()、write()、read()或mmap()时首先经过 Linux VFS虚拟文件系统抽象层。针对 tmpfs内核通过 shmem/tmpfs 相关机制管理文件、inode 与页面。文件数据驻留在内核缓存里内存回收机制在有条件时能够将部分页面交换到 Swap。读取被换出的页面时系统需要将其重新调入。[1]这和“直接 malloc 一大块内存做文件系统”是不同的tmpfs 有常规文件系统接口、文件名、目录、权限、inode、扩容与空间不足处理行为。例如一次图片解析流程可以是服务收到图片 URL 或上传请求从网络读取原始内容写入 tmpfs 中的临时文件图片处理工具像读普通文件一样读取它生成处理结果并上传到持久化存储删除原始和中间临时文件。这里 tmpfs 适合扮演短期交换介质而不是最终结果的保存位置。不能因为写入 tmpfs 已完成就认为数据已经持久化成功。为什么不直接用内存变量如果所有处理都由一个进程完成且库可以接受字节流内存缓冲区通常更直接。但实际环境中多种处理工具只接受文件路径或需要多个进程通过普通文件 API 协作。这时 tmpfs 可以减少改造成本同时避免一部分持久化文件系统写入。它的代价是内核页、元数据、内存竞争以及潜在的 Swap 和复制成本。三、5 分钟上手创建、检查、调整和卸载1. 先确认现有 tmpfsfindmnt-ttmpfs findmnt-T/dev/shm-oTARGET,SOURCE,FSTYPE,OPTIONS findmnt-T/tmp-oTARGET,SOURCE,FSTYPE,OPTIONSdf-hT/dev/shmfree-h/dev/shm通常是 tmpfs/tmp是否使用 tmpfs 取决于发行版及系统配置不要凭目录名字判断。/run也常使用 tmpfs。/dev/shm主要用于 POSIX 共享内存接口。[1][3]2. 手工创建一个 512 MiB tmpfs在自有测试机器上执行sudomkdir-p/mnt/ramcachesudomount-ttmpfs\-osize512M,nr_inodes100k,uid$(id-u),gid$(id-g),mode0700,nosuid,nodev,noexec\tmpfs /mnt/ramcache findmnt-T/mnt/ramcacheprintfhello tmpfs\n/mnt/ramcache/test.txtcat/mnt/ramcache/test.txtdf-hT/mnt/ramcachedf-i/mnt/ramcachedu-sh/mnt/ramcache其中参数含义size512M为这个 tmpfs 实例指定容量上限nr_inodes100k限制 inode 数量防止大量小文件耗尽 inodeuid、gid指定根目录初始所有者mode0700仅允许所有者访问该目录nosuid,nodev,noexec限制若干文件系统行为但不能取代沙箱及进程权限控制noexec不代表其中的数据绝对无法被解释器读取执行因此不是完整的恶意代码隔离机制。3. 调整容量或卸载# 增大该实例的容量上限并非立即申请 1 GiB 内存sudomount-oremount,size1G /mnt/ramcache# 卸载前必须确认没有仍需使用的文件sudoumount/mnt/ramcache注意卸载即丢失 tmpfs 内容。不要在仍有业务使用的目录上直接执行卸载。4. 需要开机自动挂载时可以在/etc/fstab添加一行以下示例 UID/GID 请按实际应用账户修改tmpfs /mnt/ramcache tmpfs rw,size512M,nr_inodes100k,uid1000,gid1000,mode0700,nosuid,nodev,noexec 0 0这表示开机重新创建一个空的 tmpfs不是保存并恢复上次写入的文件。重要服务需要明确空目录启动与缓存重建的流程。四、为什么 size4G 并不代表占用 4GB 内存size是逻辑容量约束。假设挂载size4G实际只写入 100 MiB 数据那么这不是在挂载时预先划走 4 GiB RAM。内存使用会随文件、元数据、页面以及内存管理活动变化。但是仅有size也不意味着安全多个 tmpfs 挂载点可以同时消耗内存Java 堆、进程 RSS、内核缓存和 tmpfs 会争抢可用资源文件系统还会消耗 inode 和其他内核元数据在 Cgroup 中tmpfs 使用量计入内存控制器统计不因为设了size就绕过容器内存限制。[4]以容器为例即使 tmpfs 挂载上限为 2 GiB但容器内存硬限制只有 512 MiB也不能因此写满 2 GiB tmpfs它可能先达到容器内存限制并触发 OOM。监控命令# 查看挂载点可用空间与 inodefindmnt-T/mnt/ramcachedf-h/mnt/ramcachedf-i/mnt/ramcache# 查看系统共享内存统计包含其他 shmem不只这个 tmpfsgrep-EMemAvailable|Shmem|SwapFree/proc/meminfo# Linux 内存压力cat/proc/pressure/memory# 若当前进程所在环境挂载了 cgroup v2cat/sys/fs/cgroup/memory.current2/dev/null||truegrep-E^(shmem|file) /sys/fs/cgroup/memory.stat2/dev/null||truecat/sys/fs/cgroup/memory.events2/dev/null||truefree的shared和/proc/meminfo的Shmem并非单个 tmpfs 挂载的精确使用量看指定挂载时优先结合df和du。已删除却仍被进程持有的文件也值得通过lsof L1检查。[1]五、性能实战tmpfs 与 NVMe 应该怎么比如果只对同一个文件反复读取ext4/XFS 上的文件很可能都已经缓存在 Page Cache 中。此时测试可能只是在比较两个不同的内存缓存路径。一个相对合理的实验应当至少区分小文件频繁创建、删除时的元数据操作顺序写入、顺序读取的吞吐业务处理流程的端到端耗时进程 RSS、Shmem、内存回收压力持久化需求是否需要fsync()以及两者的语义差异。推荐先准备独立的测试目录在已安装 fio 的测试机上运行mkdir-p/mnt/ramcache/fio-lab fio--nametmpfs-mixed\--directory/mnt/ramcache/fio-lab\--rwrandrw--rwmixread70--bs4k\--size128M--ioenginesync--numjobs1\--iodepth1--runtime20--time_based\--group_reporting测试目录里会生成 fio 数据文件完成后确认测试进程结束再清理测试目录。不要在 tmpfs 上机械地使用为块设备设计的direct1作为对照条件。针对磁盘的测试也应使用隔离目录标注其 Page Cache 状态、文件系统和fsync()行为。只报告“吞吐量高了多少倍”却忽略缓存与持久化语义得不到可信的性能结论。配套压缩包中提供了一个无需 root 权限的 Python 微基准脚本可比较缓冲写入、热缓存读取和小文件操作并清理自身创建的测试数据。它的结果用于演示测试方法不代表所有硬件上的固定加速比例。六、生产实战高并发截图、解析与转码服务以网页截图或内容解析服务为例每个任务可能生成 HTML、截图、提取后的图片和压缩包等临时产物。业务真正需要长期保存的通常只是最终结果而不是全部中间文件。可以采用这样的流程请求到达后为任务生成独立的临时子目录在 tmpfs 内保存大小可控的中间结果根据所选工具生成最终输出将最终数据写入对象存储或其他持久化系统并确认成功删除临时文件与目录若出现空间不足、超时或进程异常返回可定位的错误同时执行清理与降级逻辑。这里不能只算单任务数据量应该估计峰值并发时的总占用峰值临时空间 ≈ 最大同时运行任务数 × 单任务峰值临时文件量 × 安全冗余系数这只是容量估算不是物理内存的独占预留。需要进一步叠加应用堆、浏览器进程、内核开销和业务异常重试带来的峰值。如果一个服务本来可以直接用流式 API 处理内容就不必为了使用 tmpfs 而先写文件、再重新读文件。多一次复制和文件系统操作反而可能造成额外成本。Java 服务如何选用 tmpfs最直接的做法是把一部分明确可丢弃的临时文件放到指定路径importjava.nio.file.Files;importjava.nio.file.Path;publicclassTempWork{publicstaticvoidmain(String[]args)throwsException{PathtmpFiles.createTempFile(Path.of(/mnt/ramcache),stage-,.txt);try{Files.writeString(tmp,temporary result);System.out.println(Files.readString(tmp));}finally{Files.deleteIfExists(tmp);}}}也可以通过-Djava.io.tmpdir...改变 JVM 默认临时目录但这会影响更多组件。对于已有系统建议先对目标业务单独配置临时目录而不是一开始就全局修改。七、Docker 中正确使用 tmpfsDocker 的 tmpfs 挂载可把临时文件放到容器的可写层之外同时仍受宿主内核和容器内存限制约束。[5]dockerrun--rm\--memory256m\--tmpfs/scratch:rw,size128m,mode1777,nosuid,nodev,noexec\alpine:3.21\sh-cdf -h /scratch; echo ok /scratch/demo.txt; cat /scratch/demo.txt生产中可以根据应用用户设置更严格的目录权限。Docker Compose 也可以配置services:worker:image:alpine:3.21command:[sh,-c,df -h /scratch; sleep 3600]mem_limit:512mtmpfs:-/scratch:size128m,mode1770需要特别强调容器 tmpfs 页面会计入容器内存控制组。tmpfs容量 128 MiB并不等于容器获得额外 128 MiB RAM。容器停止时里面的 tmpfs 数据不会作为持久卷保存。[5]八、KubernetesemptyDir.medium: Memory在 Kubernetes 中emptyDir指定medium: Memory就会使用 tmpfsapiVersion:v1kind:Podmetadata:name:tmpfs-labspec:containers:-name:appimage:busybox:1.36command:[sh,-c,df -h /scratch; sleep 3600]resources:requests:memory:128Milimits:memory:256MivolumeMounts:-name:scratchmountPath:/scratchvolumes:-name:scratchemptyDir:medium:MemorysizeLimit:64Mi注意两点sizeLimit限制卷内数据量但不会把卷的内存从容器用量中剔除写入数据计入执行写入操作的容器内存用量。emptyDir的内容在同一 Pod 内通常能够跨容器进程重启保留但 Pod 从节点移除后会被删除。它和 Docker 容器 tmpfs 的生命周期不能完全混为一谈。[6]因此Kubernetes 里不仅要限制 emptyDir 容量也要评估容器的内存 limit避免因临时文件增长导致 OOMKilled。九、数据库是否应该使用 tmpfs不推荐直接把数据库的数据目录、WAL、Kafka 日志、ClickHouse 持久化数据或备份原件放在 tmpfs。因为重启与故障恢复时缺失的是原始数据而非可再生缓存。以 PostgreSQL 为例temp_tablespaces可指定临时表和部分排序等临时文件使用的表空间。[7] 理论上可以对受控的临时工作负载评估 tmpfs但这必须先考虑峰值占用、查询失败恢复以及内存预算不应该让生产数据库直接采用没有验证的 tmpfs 表空间方案。还要区分 PostgreSQLUNLOGGED表与 tmpfsUNLOGGED 是数据库提供的一种日志策略不等于将数据文件自动放到内存文件系统。即使都可能具有某些数据恢复限制也不是可互换的概念。十、三个最容易忽略的风险风险 1Swap 让 tmpfs 仍可能涉及磁盘允许 Swap 的 tmpfs 页面在内存压力下可能被换到交换空间。若用于暂存敏感信息就不能简单宣传为“绝对不落盘”。在 Linux 6.4 可根据需要评估初次挂载时使用noswap并继续考虑内存转储、进程权限和其他数据泄露风险。[1]风险 2文件被删除不一定立即释放页面进程仍持有打开的文件描述符时已 unlink 的文件资源可能不会立即回收。排查时可以结合lsof L1、df和进程生命周期检查。风险 3tmpfs 会和应用争抢内存高并发任务产生大量临时文件时应用堆、浏览器子进程、内核缓存与 tmpfs 并不会彼此隔离。如果没有并发限制和释放机制可能出现ENOSPC、Swap 抖动、内存回收开销上升或 OOM。十一、上线前建议检查什么业务是否允许 tmpfs 所有文件在重启后丢失任务是否具有可量化的峰值临时文件容量是否对 inode、文件大小和并发任务数设置上限是否确认了容器 Cgroup 的内存限制和监控方式是否测试了空间不足、Swap 压力和 OOM 处理是否有临时文件清理、对象存储持久化确认与失败降级是否使用端到端业务指标而不只是dd/fio单项跑分十二、总结tmpfs 值得使用但它适合解决的是短生命周期、可重建、文件接口方便且大小受控的数据交换问题。如果临时文件路径上确实存在持久化磁盘 I/O 开销tmpfs 可能提高延迟表现并减少磁盘写入如果工作负载原本就命中 Page Cache或者处理瓶颈在 CPU、网络、图像解码替换为 tmpfs 可能收益有限。真正正确的做法是把 tmpfs 当作受内存预算约束的高速临时文件系统而不是“免费且永远比磁盘快的内存盘”。参考资料Linux Kernel — tmpfstmpfs(5) — Linux manual pagesystemd — Temporary DirectoriesLinux Kernel — Control Group v2Docker — tmpfs mountsKubernetes — Volumes / emptyDirPostgreSQL — Tablespaces