/dev/shm 被塞满会导致 mysql、postgresql 或 java 应用异常退出或崩溃，因其默认仅 64mb 且程序可能无节制写入 posix 共享内存文件；需通过 df、ls、ipcs 检查，临时清理残留文件，并永久调整 fstab 中 size 参数、规范 tmpdir 配置及建立监控清理机制。
Linux 服务器上 /dev/shm 被塞满，确实会直接导致数据库（如 MySQL、PostgreSQL）或 Java 应用（尤其是使用大量 NIO 或内存映射文件的场景）异常退出甚至崩溃。根本原因是：/dev/shm 是基于内存的临时文件系统（tmpfs），默认大小通常只有 64MB，而某些程序会无节制地往里面写临时共享内存段（如 Oracle 的 shared memory segments、Java 的 java.io.tmpdir 配置不当、或 JNI 使用 shm_open）、或者未清理的 POSIX 共享内存对象（/dev/shm/xxx 文件残留）。
确认 /dev/shm 是否已满
执行以下命令快速检查：
-
df -h /dev/shm—— 查看已用空间和挂载大小 -
ls -l /dev/shm/—— 列出所有共享内存文件，重点关注大文件或大量小文件（如hsperfdata_*、postgresql-*、java_*等） -
ipcs -m—— 查看 System V 共享内存段（注意：这部分不占用 /dev/shm，但常被混淆；真正占 /dev/shm 的是 POSIX 共享内存，即shm_open()创建的）
临时清理方法（应急恢复）
立即释放空间，让服务恢复运行：
- 清空所有非正在使用的 shm 文件：
rm -f /dev/shm/*（谨慎！确保没有活跃进程正依赖其中某个文件） - 更安全的方式：只删明确无主的文件，例如 Java 的
hsperfdata_*（JVM 关闭后残留）：find /dev/shm -name "hsperfdata_*" -delete - 若发现 PostgreSQL 的
PGSQL.*文件长期存在，可能是实例异常退出未清理，可先停库再清理
永久解决：调整 /dev/shm 大小并规范使用
不能只靠清理，必须从配置层面预防：
立即学习“Java免费学习笔记（深入）”；
- 修改
/etc/fstab，增大 tmpfs 大小（例如设为 2GB）：tmpfs /dev/shm tmpfs defaults,size=2g 0 0
执行mount -o remount /dev/shm生效（无需重启） - Java 应用避免把
java.io.tmpdir指向/dev/shm（常见于 Docker 启动脚本误配），应改用/tmp或独立目录，并配好清理策略 - 数据库方面：
– MySQL 一般不直接用 /dev/shm，但若启用了memcached插件或自定义 UDF，需检查其行为
– PostgreSQL 默认不用，但扩展（如pg_cron或外部 FDW）可能间接使用，升级或配置时留意日志
预防机制：监控与自动清理
把问题挡在发生前：
- 加入基础监控项：Zabbix、Prometheus 或自定义脚本定期采集
df /dev/shm | awk 'NR==2 {print $5}'，超过 80% 触发告警 - 设置定时任务清理陈旧 shm 文件（例如 1 小时以上未访问）：
find /dev/shm -type f -mmin +60 -delete 2>/dev/null - 对关键 Java 进程，启动时显式指定
-Djava.io.tmpdir=/var/tmp/myapp，并确保该路径有配额和轮转策略
