ipcs -l 显示的是内核硬限制，超限则 semget 返回 enospc；max number of semaphore sets 易耗尽，因多程序为单资源建单信号量集（nsems==1），且集不随进程退出自动销毁，须手动 ipcrm 或 semctl(..., ipc_rmid) 清理。
直接看 ipcs -l，它输出的就是内核硬限制，不是建议值，超了 semget 就会返回 ENOSPC。
为什么 ipcs -l 显示的 max number of semaphore sets 很容易被耗尽
很多程序（PostgreSQL、旧版 Java、Oracle 客户端）习惯为每个资源单独建一个信号量集，且只放 1 个信号量（nsems == 1）。结果就是：系统上限是 128 或 256 个信号量集，但实际只用了不到 10% 的总信号量数，却卡在“集数”上。更麻烦的是，这些信号量集不会随进程退出自动销毁——哪怕创建它的进程早死了，只要没调用 semctl(..., IPC_RMID) 或手动 ipcrm -s semid，它就一直占着 ID 和内核 slot。
ipcs -s 输出里 nsems 列到底代表什么
nsems 是该信号量集里**包含的信号量个数**，不是当前使用中的数量，也不是系统总信号量数。常见误解：
- 误以为
nsems越大越危险 —— 其实单个集含 100 个信号量，远不如 100 个各含 1 个信号量的集对max number of semaphore sets构成威胁 - 用
ipcs -s | awk '{sum += $5}' END {print sum}算总信号量数 —— 错，$5 是nsems，但表头不固定；安全做法是ipcs -s | tail -n +2 | awk '{sum += $4} END {print sum}（$4 在标准输出中才是nsems） - 看到
nsems == 1就删 —— 不一定该删，得先确认是否还有进程在用：ipcs -s -p semid查cpid（创建者）和lpid（最后操作者），再用ps -p cpid,lpid -o pid,comm,args验证
如何安全清理僵尸信号量集
不能靠“猜”，得验证再删：
- 先查谁在用：
ipcs -s -p semid，如果cpid和lpid都是 0 或对应进程已不存在（kill -0 PID返回失败），基本可判为僵尸 - 批量清理所有无关联进程的信号量集：
ipcs -s | tail -n +2 | awk '$4 == 1 && $5 == 0 {print $2}' | xargs -r ipcrm -s（注意：$4 是nsems，$5 是nattch？不对 ——ipcs -s输出列顺序是key semid owner perms nsems，所以nattch并不在其中；真正能反映“无人使用”的是ipcs -s -c或结合ipcs -s -t看最后访问时间） - 最稳妥方式：只删明确已废弃的，比如测试程序留下的；生产环境优先改应用逻辑，让其退出前调用
semctl(semid, 0, IPC_RMID) - 临时扩容（仅应急）：
sudo sysctl -w kernel.sem="250 32000 32 128"；永久生效写入/etc/sysctl.conf，但要注意这会放宽整个系统的同步粒度控制
真正难处理的从来不是“怎么删”，而是“删完之后，那个本该自己清理却没清理的应用，下次启动又悄悄建一堆新的”。System V IPC 对象的生命周期完全脱离进程，这点必须刻进运维直觉里。
