tmpfs挂载需“稳、小、准、可管”：必须设size、mode、uid/gid、nr_inodes四要素，写入fstab并用Shmem监控真实内存占用，仅适用于可丢弃、重建快的秒级缓存。
确认目录是否真适合放内存
秒级缓存通常可丢、可重建，比如 API 返回结果快照、实时指标聚合中间态、会话临时快照等。但得先排除硬编码路径或强依赖磁盘持久性的服务：
– 运行 fuser -v /path/to/cache 或 lsof +D /path/to/cache，确保没进程正锁定该目录
– 清空前先备份（rsync -a /cache/ /backup/cache_pre_tmpfs/），再 rm -rf /cache/*
– 重启服务验证：清空后 reload 或 restart，看日志是否正常写入、无“Permission denied”或“No such device”报错
挂载命令必须带四要素
只写 mount -t tmpfs tmpfs /cache 是高危操作。真正可用的命令要包含：
– size=值：按业务峰值预估，比如每秒生成 500 个 4KB 文件，10 秒窗口最多占 20MB，那就设 size=64M（留余量）
– mode=1755：保证 sticky bit，避免不同用户进程互相删文件
– uid/gid：限定属主，例如 Nginx 缓存用 uid=www-data,gid=www-data
– nr_inodes=20k：防小文件撑爆 inode（尤其秒级打点类缓存）
示例：
sudo mount -t tmpfs -o size=64M,mode=1755,uid=1001,gid=1001,nr_inodes=20k tmpfs /var/run/myapp_cache
开机自动+安全兜底不能少
/etc/fstab 必须加一行，格式严格用 Tab 分隔：
tmpfs /var/run/myapp_cache tmpfs defaults,size=64M,mode=1755,uid=1001,gid=1001,nr_inodes=20k 0 0
执行 sudo mount -a 测试语法，无输出即成功。
额外建议：
– 加 swap_mode（如内核支持）：内存紧张时自动借 swap，防 OOM
– 配合 cgroups 限服务内存上限，避免缓存暴涨拖垮整机
– 不用于含未落盘状态的缓存（如订单中间状态），只放纯临时、重建成本＜50ms 的数据
验证和盯住真实水位
挂完别信 df 显示的“已用 100%”——那是逻辑分配量，不是真实内存占用：
– 看真实 RAM 消耗：grep Shmem /proc/meminfo（Shmem 字段反映所有 tmpfs 总用量）
– 查单个挂载点：df -hT /var/run/myapp_cache 确认类型是 tmpfs，mount | grep myapp_cache 核对选项
– 实时盯增长：watch -n 1 'find /var/run/myapp_cache -type f | wc -l' + df -h /var/run/myapp_cache
– 基准对比：用 wrk -t4 -c100 -d30s http://localhost/endpoint 测挂载前后 p95 延迟变化
