ipcs -m 是最直接查看 System V 共享内存段的命令，显示 key、shmid、owner、perms、bytes（大小）、nattch（附加进程数）等字段；非 root 用户默认仅见自己创建的段，需 sudo ipcs -ma 查全部；它不依赖进程运行状态，只读内核 IPC 数据。
ipcs -m 是最直接、最常用的查看共享内存占用的命令。它不依赖进程状态，也不需要 root 权限（只要能读取 IPC 信息），能立刻列出所有 System V 共享内存段的 key、shmid、owner、大小和附加进程数。
怎么用 ipcs -m 快速定位高占用段
输出中 bytes 列就是每段共享内存的字节数，nattch 表示当前有多少进程正附加（attach）着它：
- 若
bytes很大（比如 >100MB）且nattch == 0，说明这段内存已无人使用但未释放，属于泄漏风险点 - 若
nattch > 1且bytes持续增长，需结合ipcs -m -p查看cpid和lpid，再用ps -p PID -o pid,comm,args定位是哪个程序在反复写入 - 避免只看
ipcs -m | tail -n +2 | awk '{sum += $5} END {print sum}'算总和——$5是nattch，不是bytes；正确求和应为：ipcs -m | tail -n +2 | awk '{sum += $4} END {print sum}'（$4是bytes）
为什么 ipcs -s 查信号量时经常看到大量 nsems == 1 的条目
每个信号量集（semaphore set）可含多个信号量（nsems），但很多程序（如 PostgreSQL、Oracle 客户端、旧版 Java 应用）习惯为每个资源单独创建一个单信号量集，导致系统里堆积大量 nsems == 1 的条目：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
ipcs -s | wc -l超过 100 通常就值得警惕，尤其当ipcs -l显示max number of semaphore sets接近上限（默认通常是 128 或 256） - 信号量不会自动清理，即使创建它的进程已退出；必须显式调用
semctl(..., IPC_RMID)或用ipcrm -s semid - 注意：POSIX 信号量（
/dev/shm/sem.xxx）不归ipcs管理，得用ls /dev/shm | grep sem配合lsof查
ipcs -l 显示的限制值到底影响什么
ipcs -l 输出的是内核硬限制，不是建议值。一旦触及，后续 shmget 或 semget 会直接失败并返回 errno = ENOSPC：
-
max number of shared memory segments：整个系统最多允许多少个独立的共享内存段（非字节大小） -
max size of shared memory segment：单个段最大字节数（常见默认为 32MB，64 位系统可能达 4GB） -
max number of semaphores per semaphore set：单个信号量集最多含几个信号量（注意不是“系统总共”） - 这些值可通过
/proc/sys/kernel/shmmni、/proc/sys/kernel/shmmax等临时修改，但重启失效；永久生效要写入/etc/sysctl.conf
真正容易被忽略的是：System V IPC 对象的生命周期与进程无关，只与内核和显式删除动作有关。哪怕所有相关进程都退出了，只要没调用 shmctl(..., IPC_RMID) 或执行 ipcrm，那段内存或那个信号量集就一直占着 ID 和内核资源——这也是为什么运维查 ipcs -m 时总能看到一堆 “僵尸段”。
