Linux怎么查看占用原因分类统计

/proc/[pid]/status 会把进程内存按更细的口径拆开，同时给出一组很关键的运行状态信息：比如 VmData（堆）、VmStk（栈）、VmExe（代码段）、VmLib（共享库）、VmRSS（包含共享页的驻留内存）；除此之外，还能看到 State、Threads、上下文切换次数以及 CapEff 等常用诊断字段。

直接读 /proc/[pid]/status 获取内存用途硬分类

想搞清一个进程的内存到底“花在哪”，别信 top 的 RES 或 ps 的 RSS ——它们只是总和，不区分堆、栈、代码、共享库。真正能拆开看的，只有内核提供的原始快照：/proc/[pid]/status。

这个文件里的 VmData、VmStk、VmExe、VmLib、VmRSS 等字段，是内核按内存用途强制划分的，没有采样、不聚合、不估算，就是当前真实映射状态。

• VmData：堆内存（brk/sbrk、大部分 malloc 分配）
• VmStk：用户栈（通常很小，固定上限约 8 MB）
• VmExe：可执行文件的代码段（.text）
• VmLib：所有共享库（如 libc.so、libpthread.so）映射大小
• VmRSS：当前驻留物理内存总量（含上述全部 + 共享页，不是独占内存）

快速提取示例：
cat /proc/1234/status | grep Vm

VmRSS 不等于进程实际独占内存

很多排查误判就栽在这里：看到 VmRSS 是 500 MB，就认定这进程“吃了 500 MB 物理内存”，结果发现系统还有大量空闲 RAM，OOM Killer 却反复触发。原因很简单——VmRSS 包含共享页。

比如 10 个进程都用了 libc.so，每个的 VmLib 可能是 2 MB，VmRSS 也都计入这 2 MB，但物理内存里只有一份 libc 代码页。内核不会去 dedup 这些共享页，VmRSS 就是“每个进程视角下的驻留页总数”。

真正反映独占物理内存的是：
– VmData（堆） + VmStk（栈） + VmExe（私有代码段）
– 再减去 mmap 映射中可能存在的共享匿名区（需结合 /proc/[pid]/maps 判断）

用 smem 做共享内存去重统计

如果目标是评估“这个进程实际新增了多少物理内存压力”，smem 是比 ps 或 top 更靠谱的选择。它基于 /proc/[pid]/smaps，能对共享页做近似去重计算。

安装后直接运行：
smem -P nginx -c "pid name uss pss rss"

关键字段含义：
– uss（Unique Set Size）：该进程独占的物理内存（最接近“真实新增开销”）
– pss（Proportional Set Size）：共享页按进程数均摊后的值（适合横向比较）
– rss：等同于 VmRSS，不做去重

注意：smem 需 root 权限才能读取所有 smaps；非 root 用户只能看到自己进程的 uss/pss。

别忽略 /proc/[pid]/status 里的非内存线索

除了 Vm* 字段，这个文件还藏着几个常被跳过的诊断关键点：

• State：进程当前内核态状态（R运行、S可中断休眠、D不可中断休眠），比 ps 的 STAT 更底层
• Threads：当前线程数，比 ps -T -p [pid] 更快，适合排查线程泄漏
• voluntary_ctxt_switches 和 nonvoluntary_ctxt_switches：主动 vs 被动上下文切换次数；后者持续升高，往往意味着 CPU 竞争激烈或锁争用严重
• CapEff：有效 capabilities，权限问题排查时比 getpcaps [pid] 更直接

查一个 PID 时，别只 grep Vm ——顺手加一句 grep -E "State|Threads|voluntary|CapEff"，常能提前发现异常模式。