RAMMap 学习笔记（15.2）：Processes / Priority / Summary——从“谁在用”和“谁更重要”看物理内存

RAMMap 学习笔记（15.2）：Processes / Priority / Summary------从"谁在用"和"谁更重要"看物理内存

[RAMMap 学习笔记（15.2）：Processes / Priority / Summary------从"谁在用"和"谁更重要"看物理内存](#RAMMap 学习笔记（15.2）：Processes / Priority / Summary——从“谁在用”和“谁更重要”看物理内存)
- 一、你能从这一篇带走什么？
- [二、Processes 视图：从"用途"到"进程"的桥梁](#二、Processes 视图：从“用途”到“进程”的桥梁)
- - [2.1 它长啥样？](#2.1 它长啥样？)
  - [2.2 常见列怎么解读？](#2.2 常见列怎么解读？)
  - [2.3 怎么用它快速锁定"嫌疑人"？](#2.3 怎么用它快速锁定“嫌疑人”？)
  - - [场景 1：机器疯狂卡 + 内存占用高](#场景 1：机器疯狂卡 + 内存占用高)
    - [场景 2：Chrome / 浏览器占内存到底冤不冤？](#场景 2：Chrome / 浏览器占内存到底冤不冤？)
- [三、Priority 视图：内存也有"贵宾座"和"站票"](#三、Priority 视图：内存也有“贵宾座”和“站票”)
- - [3.1 什么是内存优先级（Memory Priority）？](#3.1 什么是内存优先级（Memory Priority）？)
  - [3.2 Priority 视图长什么样？](#3.2 Priority 视图长什么样？)
  - [3.3 优先级在实际排查中有什么价值？](#3.3 优先级在实际排查中有什么价值？)
- [四、Summary 视图：汇总全局的"内存鸟瞰图"](#四、Summary 视图：汇总全局的“内存鸟瞰图”)
- - [4.1 这页是干嘛的？](#4.1 这页是干嘛的？)
  - [4.2 怎么用 Summary + 其他视图配合？](#4.2 怎么用 Summary + 其他视图配合？)
- 五、实战脚本：一次完整的内存排查小演练
- [六、小结：15.1 + 15.2 拼出"谁在用内存"这半张拼图](#六、小结：15.1 + 15.2 拼出“谁在用内存”这半张拼图)

RAMMap 学习笔记（15.2）：Processes / Priority / Summary------从"谁在用"和"谁更重要"看物理内存

上一篇 15.1 里，我们站在"内存用途（Use）"的视角看账本。

这一篇换个角度：哪几个进程在花钱？谁是大冤种，谁是背锅侠？

一、你能从这一篇带走什么？

看完你应该能做到：

读懂 Processes 视图：
哪个进程占了多少物理内存、多少是私有的、多少是共享/缓存
读懂 Priority 视图：
什么是"内存优先级"，谁的缓存更容易被回收
理解 Summary 视图：
如何把 Use Counts + Processes + Priority 拼成一张"内存总图"
有一份可以复制进自己运维/排错手册的"小流程"：
内存紧张时，先看哪页，再看谁，再看什么列

二、Processes 视图：从"用途"到"进程"的桥梁

2.1 它长啥样？

切到 Processes 标签，你会看到类似这样的表（示意）：

text 复制代码

Process         PID   Total   Private   Standby   Shareable   ...
---------------------------------------------------------------
chrome.exe      4321  1,234   900       120       214        ...
sqlservr.exe    2100  2,048   1,800      50       198        ...
explorer.exe    1024   300    200        5        95        ...
...

这页的核心是：

把 15.1 中那些"Use 类型"，按进程 拆开统计。

2.2 常见列怎么解读？

不同版本的 RAMMap 列名略有差异，但核心概念类似，一般会看到：

Process / PID
- 进程名 + 进程 ID
- 建议和 Process Explorer / 任务管理器交叉验证
Total
- 这个进程当前关联的物理页总量（以 MB/页数展示）
- 可以当作"这个进程在物理内存里存在感多大"
Private
- 进程独占的物理内存（和 Use Counts 那里的 Process Private 一致）
- 真·由这个进程自己申请并占用，别人用不着
Shareable / Shared （具体名字可能略有不同）
- 可以被多个进程共享的页（如 DLL、共享内存）
- 某个 DLL 被 10 个进程用，只在物理内存里算一份，但在这里会分摊统计
Standby / Modified / ...
- 和 Use Counts 里列意义类似，只是这回按"进程切片"展示
- 比如：某进程映射的文件页中，有多少还在 Standby 状态

心里要有个"映射"：

Use Counts 是按"用途"看总量，

Processes 是按"进程"看这些用途被谁拿走了。

2.3 怎么用它快速锁定"嫌疑人"？

场景 1：机器疯狂卡 + 内存占用高

小流程：

任务管理器看到"内存 95%+"
打开 RAMMap → Processes
点击 Total 或 Private 列排序（降序）
问两个问题：
- 是不是某个进程离群值，远高于其他进程？
- 这个进程的 Private 是否占比极高？

如果：

某进程 Total / Private 都巨大
⇒ 很可能是这个进程自己内存泄漏或有意吃大内存（DB、缓存等）
所有进程都还挺正常
⇒ 回到 Use Counts，看是不是 Mapped File / Standby 撑大了文件缓存

场景 2：Chrome / 浏览器占内存到底冤不冤？

你可以这样玩：

RAMMap → Processes 截图 A
打开一堆网页 / Web 应用
再开 RAMMap → Processes 截图 B
对比 chrome.exe 系列进程的：
- Total
- Private
- Shareable

会发现：

很多是 共享的代码/库，不完全是冤枉
真正导致压力的，是某些前端页面疯狂占内存（Private 增长明显）

三、Priority 视图：内存也有"贵宾座"和"站票"

3.1 什么是内存优先级（Memory Priority）？

从 Vista/Win7 开始，Windows 引入了 内存优先级 的概念。

同样是缓存页：

高优先级的页：尽量先保留
低优先级的页：内存紧张时优先被回收

这主要体现在 Standby 列表 上 ------ 就是 15.1 那个被频繁误会的"高占用缓存"。

Priority 视图，就是把这些页按优先级"排座位表"。

3.2 Priority 视图长什么样？

切到 Priority 标签，大致是：

text 复制代码

Priority   Total   Active   Standby   Modified   ...
---------------------------------------------------
0          100     10       90        0
1          256     20       230       6
2          512     50       450       12
3          1024    100      900       24
4          2048    300      1700      48
5          512     400      100       12

（数字仅示意）

含义：

Priority 0--5 或 0--7：数值越大，优先级越高
某个优先级下的 Active / Standby / Modified 等页数统计

非常口语的理解：

内存不够用的时候，系统会按优先级"从低到高"开始赶走乘客。

3.3 优先级在实际排查中有什么价值？

几个典型用途：

确认缓存是不是"可以安心丢"的
- 如果大多数 Standby 页都处于 低优先级，说明系统知道这些页"可随时回收"
- 有时候看起来内存很满，但大部分只是低优先级缓存，并不危险
理解前台/后台应用的"待遇差异"
- 前台正在用的应用，其页通常优先级更高
- 后台进程、部分服务的缓存页可能被降级，内存紧张时会先丢他们的缓存
开发/调优场景 （偏高级）
- 某些 API（比如 SetProcessInformation / SetThreadInformation）可以调整内存优先级
- Priority 视图能帮助验证：你的调优有没有真的改变内存优先级分布

对于运维/桌面支持来说，你不需要记住所有数字对应关系，只要记得：

Priority 视图回答的问题是：

"当前被缓存的东西，系统有多舍不得丢？"

四、Summary 视图：汇总全局的"内存鸟瞰图"

4.1 这页是干嘛的？

Summary 视图，更偏向"总览"：

汇总各类用途、各状态的内存占用
类似于把 Use Counts + 一些全局统计压缩在一页

可用于：

快速确认整体分布 ：
私有内存 / 文件缓存 / 池 / 页面表 / 零页 / 空闲页的比例
做"前/后"对比截图
比如变更前 vs 压测后

4.2 怎么用 Summary + 其他视图配合？

一个很实用的组合是：

Summary
- 看整体结构是否健康：
  - Private / Mapped File / Standby / Pool 所占比例正常吗？
Use Counts
- 针对某类用途深入：
  - 比如确认 Mapped File 是否大头
Processes
- 再向下钻：
  - 把某类用途拆到进程维度，看"谁贡献的最多"

简单画个"调查路线图"：

text 复制代码

Summary（总览）
   ↓
Use Counts（哪类用途多）
   ↓
Processes（哪几个进程贡献）
   ↓
Priority（这些页有多"重要"）

你可以把它写进自己的"内存排查 SOP"，以后看到"内存 99%"就按这个路线走一遍。

五、实战脚本：一次完整的内存排查小演练

假设场景：
一台应用服务器被投诉"时不时很卡，内存基本打满"。

你可以按下面这个"标准动作"来：

抓现场
- 任务管理器截图：CPU + 内存 + 进程列表
- 打开 RAMMap，依次截：
  - Summary
  - Use Counts
  - Processes
  - Priority
快速判断是"谁的问题"
- Use Counts：
  - Process Private 是否是大头？
  - 还是 Mapped File / Standby 撑起来的？
- Processes：
  - 哪几个进程 Total / Private 高？
- Priority：
  - 很多 Standby 页是否都是低优先级缓存？
给出一个带点"内核味"的结论 （邮件/工单里可以这样写）

示例：
经过 RAMMap 分析，目前物理内存中：
- 约 60% 为应用进程私有内存（以 XXX.exe / YYY.exe 为主），
- 约 30% 为文件缓存（Mapped File + Standby），缓存优先级较低，可在压力增大时自动回收。
- 内核 Nonpaged Pool 处于正常范围，没有明显泄漏迹象。
综合判断，目前的内存高占用主要是业务进程本身需求，而非系统缓存异常。后续建议从：

1）业务配置优化（XXX 进程内缓存/连接池），

2）或适度提升物理内存规格两个方向评估。

看起来就会比"就是内存不够，多加条条吧"专业很多。

六、小结：15.1 + 15.2 拼出"谁在用内存"这半张拼图

Use Counts（15.1）
- 回答：内存被用来干啥（用途视角）
Processes（15.2 上半）
- 回答：谁在用这些内存（进程视角）
Priority（15.2 中）
- 回答：这些内存页的"地位高不高"
Summary（15.2 下）
- 回答：全局结构是否健康

等你把 RAMMap 的这几页玩熟，再配合后面的：

Physical Pages / Physical Ranges（物理地址段）
File Summary / File Details（文件维度）
快照保存/加载（时间维度）

就可以很从容地在"内存问题"讨论中，从玄学抱怨 升级成结构化分析了。

下一篇（15.3），我们就来聊 RAMMap 的 Physical Pages / Physical Ranges / File Summary / File Details，把"谁在用"继续精细拆到"在哪块物理内存、对应哪些具体文件"。