用 ps -p pid -o pid,comm,%cpu,%mem,rss,vsz,etime 可精准查单个进程的cpu、内存（rss/vsz）、运行时长等核心指标，避免grep干扰；未知pid时优先用pgrep -f或pidof获取。
怎么用 ps 快速定位某个进程的内存和 CPU 占用
直接查单个进程，别靠 grep 后再人工找，容易漏掉同名子进程或匹配到 grep 自身。用 ps 的 -p 选项精准指定 PID 最稳：
-
ps -p 1234 -o pid,comm,%cpu,%mem,rss,vsz,etime—— 替换1234为真实 PID，只输出该进程核心指标 -
%cpu和%mem是百分比，rss是实际物理内存（KB），vsz是虚拟内存（KB） - 如果不知道 PID，先用
pgrep -f "nginx: master"或pidof nginx获取，避免用ps aux | grep nginx多出一行grep进程干扰判断 -
etime表示进程已运行秒数，有助于区分新启进程和长时驻留进程
为什么 /proc/[pid]/status 比 ps 更准，但字段难懂
ps 的 rss 和 /proc/[pid]/status 的 VmRSS 理论上一致，但后者是内核直接上报值，不受用户态采样延迟影响；不过它混在几十行文本里，得过滤：
-
grep VmRSS /proc/1234/status→ 输出类似VmRSS: 189456 kB，这就是当前精确物理内存占用 -
VmSize是总虚拟内存，VmData是数据段（堆），VmStk是栈，三者加起来通常远小于VmSize，差额主要是 mmap 映射的共享库和文件 - 注意：同一进程多次读取
/proc/[pid]/status可能数值微变，这是正常现象，内核在动态回收页框
pmap -x 能看出什么隐藏内存问题
当 rss 高但业务逻辑简单时，pmap -x 是排查泄漏或异常映射的关键工具：
-
pmap -x 1234输出每块内存区域的Kbytes（大小）、RSS（实际驻留）、Mode（权限），最后一行的mapped和shared是重点 - 如果
shared值极小（比如0），而mapped很大，说明大量内存没被共享——可能是重复加载相同库，或用mmap分配了私有匿名区但没释放 - 看到一堆
[anon]区域且RSS累计很高，大概率是堆内存泄漏；看到大量.so文件但RSS很低，说明共享库加载了但没常驻，属正常
别忽略 smem 的 PSS——共享内存怎么算才公平
多个进程共用同一个动态库或 mmap 文件时，rss 会重复统计，导致总量虚高。smem 的 PSS（Proportional Set Size）把共享内存按参与进程数均摊：
- 安装后运行
smem -p -P nginx，看PSS列，比RSS更反映该进程“真实”内存开销 - 例如：5 个 Java 进程共用 100MB 的 JVM 共享代码缓存，
rss每个都算 100MB，PSS每个只算 20MB - 没装
smem时，cat /proc/1234/smaps | awk '/^Pss:/ {sum += $2} END {print sum " kB"}'可手动提取 PSS 总和
实际排查时，rss 和 PSS 要对照看：前者告诉你“物理内存压力在哪”，后者告诉你“哪个进程该优化”。共享内存占比高的服务（如数据库、Web 服务器），跳过 PSS 容易误判。
