必须用pmap -x pid，因只有该命令固定输出address、kbytes、rss、dirty、mode、mapping六列，其中rss反映真实物理内存占用，dirty指示未释放的写入内存；其他参数无法提供这两项关键数据。
pmap -x PID 是唯一能直接看到 RSS 和 Dirty 的方式，其他参数基本没用——不加 -x 就等于没看内存实际占用。
为什么必须用 pmap -x PID 而不是 pmap 或 pmap -XX
pmap（无参数）只输出地址、大小、权限和映射名，完全看不到物理内存占用；pmap -XX 字段冗余，包含大量重复的页表统计项（如 MMUPageSize），干扰判断。只有 pmap -x 固定输出 6 列：Address、Kbytes、RSS、Dirty、Mode、Mapping，刚好覆盖泄漏诊断核心维度。
其中 RSS 总和 ≈ 进程真实物理内存（单位 KB），Dirty 持续增长说明某段内存在频繁写入但未释放。
怎么拿到准确的 PID 而不是猜进程名
pmap python3 或 pmap nginx 会报错：illegal process ID——pmap 只认数字 PID，不解析进程名。
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 查带参数的 Python 应用：
pgrep -f "myapp.py"（比ps aux | grep干净，避免匹配到grep自身） - 查 systemd 服务主进程：
systemctl show --property MainPID nginx.service | cut -d= -f2 - 多个同名进程里找真正干活的：先
ps -o pid,ppid,comm -C nginx，找PPID为 1 的那个（master 进程）
从 pmap -x 输出里快速识别三类关键区域
不用逐行读完全部输出，盯住 Mapping 列，按优先级扫这三类：
-
[heap]：权限通常是rw-p，Kbytes和RSS若远超预期（比如 >100MB 且随时间上涨），就是堆泄漏第一嫌疑对象 -
[anon]：匿名映射，没有文件路径，常见于mmap(MAP_ANONYMOUS)、JVM DirectBuffer、Python 的array.array底层分配；多个小块[anon]的RSS累加很大，说明 native 层分配失控 - 共享库分段：同一个
.so（如libcrypto.so.1.1）可能有 3–4 行，分别对应r-xp（代码）、rw-p（数据）、r--p（只读数据）；若某一行RSS异常高，可能是该库内部静态缓冲区膨胀
Permission denied 或输出为空时怎么办
普通用户执行 pmap -x 12345 报 Permission denied，不是权限不够导致“看不到”，而是内核拒绝暴露该进程的 /proc/12345/maps 内容——这是安全机制，不是错误。
- 对 systemd 服务（如
mysql、redis），用sudo pmap -x $(systemctl show --property MainPID mysql.service | cut -d= -f2) - 如果
pmap -x输出只有 header 没有数，大概率是目标进程设置了PR_SET_DUMPABLE=0（比如被gdb附着过），此时sudo也无效，得换用/proc/PID/smaps手动分析
真正容易被忽略的是：RSS 高 ≠ 泄漏，要结合 Dirty 和 Mapping 类型交叉判断；[heap] 和 [anon] 看似相似，但前者来自 brk，后者多来自 mmap，排查工具和路径完全不同。
