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 值也不会变。
