Linux /proc/PID/statm 怎样区分虚拟内存与常驻内存

排查 Linux 进程“内存很大”时，/proc/PID/statm 最容易被误读：它给出的不是字节，而是按页计数的七个数字。真正要区分的是两件事：size 表示进程的虚拟地址空间规模，resident 表示当前驻留在 RAM 中的页数近似值。先乘以系统页大小，再结合 shared 判断共享页，才能避免把虚拟内存直接当成物理内存。

快速判断可以记成一句话：看地址空间用 size，看驻留 RAM 用 resident，看文件支持的共享驻留页用 shared；这些值适合快速巡检，要求精确映射时应转向 /proc/PID/smaps 或 smaps_rollup。

• statm 的七列都是页数，必须乘以页大小才是字节量级。
• resident 与 VmRSS 对应，但 Linux 文档明确提示它可能不精确。
• shared 是驻留且由文件支持的共享页近似值，不等于进程独占内存。
• lib 和 dt 在现代 Linux 上属于历史字段，不能拿来做主要结论。

Linux /proc/PID/statm 到底返回什么

读取 /proc/PID/statm 会得到一行空格分隔的数字，顺序固定为 size resident shared text lib data dt。Linux 内核文档和 man-pages 都把这些字段定义为以页为单位的内存使用信息。这里的“页”不是某个应用自己定义的块，而是内核使用的内存页计数；具体字节大小要通过系统页大小换算。

怎样读取 statm 并换算成字节

不要直接把第一列当作 KB。最稳妥的做法是同时读取系统页大小，再将每一列乘以页大小。下面的命令使用当前 shell 的 PID 作为示例；替换成业务进程的 PID 后，可以观察对应进程的快照。

# 读取当前 shell 的 PID；排查业务进程时替换成目标 PID。
PID="$$"

# statm 的数字单位是页，PAGESIZE 用字节给出一页的大小。
PAGE_SIZE="$(getconf PAGESIZE)"
read -r size resident shared text lib data dt 

这个换算只改变单位，不会把近似值变成精确值。页大小通常可以从 getconf PAGESIZE 取得，但不要把某台机器的页大小硬编码到监控脚本里；容器、不同架构或不同内核配置下，显式读取更稳妥。

size 和 resident 为什么经常差很多

size 关注的是进程建立或保留的虚拟地址空间，包含尚未真正驻留在 RAM 的区域。线程栈预留、内存映射、共享库映射以及尚未触碰的匿名区域，都可能让虚拟规模变大。resident 关注的是当前有页在物理内存中的部分，因此通常小于或等于虚拟规模，但它也不是“应用独占 RAM”的同义词。

例如，一个进程映射了较大的文件却只访问其中一小段，size 可能迅速增加，而 resident 只随实际装入内存的页增长。反过来，多个进程共同映射同一个库时，每个进程的 resident 都可能包含这部分驻留页；简单地把多个进程的 RSS 相加，会重复计算共享页。

可以把两个数字放在同一张诊断表里：

shared、lib 和 dt 怎么避免误判

shared 的定义重点是“驻留且由文件支持的共享页”。它不是“所有被多个进程使用的页”的精确审计值，也不是把 resident 减掉后就得到独占内存。匿名共享内存、tmpfs 映射等情况还需要结合 RssShmem 一起理解。

lib 和 dt 仍然出现在接口的七列中，但现代 Linux 文档将它们标为未使用，常见结果为 0。旧资料里可能出现 lrs、drs 等历史命名，阅读时要以当前系统的 man-pages 和内核文档为准，不要把旧表格里的字段解释原样套到新的监控规则。

如果需要快速同时看 statm 和人类可读的 status，可以用下面的检查片段：

# 先确认目标进程目录存在，避免把“进程已退出”误判成内存为 0。
PID="${1:?请传入 PID}"
if [ ! -r "/proc/${PID}/statm" ]; then
  echo "无法读取 /proc/${PID}/statm：进程可能已退出或权限不足" >&2
  exit 1
fi

# statm 保留页数，status 提供更容易阅读的 KiB 字段。
echo "statm:"
cat "/proc/${PID}/statm"
echo "status memory fields:"
grep -E '^(VmSize|VmRSS|RssAnon|RssFile|RssShmem|VmData|VmStk|VmExe|VmLib):' \
  "/proc/${PID}/status"

# 读取 procfs 是快照式观察，前后两次读数不保证来自同一瞬间。
echo "读取完成；请把它作为一次巡检快照，而不是精确计量报告。"

这段命令的价值在于把“页数列”和 status 中的 KiB 字段并排放出来，帮助确认自己是在看地址空间、RSS，还是匿名/文件/共享内存的拆分。它仍然没有解决内核异步统计带来的精度边界。

什么时候应该改读 smaps 或 smaps_rollup

Linux man-pages 明确指出，statm 的部分值因为内核内部的可扩展性优化而不精确。如果任务只是发现“哪个进程的虚拟规模突然变大”或“RSS 是否大致上升”，statm 和 status 的成本低，适合周期性巡检；如果任务是回答“哪一段映射占用最多、PSS 如何按共享比例分摊、究竟是匿名页还是文件页增长”，就需要更详细的接口。

/proc/PID/smaps 按映射列出 Size、Rss、Pss 等信息；smaps_rollup 则提供聚合后的结果。它们需要扫描页表，读取成本更高，所以不适合在每个采样周期无条件读取全部进程。

一个实用的排查顺序是：先用 statm 找到异常进程，再用 status 看匿名、文件和共享内存的粗分，最后只对少数目标读取 smaps_rollup。这样既保留了低成本监控，又不会用一个粗粒度快照承担精确归因的任务。

常见问题

statm 第一列是不是进程实际占用的内存？

不是。第一列 size 是总程序大小，代表虚拟地址空间规模；它可能包含尚未驻留 RAM 的映射和预留区域。判断当前驻留内存，应先看第二列 resident，并注意它仍是近似值。

把 resident 乘以页大小就得到精确 RSS 了吗？

只能得到按 statm 口径换算后的 RSS 近似值。man-pages 对 resident 和 shared 都标注了不精确边界；需要精确、详细的映射统计时，应转向 smaps 或 smaps_rollup。

shared 能不能从 resident 中直接减掉？

不建议这样当作独占内存公式。shared 是驻留且由文件支持的共享页近似值，统计口径和共享关系并不等同于“所有可扣除页”；要做进程间分摊，应使用更合适的 PSS 等详细指标。

为什么 lib 和 dt 总是 0？

这是现代 Linux 的预期现象。当前 man-pages 将 lib、dt 标为自 Linux 2.6 起未使用，常见情况下保持 0；它们保留在七列格式里主要是兼容历史接口。

总结

读 Linux /proc/PID/statm 时，先记住“七列都是页数”。用 getconf PAGESIZE 换算后，size 用来观察虚拟地址空间，resident 用来估计当前驻留 RAM，shared 用来提示文件支持的共享驻留部分。它们很适合做低成本趋势巡检，但不适合作为精确映射审计；出现明确的内存归因问题时，再把范围收窄到 status、smaps 或 smaps_rollup。