smap测评：避坑版
smap测评不能只说好不好用，重点是它在哪些地方会误导人。我按真实排障流程拆一遍：从确认口径到读取成本，再到字段解释和后续验证。很多误判不是工具错，是把 RSS、PSS、Size 混成了一个数。
步骤一：先确认你测的是什么
第一坑是名字。很多人口头说 smap，实际文件是 /proc/[pid]/smaps；如果系统支持，还会有 /proc/[pid]/smaps_rollup。前者是逐段明细，后者是汇总。测评时不分这两个，结论会很飘。
我的判断：smaps 适合深挖，smaps_rollup 适合快速采样。一个 Java 进程完整 smaps 可能非常长，rollup 几十行就能看到总 PSS、RSS、Private_Dirty，排障起手更轻。
步骤二：别拿RSS直接定罪
第二坑是看 RSS 就喊泄漏。RSS 包含共享页，同一批共享库可能在多个进程里重复显示。多进程模型下，只按 RSS 加总，很容易算出一个比机器内存还离谱的数字。
测评 smap 的价值，就在 PSS 这个字段。它把共享页按比例分摊，容量评估更稳。RSS 适合观察驻留压力，PSS 适合回答“这个进程大概该背多少账”。
步骤三：把Size当线索别当证据
第三坑是看到某段 Size 几十 GB 就紧张。很多运行时、数据库、内存分配器会预留大块虚拟地址空间，并不代表物理内存真用了这么多。64 位系统地址空间宽，预留并不稀奇。
真正要盯的是 Rss、Pss、Private_Dirty。如果 Size 巨大但 Rss 很小，通常不是当前内存压力来源；如果 Private_Dirty 持续上涨，才值得继续追分配路径。
步骤四：注意读取成本
第四坑是把 smaps 当高频监控指标采。读取完整 smaps 需要内核遍历映射并统计页面信息，进程越复杂越贵。在线上每秒读一遍，等于给问题现场又加了一个变量。
更合适的流程是：平时采 cgroup、RSS、PSS rollup；超过阈值时抓一份完整 smaps；必要时隔 30 秒再抓一份做 diff。看变化，比看单张截图更有价值。
步骤五：测完必须验证
smap 的结论要落到后续工具上。匿名私有页上涨，用 heap profiler 或分配器统计验证；文件映射异常，查 mmap、fd、deleted 文件；线程栈多，核对线程数；Swap 上升，回看节点整体压力。
我的测评结论很明确：smap 是优秀的内存分诊工具，不是万能诊断仪。它最强的地方是把方向缩小，最容易踩坑的地方是把字段当成最终答案。
常见问题
smap测评结果准吗？
字段本身来自内核统计，可信度高；但解释要看口径。RSS、PSS、Size 含义不同，混用就会得出错误结论。
smap会影响线上性能吗？
偶尔读取通常影响很小，高频读取完整 smaps 不推荐。映射很多的进程读取成本更明显，监控采样优先选 smaps_rollup。
smap能测容器内存吗？
能看容器内进程的内存映射，但容器总内存还要结合 cgroup 指标。单个进程 smaps 不能替代 memory.current 这类容器口径。