/dev/shm 是基于内存的tmpfs，默认64MB，PostgreSQL和Redis依赖其创建共享内存段；占满会导致崩溃、启动失败或连接拒绝。PostgreSQL在高并发、逻辑复制、统计扩展等场景易耗尽空间；Redis在AOF重写、模块扩展、容器部署时可能间接触发占用；其他服务残留文件亦会隐形占用。诊断用df -h /dev/shm和ls -l /dev/shm，缓解可清理或扩容至1G，或PostgreSQL v12+改用mmap。
/dev/shm 是 Linux 系统中基于内存的临时文件系统（tmpfs），默认大小通常为 64MB（部分系统为 512MB 或 1GB，取决于内核版本和配置）。PostgreSQL 和 Redis 都会主动使用 /dev/shm 存放共享内存段，一旦该空间被占满，会导致服务无法创建新的共享内存对象，进而触发崩溃、启动失败或连接拒绝等严重问题。
PostgreSQL 的共享内存需求场景
PostgreSQL 启动时会在 /dev/shm 下创建以 PostgreSQL.xxx 命名的共享内存段，用于进程间通信（如 WAL 共享缓冲、并行查询协调、逻辑复制槽状态等）。以下情况容易快速耗尽 /dev/shm：
- 高并发连接 + 大量并行查询：每个并行工作进程需额外共享内存页，连接数 × 并行度 × 每个 worker 的 shm 开销可能远超默认容量
- 启用了逻辑复制且订阅端堆积大量未消费的变更：逻辑解码中间状态缓存会驻留在 /dev/shm
- 使用 pg_stat_statements 或其他扩展频繁刷新统计信息：某些版本在重载统计时会短暂申请大块共享内存
- PostgreSQL 版本较老（如 9.6 或更早）：对 shm 使用不够节制，且不支持
shared_memory_type = mmap回退机制
Redis 的共享内存使用场景
Redis 本身不直接依赖 /dev/shm，但以下常见业务集成方式会间接触发其占用：
- 启用 AOF 重写（BGREWRITEAOF）时配合子进程 fork：虽然 Redis 主要用 copy-on-write，但在某些内核（尤其开启 transparent_hugepage）下，fork 可能触发 tmpfs 映射，临时放大内存需求
- 使用 Redis Modules（如 RedisAI、RedisJSON）进行大模型推理或批量解析：部分模块为加速数据交换，主动在 /dev/shm 创建命名信号量或共享缓冲区
- 部署在容器中且未限制 shm 大小：Docker 默认只给容器 64MB /dev/shm，Kubernetes Pod 若未设置
securityContext.shmSize，也会继承该限制，而 Redis Cluster 节点间通信或 Lua 脚本大量调用redis.call()可能累积 shm 对象
被忽略的“隐形”占用源
除数据库自身外，同一台机器上的其他服务或脚本也可能持续写入 /dev/shm，导致 PostgreSQL/Redis 启动时“莫名失败”：
- Python 多进程程序（如使用
multiprocessing.SharedMemory）未显式.close()和.unlink()，残留 shm 对象长期不释放 - Java 应用使用
java.nio.channels.FileChannel.map()映射 /dev/shm 下的文件，JVM 退出异常时未清理映射 - 监控 agent（如 collectd、telegraf）采集进程指标时，将临时元数据写入 /dev/shm 且未轮转清理
- CI/CD 构建脚本临时解压大型归档包到 /dev/shm（误以为“快”就安全），忘记清理
快速诊断与缓解建议
发现崩溃后，优先确认 /dev/shm 实际使用情况：
- 运行
df -h /dev/shm查看使用率；ls -l /dev/shm/列出对象，重点关注 PostgreSQL.*、sem.*、redis.* 等前缀文件 - 用
ipcs -m查看系统级共享内存段（注意：tmpfs 中的文件不显示在此，但传统 shm 段会） - PostgreSQL 启动失败时检查日志关键词：
could not create shared memory segment或No space left on device - 临时缓解：清空非关键 shm 文件（
rm -f /dev/shm/PostgreSQL.* /dev/shm/sem.*），但需确保无活跃数据库进程 - 长期方案：调整 /dev/shm 大小（如挂载时指定
size=1G），或让 PostgreSQL 使用 mmap（shared_memory_type = mmap，v12+ 支持），Redis 容器明确设置--shm-size=1g
