如何在Linux中查看共享内存大小
ipcs -m 的 bytes 列才是 System V 共享内存真实大小,因其直接读取内核 shmid_ds.shm_segsz 字段,反映 shmget() 指定且页对齐后的固定值,不随进程读写变化。ipcs -m 仍然是查看 System V 共享内存大小最直接、也最稳妥的办法,里面的 byt
ipcs -m 的 bytes 列才是 System V 共享内存真实大小,因其直接读取内核 shmid_ds.shm_segsz 字段,反映 shmget() 指定且页对齐后的固定值,不随进程读写变化。

ipcs -m 仍然是查看 System V 共享内存大小最直接、也最稳妥的办法,里面的 bytes 列,显示的就是每一段共享内存对应的实际字节数。至于 free 或 top 里的 shared 字段,别混为一谈——它统计的只是进程之间共享的物理页,和 IPC 共享内存并不是一回事。
为什么 ipcs -m 的 bytes 才是真实大小
System V 共享内存段在内核中独立存在,bytes 字段来自内核 shmid_ds.shm_segsz,是创建时 shmget() 指定的 size 值(经页对齐后),不会因进程读写而动态变化。常见误解:
- 误把
free -h输出里的shared当作共享内存总量——它只是tmpfs和匿名页共享的粗略估算,不含 System V 段 - 用
ps查SHR列——那是进程私有映射中“可能被共享”的部分,无法反推某段 IPC 内存是否被占用 - 看
/dev/shm/下文件大小——这只反映 POSIX 共享内存(shm_open()创建),和shmget()完全无关
快速定位大段或泄漏段:盯住 bytes 和 nattch
执行 ipcs -m 后,重点关注这两列组合:
bytes很大(比如 >50MB)且nattch == 0→ 段已无人 attach,但未调用shmctl(shmid, IPC_RMID, NULL),属于典型泄漏bytes中等(如 1–10MB)但nattch持续波动 → 可能有进程反复shmat()/shmdt(),需结合ipcs -m -p查cpid/lpid,再用ps -p PID -o pid,comm,args确认进程行为- 想算总占用?用
ipcs -m | tail -n +2 | awk '{sum += $4} END {print sum}'——注意是$4(bytes),不是$5(nattch)
查不到你代码创建的段?先确认用的是哪套 API
如果你的程序用了 mmap() + /dev/shm/myseg,ipcs -m 一定为空——它只管 System V(shmget/shmctl)。此时该换命令:
- 查 POSIX 段:
ls -lh /dev/shm/(大小即文件大小) - 看整体占用:
df -h /dev/shm(受shmmax和shmall限制,但和 System V 的/proc/sys/kernel/shm*参数无关) - 验证是否真用了 POSIX:代码里有没有
shm_open()或open("/dev/shm/xxx")?有就是它
很多人最容易忽视的,恰恰是这一点:System V 共享内存段只要一创建出来,就会脱离进程生命周期,单独留在系统里;哪怕相关进程已经全部退出,只要没有显式删除(shmctl(..., IPC_RMID) 或 ipcrm -m shmid),它就会一直占用内核资源,bytes 的值也不会发生变化。

































