共享内存段占用过高会直接挤占物理内存，导致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 存储非临时数据。