必须用pmap -x PID，因只有该格式输出RSS和Dirty两列关键数据以诊断内存泄漏；PID须为数字，可用pgrep -f或systemctl show获取；重点关注[heap]和[anon]行的RSS增长趋势。
必须用 pmap -x PID，其他形式基本没用
直接运行 pmap nginx 或 pmap python3 会报 illegal process ID 错误——pmap 只认数字 PID，不解析进程名。得先拿到 PID：
- 查带参数的 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 PID 输出固定 6 列：Address、Kbytes、RSS、Dirty、Mode、Mapping。其中 RSS 和 Dirty 是唯一直接反映物理内存真实占用与泄漏风险的两列；不加 -x 就看不到它们。
pmap -x 输出里怎么快速定位问题区域
重点关注这几类行：
-
Mode为rw-p的[heap]行：若RSS > 100MB且随时间持续上涨，是堆泄漏第一嫌疑对象 -
Mapping为空或为[anon]的行：代表匿名映射（如mmap(MAP_ANONYMOUS)、Pythonarray.array底层分配），多个小块累加RSS很大，说明 native 层分配失控 -
Mapping显示具体路径（如/lib/x86_64-linux-gnu/libc-2.31.so）且Device非00:00：确认该共享库已加载且有物理文件 backing
总 RSS 值（最后一行）应与 ps -o rss= -p PID 输出接近；偏差过大说明存在未计入的私有映射或内核侧统计口径差异。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
权限不足或输出为空时怎么办
这不是配置错误，而是内核主动拒绝暴露 /proc/PID/maps 内容——这是安全机制，不是故障。
- 普通用户对 root 启动的进程（如 nginx）默认无权读取，可用
sudo pmap -x PID绕过，但看到的仍是该进程当时的映射快照，不是“提权后才有的” - 某些容器或严格 SELinux 策略下，即使
sudo也可能失败，此时可换用cat /proc/PID/maps（同样需权限）或grep VmRSS /proc/PID/status查VmRSS - 输出为空 ≠ 进程不存在，可能是 PID 已退出，或被内核隐藏（如某些 eBPF 安全模块干预）
为什么不能只看一次 pmap -x 就下结论
你看到的是一瞬间的快照，不能代替趋势观察。
- 单次结果里
[heap]的RSS高，未必是泄漏——得连续采样对比（比如每 10 秒跑一次pmap -x PID | tail -n1记录 RSS），否则可能把正常业务峰值误判为问题 -
Dirty持续增长才真正提示写入后未释放，但也要结合Mapping类型判断：如果是[anon]或[heap]，风险高；如果是MAP_SHARED映射的文件，脏页计入Cached是正常行为
真正容易被忽略的是：没有连续观测，就谈不上泄漏分析；而 pmap -x 本身不提供时间维度，得靠外部脚本补足。
