/dev/shm 耗尽会导致“No space left on device”错误，即使 df - h 和 df - i 显示正常，因其为 tmpfs 内存文件系统，需用 df -h /dev/shm、ipcs - m 和 lsof +D /dev/shm 定位占用进程，清理需终止进程而非仅删文件，扩容可 remount 或修改 fstab。
tmpfs /dev/shm 耗尽导致 no space left on device
即使 df -h 显示磁盘空间充足、df -i 显示 inode 也远未用尽，但程序仍报 No space left on device，极大概率是 /dev/shm（tmpfs 类型）被占满。它不计入根文件系统统计，df -h 默认也不显示 tmpfs 挂载点，必须显式检查。
-
df -h /dev/shm或df -h -t tmpfs查看所有 tmpfs 使用情况 - 默认大小通常为 64MB（部分内核版本为 1/2 内存），但可通过
mount命令确认实际限制：mount | grep shm→ 看size=参数 - 常见占用者：PostgreSQL 的 shared memory segments、Java NIO 的
DirectByteBuffer（通过/dev/shm映射）、TensorFlow/PyTorch 的共享内存数据加载器（num_workers > 0时）、自定义shm_open()+mmap()应用
定位 /dev/shm 下具体大文件或匿名段
/dev/shm 下的文件通常是命名共享内存对象（如 /dev/shm/psql-12345），但也可能是无名段（不显示为文件）。仅靠 ls -lSh /dev/shm 不够，需结合 ipcs -m 和 lsof：
-
ipcs -m -l查看系统级共享内存限制（max number of segments,max seg size (bytes)） -
ipcs -m列出当前所有共享内存段，关注SEGSZ（大小）和CPID（创建进程 PID） -
lsof +D /dev/shm查看哪些进程打开了/dev/shm下的文件或映射段（注意：部分匿名映射可能不显示） - 若发现可疑 PID，用
cat /proc/确认其 mmap 区域是否挂载自 shm/maps | grep shm
临时清理与永久调整方案
清理不能只删文件——rm /dev/shm/xxx 只解除名字绑定，若进程仍在使用，底层内存不会释放。必须终止对应进程，或让其主动释放。
- 临时扩容（重启失效）：
sudo mount -o remount,size=2G /dev/shm - 永久生效（写入
/etc/fstab）：none /dev/shm tmpfs defaults,size=2G 0 0，然后sudo mount -o remount /dev/shm - 应用层规避：PostgreSQL 设置
shared_memory_type = mmap（绕过 shm）；PyTorch DataLoader 改用spawn启动方式或设num_workers=0测试；Java 添加-XX:+UseTransparentHugePages减少小页映射压力 - 监控建议：在 Prometheus 中用
node_filesystem_size_bytes{mountpoint="/dev/shm"}+node_filesystem_avail_bytes做告警
为什么 df -i 看不出问题？
df -i 统计的是文件系统 inode 使用量，而 /dev/shm 是内存文件系统（tmpfs），其“文件”本质是内核中 struct shmid_kernel 或 struct file 对象，不消耗磁盘 inode。它的资源瓶颈是内存页（page）和内核共享内存对象数量，和磁盘 inode 完全无关。
真正该查的是 ipcs -l 输出里的 max number of segments 和 max total shared memory (kbytes)，以及 /proc/meminfo 中的 Shmem: 行 —— 这才是 tmpfs 实际占用的内存总量。
