ps aux | grep 显示的RSS不准，因其包含重复计算的共享内存、未聚合多进程、且grep自身干扰；真实物理内存应看/proc/[pid]/status中的VmRSS或用smem的PSS/USS。
ps aux | grep 后为什么看不到真实 RSS 值
直接用 ps aux | grep nginx 查到的 RSS 常常不准，因为 grep 进程本身也会被列出来，且父子进程（如 nginx master + worker）的内存是分开统计的，ps 默认只显示单个线程或轻量级进程的快照，不聚合。更关键的是：RSS 是驻留集大小，但未扣除共享页——多个 worker 共享的代码段、libc 等会被重复计入。
- 用
pgrep -f "nginx: master"或pidof nginx获取主进程 PID，避免匹配到 grep 自身 - 若服务启用了多 worker（如 nginx、redis），应查所有相关 PID：
pgrep -f "nginx:" - 想看总占用？别只信单行
RSS，改用smem -P nginx -c "pid pss rss"，它会自动聚合并用PSS（比例化共享内存）给出更公平的数值
/proc/[pid]/status 里哪个字段代表真实物理内存
/proc/[pid]/status 是内核提供的权威来源，但字段含义容易混淆。VmRSS 是最接近“该进程实际占多少物理内存”的指标，单位是 kB；而 VmSize 是虚拟地址空间总量（含 mmap、未分配的 brk 区域），不能反映真实压力。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
VmRSS：实际加载进物理内存的页数，包含堆、栈、私有数据段和部分共享库的已使用页 -
VmData和VmStk可辅助判断是否堆内存持续增长（疑似泄漏） - 注意：
VmRSS不等于ps的RSS—— 后者可能四舍五入或受调度延迟影响，前者是瞬时精确值 - 示例命令：
cat /proc/$(pidof nginx)/status | grep VmRSS
pmap -x 输出里哪些行真正算“进程独占”内存
pmap -x [pid] 展开每个内存段的细节，但多数段是共享的（如 libc、ld.so）。真正属于该进程“独占且脏”的只有 [heap] 和末尾标记为 [anon] 的私有匿名映射段——它们的 Kbytes 加起来才接近 USS（Unique Set Size），即不会被其他进程分摊的部分。
- 过滤关键段：
pmap -x $(pidof nginx) | awk '$3 ~ /^\[/ && $4 == "rw-p" {sum += $2} END {print sum}' -
[stack]段通常很小（几 MB），但若程序递归过深或线程过多，这里会异常膨胀 - 大量
[anon]:行（无文件名、权限含w）是 malloc/new 分配的堆内存，增长快就该怀疑泄漏 - 别被
total行迷惑——它含所有映射（包括只读代码段、未访问的 mmap 区域）
为什么 smem 比 ps 更适合对比多个同名进程
当运行多个相同命令的实例（如 10 个 python script.py），ps aux --sort=-%mem 会把它们按各自 %mem 排序，但共享库内存被重复计算，导致总和虚高；smem 则基于 /proc/[pid]/smaps 中的 PSS 字段，把共享页按参与进程数均摊，结果可加总。
- 查全部 python 进程的 PSS 总和：
smem -P python -c "pss"→ 输出单列数字（kB） - 对比 USS（独占）和 PSS（均摊后）：
smem -P python -c "uss pss"，差值越大说明共享越充分 - 没装 smem？可用临时方案：
awk '/^Pss:/ {sum += $2} END {print sum}' /proc/[pid]/smaps，但需手动遍历每个 PID
VmRSS；是评估长期泄漏趋势？盯 [heap] 在 pmap 中的增长；是要横向比较同类服务资源开销？必须用 smem 的 PSS。工具本身没对错，错的是把 ps RSS 当成铁律去算总账。 
