共享内存段占用过高会直接挤占物理内存，导致OOM Killer触发、Swap频繁启用及服务崩溃；其为IPC分配的不可自动回收内存，需主动识别清理。
共享内存段（Shared Memory Segments）占用过高，会直接挤占物理内存，导致系统可用内存锐减、触发 OOM Killer、Swap 频繁启用，甚至服务响应变慢或崩溃。这不是缓存，而是内核为进程间通信（IPC）分配的不可自动回收的内存，需主动识别和清理。
确认共享内存是否真的过高
先看系统级总量是否异常：
- 运行
cat /proc/meminfo | grep -i "Shmem\|SReclaimable"：
– Shmem 表示 tmpfs 和 shm 段总占用（计入 MemUsed）；
– 若 Shmem 值远超预期（如 >1GB 且无大内存数据库/缓存服务），需深入排查。 - 对比
free -h中 available 值与 MemFree + Buffers + Cached 的差值：若差值接近 Shmem 大小，说明共享内存是主要“吃内存者”。
定位具体共享内存段和所属进程
分两层查：先看 IPC 共享内存段，再关联到使用它的进程：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 列出所有 System V 共享内存段：
ipcs -m
关注 bytes 列（大小）、nattch（当前附加进程数）、pid（最后操作该段的进程 ID）。 - 查看 POSIX 共享内存（
/dev/shm下）：df -hT /dev/shm看挂载容量和使用率；ls -lSh /dev/shm/按大小排序文件，找大文件或残留文件。 - 反向追踪：对可疑段 ID（如
0x12345），用ipcs -m -i 0x12345查详细信息；再用lsof +D /dev/shm或find /proc/[0-9]*/fd -lname "/dev/shm/*" 2>/dev/null找出哪些进程打开了这些文件。
判断是否属于正常业务或异常残留
不能一删了之，要区分用途：
-
合理占用：PostgreSQL 的 shared_buffers、Redis 的 AOF 重写临时段、某些 Java 应用通过
shm_open实现高性能 IPC——这些需结合业务确认是否配置合理。 -
异常残留：进程崩溃后未释放的 shm 文件（
/dev/shm/xxx.pid）、旧版程序未调用shm_unlink、测试脚本反复创建未清理的段——这类可安全清理。 - 检查
ipcs -q（消息队列）和ipcs -s（信号量）是否也堆积，它们常与共享内存配套使用，同样不自动释放。
清理与长期防护
清理要谨慎，优先从用户态入手：
- 删除
/dev/shm下明确无用的文件：rm -f /dev/shm/old_temp_* - 移除未被任何进程附加的 System V 段：
ipcs -m | awk '$5 == 0 {print $2}' | xargs -I{} ipcrm -m {}（慎用，确认 nattch=0） - 限制 tmpfs 大小防失控：
临时：mount -o remount,size=512M /dev/shm
永久：在/etc/fstab中修改tmpfs /dev/shm tmpfs defaults,size=512M 0 0，再mount -o remount /dev/shm。 - 代码层面：确保应用在退出前调用
shm_unlink()（POSIX）或shmctl(..., IPC_RMID)（System V）；生产环境避免在/dev/shm存储非临时数据。
