排查内存问题需三步：先按m键以%mem降序排列锁定高占比进程（%mem超30%或res达总内存50%+即可疑）；再用free -h查available（低于10%危险）和swap used（近满则oom风险高）；最后用dmesg -t | grep "killed process"确认是否被oom killer终止。
直接用 top 查内存问题，关键不是“打开就看”，而是三步到位：快速切换排序、锁定可疑进程、交叉验证是否真溢出。
按内存使用率排序，一眼揪出“吃内存大户”
启动 top 后，默认按 CPU 排序。排查内存问题时，敲 M（大写），立刻按 %MEM 降序排列。排在最上面的几个进程，就是当前内存占用最高的目标。
重点关注两列：
- %MEM：该进程占用物理内存的百分比。超过 30% 就值得警惕，单个进程占满 50%+ 很可能就是元凶；
- RES（或 RSS）：实际驻留物理内存大小（单位通常是 MiB），比 %MEM 更反映真实开销。比如 RES 达到 2.8GiB，而服务器总内存才 4GiB，基本可以断定异常。
结合 available 和 swap 状态，判断是否已到 OOM 边缘
top 界面顶部会显示内存摘要（如 MiB Mem: 7800 total, 6200 used...），但这里不直观。更可靠的是按下 1 显示所有 CPU 核心后，再按 q 退出 top，立即执行：
free -h重点看这两项：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- available：真正能被新进程使用的内存。若低于总内存的 10%（例如 8G 内存下只剩 600MiB），系统已非常危险；
- Swap used：如果 swap 几乎打满（如 2.0G 中用了 1.9G），说明物理内存早就不够，系统靠磁盘硬扛，响应迟滞、OOM 风险极高。
确认进程是否被 OOM killer 杀过
很多崩溃不是程序自己挂的，是内核主动 kill 的。top 看到某个 Java 或 Node 进程突然消失？马上查日志：
dmesg -T | grep -i "killed process"如果输出类似：
[Tue Jul 28 23:41:05 2026] Out of memory: Kill process 12345 (java) score 897 or sacrifice child那就实锤了——这个 PID 就是刚被干掉的“内存肇事者”，再回 top 里找它历史残留或同名进程，基本就是根因。
进阶技巧：缩小范围，区分泄漏与瞬时高峰
单次 top 只能抓快照。要判断是不是内存泄漏，可连续观察：
- 保持 top 运行，每隔几十秒按 Shift+M 刷新，看某个进程的 RES 是否持续缓慢上涨；
- 或用命令快速轮询：watch -n 2 'ps aux --sort=-%mem | head -5'，每 2 秒刷新一次前 5 名；
- 若 RES 稳定在某值、但 available 持续下降，大概率是 buff/cache 被内核缓存占满（通常不致命）；若 RES 持续涨、swap 也跟着涨，十有八九是泄漏或配置过小。
