【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除
13、【MOD开发】【骑砍2】运行内存：把经验扩展到其他应用
背景
上篇 【MOD开发】【骑砍2】运行内存：游戏里的 pagefile 与虚拟内存 把游戏侧的机制讲清楚了：游戏访问虚拟地址，页表负责翻译，页错误把页从页面文件搬回 RAM（Random Access Memory，随机存取存储器）；页面文件增加的是提交上限，不是物理内存；冷页换出可以腾出 RAM，热页密集切页会带来卡顿和加载变慢；战场加载是峰值场景，纹理、植被、Agent（游戏中的行动单位）、阵型和 MOD（Modification，模组）会在短时间内集中提交。
这些机制不只属于骑砍2。浏览器、IDE、虚拟机、剪辑软件、模拟器和大型 Office 文件都可能遇到同一类提交压力。本篇把骑砍2的案例抽象成通用判断：哪些程序适合用页面文件兜底，扩容会带来什么收益，又会付出什么代价。
骑砍2
🧩 哪些应用会受益
| 应用 | 典型压力 | 页面文件的作用 | 注意点 |
|---|---|---|---|
| 浏览器 | 多标签、多个渲染进程、缓存 | 承载冷标签和缓存，避免提交耗尽 | 标签泄漏仍需关闭或升级浏览器 |
| IDE（Integrated Development Environment，集成开发环境）与编译器 | 索引、构建、语言服务 | 吸收构建峰值和冷缓存 | 构建结束后工作集回落，提交未必立刻下降 |
| 虚拟机 / WSL2（Windows Subsystem for Linux 2，Windows 的 Linux 子系统）/ Docker | 客户机内存、镜像、容器 | 给宿主提交留余量 | 过度分配客户机内存会拖垮宿主 |
| 视频剪辑 / 3D（Three-Dimensional，三维）渲染 | 高分辨率素材、缓存、预览 | 避免素材加载阶段 OOM（Out of Memory，内存耗尽） | 热素材仍要驻留 RAM，切页会拖慢预览 |
| 游戏模拟器 | 纹理、着色器、ROM（Read-Only Memory，只读存储器）缓存 | 和游戏类似，给场景切换兜底 | 模拟器自身的缓存策略也会影响峰值 |
| 大型 Office 文件 | 多文档、撤销历史、嵌入对象 | 吸收打开和编辑峰值 | 文件损坏或插件泄漏仍需单独处理 |
| 科学计算 | 大数组、中间结果 | 让超过 RAM 的数据集有机会运行 | 工作集长期超过 RAM 时性能会明显下降 |
| 数据库 / 实时服务 | 缓冲池、连接、查询 | 不是首选手段 | 通常应先调缓冲池、连接数和查询，再评估页面文件 |
页面文件最适合"有明显峰值、冷热分层清楚、允许短时延迟"的负载。对延迟极敏感的实时服务，或者工作集长期大于 RAM 的负载，优先加内存或降低并发，而不是继续扩大页面文件。
🧩 三个具体例子
浏览器开 30 个标签时，冷标签和缓存可以被换出，页面文件能避免提交耗尽；但如果某个渲染进程持续泄漏，扩容只能延后崩溃时间，仍需关闭标签或升级浏览器。
IDE 建立索引和编译时会出现短时峰值，页面文件可以吸收这部分提交；索引完成后工作集回落，提交量未必立刻下降，判断是否够用要看峰值余量。
虚拟机同时运行多个客户机时，宿主提交量会叠加；页面文件可以提供余量，但客户机内存总和长期超过宿主 RAM 时，切页会把整机拖慢，优先调整客户机内存分配。
📊 收益与限制
| 维度 | 结果 | 用途 |
|---|---|---|
| 稳定性 | 提交上限提高，分配失败减少 | 避免 OOM 和进程直接退出 |
| 并发能力 | 可以同时保留更多冷页 | 多开程序、多标签、多任务更从容 |
| 峰值承载 | 吸收构建、加载、渲染的短时峰值 | 峰值过后系统可以回收 |
| 磁盘空间 | 页面文件占用磁盘，D 盘 32GB 会直接减少可用空间 | 需要预留 10--15% 空闲 |
| SSD（Solid State Drive，固态硬盘）写入 | 切页会增加写入量 | 现代 SSD 有寿命余量，但长期高频切页不是好状态 |
| 延迟 | 热页被换出后重新读入需要 I/O | 机械硬盘上会表现为明显卡顿 |
| 安全 | 页面文件可能包含内存中的敏感数据 | 有敏感数据时依赖磁盘加密和访问控制 |
| 备份 | 页面文件通常不需要备份 | 备份工具一般会跳过系统文件 |
| 内核转储 | 系统盘页面文件影响内核转储 | 移动或关闭系统盘页面文件前要确认转储需求 |
磁盘空间是最容易被忽略的代价。本次把 C 盘页面文件设为 8GB、D 盘设为 32GB，合计 40GB；D 盘可用空间会相应减少。页面文件是隐藏的系统文件，资源管理器默认不显示，但磁盘容量的确被占用了。磁盘写满后，页面文件无法扩展，新的提交请求仍可能失败。
页面文件可能包含内存中的敏感数据；有合规要求时依赖 BitLocker 等磁盘加密，并评估关机清理策略。页面文件通常不需要备份，备份工具会跳过系统文件；真正需要保护的是业务数据和配置。
🧮 怎么定大小
页面文件大小不应该套一个固定倍数，而应该看提交峰值。可以先在目标程序运行时采样：
powershell
(Get-Counter '\Memory\Commit Limit').CounterSamples.CookedValue / 1GB
(Get-Counter '\Memory\Committed Bytes').CounterSamples.CookedValue / 1GB
(Get-Counter '\Memory\Available MBytes').CounterSamples.CookedValueCommit Limit 是上限，Committed Bytes 是当前已提交量，两者相减是余量。建议在峰值场景下保留至少 4GB 余量；如果余量长期低于 1GB，下一次大分配就可能失败。
一个实用的参考区间如下，具体仍以峰值和磁盘空间为准：
| 物理内存 | 页面文件参考值 | 说明 |
|---|---|---|
| 8GB | 8--16GB | 低内存机器需要更多后备，但性能仍受 RAM 限制 |
| 16GB | 16--32GB | 本次案例取 8GB + 32GB，重点是抬高提交上限 |
| 32GB | 16--32GB 或系统管理 | 常规办公和开发通常够用 |
| 64GB 及以上 | 系统管理或较小固定值 | 优先看峰值和转储需求，不必盲目放大 |
系统管理的页面文件在多数桌面场景下够用；只有当提交峰值持续接近上限，或者需要固定大小避免系统频繁调整时，才值得手动配置。手动配置的代价是要自己负责磁盘空间、重启验证和回滚。
图 1 加内存与加页面文件的取舍
🧪 监控与验收
在目标程序运行时采样 Commit Limit、Committed Bytes 和 Available MBytes，并记录峰值场景的余量。验收标准可以写成三条：峰值余量不低于 4GB；Event 2004 不再出现；磁盘剩余空间保持在 10--15%。
Get-Process | Sort-Object PagedMemorySize64 可以找出提交量最大的进程；Get-WinEvent 过滤 2004 可以确认系统是否再次触发低内存诊断。两者结合，比只看任务管理器更可靠。
⚠️ 常见坑
- 把页面文件放在机械硬盘上，密集切页会把卡顿放大。
- 磁盘剩余空间不足，页面文件无法扩展到目标大小。
- 移动或关闭系统盘页面文件，可能导致内核转储无法生成；需要转储时保留系统盘页面文件或配置专用转储文件。
AutomaticManagedPagefile=True时Win32_PageFileSetting可能为空，不能据此判断"没有页面文件"。- 只看配置对象，不看
Win32_PageFileUsage.AllocatedBaseSize，会误以为配置已经生效。 - 回滚后残留
D:\pagefile.sys，需要在重启后确认并手动清理。 - 页面文件可能包含敏感内存数据；有合规要求时依赖 BitLocker 等磁盘加密，必要时评估关机清理策略。
- 把页面文件当成性能加速器；它主要换稳定性，热页切回仍然要付出 I/O 成本。
- 在系统运行时删除
pagefile.sys，文件被占用，删除会失败或导致异常。
本次的三个脚本可以复用到其他机器：apply 改目标盘符和大小，check 在重启后验证配置、实际分配和提交余量，restore 恢复自动管理。复用时要先确认磁盘空间、内核转储需求和目标程序的峰值，不要直接照搬 8GB + 32GB。
📌 小结
- 页面文件适合有明显峰值、冷热分层清楚的负载，不是所有程序的通用加速手段。
- 扩容提高的是提交上限，代价是磁盘空间、SSD 写入和切页延迟。
- 用
Commit Limit、Committed Bytes和峰值场景的余量定大小，不套固定倍数。 - 系统管理通常够用；手动配置要有验证和回滚路径。
- 磁盘写满、机械硬盘、内核转储和敏感数据是四个需要提前确认的边界。
- 页面文件是稳定性保险，不是性能加速器；长期高负载优先加内存。
到这里，从 OOM 现场、术语、三个脚本、脚本语法到游戏机制和通用扩展，这条运行内存的排查与修复路径就完整了。
OK，本篇先到这里，如有疑问，欢迎评论区留言讨论，祝各位功力大涨，技术更上一层楼！！！更多内容见下篇 blog