必须用pmap -x pid，因只有该形式显示rss和dirty两列，二者是判断内存真实占用与泄漏的唯一直接依据；pmap不接受进程名，只认数字pid，需用pgrep -f、systemctl show或ps -o pid,ppid,comm等命令准确获取。
pmap -x PID 是唯一可靠的方式，其他形式基本没用——不加 -x 就看不到 RSS 和 Dirty，而这两列是判断内存是否真实占用、是否存在泄漏的唯一直接依据。
为什么必须用 pmap -x PID，而不是 pmap 进程名
pmap 只接受数字 PID，不解析进程名。直接运行 pmap nginx 或 pmap python3 会报 illegal process ID 错误。
- 查带参数的 Python 应用：
pgrep -f "myapp.py"（比ps aux | grep干净，不会匹配到grep自身） - 查 systemd 服务主进程：
systemctl show --property MainPID nginx.service | cut -d= -f2 - 查多个同名 nginx worker 中哪个是 master：
ps -o pid,ppid,comm -C nginx，找PPID为 1 的那一行
pmap -x 输出里哪几列最关键
输出固定 6 列：Address、Kbytes、RSS、Dirty、Mode、Mapping。重点关注：
-
RSS总和 ≈ 进程真实物理内存占用（单位 KB），ps -o rss= -p PID的值应与之接近 -
Dirty高且持续增长，说明某段内存（如[anon]或[heap]）在频繁写入但未释放 -
Mode为rw-p的[heap]行，若RSS> 100MB 且随时间上涨，是堆泄漏第一嫌疑对象 -
Mapping为空或为[anon]的行，代表匿名映射（如mmap(MAP_ANONYMOUS)、Pythonarray.array底层分配），多个小块累加 RSS 很大，说明 native 层分配失控
遇到 Permission denied 或输出为空怎么办
这不是权限配置错误，而是内核主动拒绝暴露 /proc/PID/maps 内容——这是安全机制，不是故障。
- 普通用户对其他用户启动的进程（如 root 启动的 nginx）默认无权读取，
sudo pmap -x PID可绕过，但看到的仍是该进程当时的映射快照，不是“提权后才有的” - 某些容器或严格 SELinux 策略下，即使
sudo也可能失败，此时需换用cat /proc/PID/maps（同样需权限）或改用/proc/PID/status查VmRSS - 输出为空 ≠ 进程不存在，可能是 PID 已退出，或被内核隐藏（如某些 eBPF 安全模块干预）
真正容易被忽略的是：你看到的 pmap -x 输出是一瞬间的快照，不能代替趋势观察；单次结果里 [heap] RSS 高，未必是泄漏——得连续采样对比，否则可能把正常业务峰值误判为问题。
