一、问题现象与运行环境

在大型 3D 项目的开发过程中，“打开关卡”与“关卡迁移”是最容易触发崩溃的两类高频操作。典型表现是编辑器直接闪退，并在日志中留下两类致命错误。

错误一：CPU 侧内存分配失败

致命错误：[引擎通用平台内存模块]
Ran out of memory allocate 8294352 (7.9 MiB) bytes with alignment 4
最后一个错误消息：页面文件太小，无法完成操作。

错误二：GPU 侧渲染资源分配失败

致命错误：[图形接口层]
尝试分配渲染资源时，显存不足。

排障环境为高端桌面平台：64GB 物理内存、24GB 显存的独立显卡（另含一块集成显卡）、高速 NVMe 固态硬盘。按理说这套配置处理绝大多数场景绰绰有余，但崩溃仍反复出现，且一度困扰了近半个月。

值得注意的是错误一的一个细节：失败时尝试分配的仅有约 7.9 MiB。这并不是某次超大分配导致的失败，而是整个系统的提交上限已被榨干后，连小额分配都无法满足——这是典型的容量耗尽特征，也是后面分析的关键线索。

二、为什么“看起来没占满”却报内存不足

排障初期最大的困惑是：任务管理器里内存、显存占用都不高，报错却说不出来。要理解这个矛盾，需要分三层看。

1. 物理内存 ≠ 提交内存

现代操作系统采用“虚拟内存 + 页面文件”的提交机制。进程申请内存时，系统承诺的总量由物理内存和页面文件共同兜底；而任务管理器默认展示的“内存占用百分比”主要反映物理内存压力，页面文件的余量并不直观。当所有进程的提交总量逼近“物理内存 + 页面文件”的上限时，任何一次新的分配都会失败——哪怕物理内存条还有富余。报错信息“页面文件太小，无法完成操作”正是这个含义，它已经把方向指得很清楚了。

2. 大型关卡的内存使用呈“陡峭峰值”特征

• 关卡中常存在大量单体很大的资产文件（超大纹理、高精度网格、烘焙光照数据等），打开时需要一次性反序列化，瞬间产生数 GB 级别的提交请求；
• “迁移”比“打开”更重：迁移过程中源关卡资源与目标位置资源往往同时驻留，内存压力近似翻倍；
• 峰值是瞬时的，任务管理器的刷新间隔通常在秒级，很容易错过尖峰，让人误以为“资源根本没吃满”，从而在错误的方向上反复排查。

3. 显存报错可能与系统内存同源

在“独立显卡 + 集成显卡”的混合体系下，显存与系统内存通过驱动层统一调度：当系统内存与页面文件紧张时，驱动可能尝试把部分资源回溢到系统内存，反而进一步加剧提交压力，最终在显存分配环节报错。因此两类报错未必是两个独立问题——优先把页面文件扩到位后，显存不足的报错往往随之缓解。这一推断与后面的实测结果相互印证。

三、解决步骤：先扩页面文件，再治显存

1. 扩容页面文件（核心手段）

操作路径：进入操作系统的“高级系统设置 → 性能选项 → 高级 → 虚拟内存”，取消自动管理，在系统盘上设置自定义大小。

我们做了逐级实验，结果如下：

页面文件配置	实测结果
4–8 GB	打开阶段即崩溃
8–16 GB	崩溃点后移，仍失败
16–32 GB	打开可用，迁移大关卡仍失败
32–64 GB	打开与迁移均稳定

最终将 32–64 GB 确定为当前项目规模下的稳定最小值；极端验证时也曾一次性拉到 32–128 GB，问题彻底消失。需要强调的是，这组数值是相对本项目关卡体量得出的经验值——如果关卡更巨大，所需页面文件还会继续上涨，可按“单次加载资产总量 × 2（迁移场景 × 3）”估算下限。此外，页面文件应放在高速 SSD 上，以降低真正发生换页时的性能惩罚。

2. 显存不足的配套处理

在扩容页面文件之外，针对显存报错还有一组常规手段：

• 关闭浏览器硬件加速、视频播放等高显存占用的后台程序，为编辑器让出峰值空间；
• 混合显卡环境下，确认渲染实际运行在独立显卡上，避免被调度到仅有共享内存的集成显卡；
• 适当调低编辑器视口的分辨率百分比与后处理质量，限制纹理流送池大小；
• 保持显卡驱动为较新版本，旧版本驱动在显存管理与资源调度上存在已知缺陷；
• 资产侧做减法：制定纹理压缩格式与分辨率预算、清理无引用资源、对超高面数网格做减面或实例化。

3. 工程侧的治本方案

页面文件只是“兜底”，长期来看应在工程层面控制关卡的内存占用规模：

• 将巨型关卡拆分为多个子关卡并配置流送策略，按需加载，避免一次性载入全部资源；
• 为团队制定资产预算（单资产体积、纹理上限、面数上限），在制作阶段就拦截问题资产；
• 对确需超大单文件的资产，评估拆分或合并的必要性，避免“很多很大的单体文件”不断堆积——虚幻类引擎场景一旦出现这种资产结构，对虚拟内存的需求会呈非线性增长。

四、排查方法论：相信报错与日志，不要相信直觉

回顾整个排障过程，真正拖慢进度的不是技术难度，而是判断方式。总结出四条经验：

1. 读懂报错三要素：出错的模块、行号、分配大小。“页面文件太小”这条系统级错误消息已经明确指出了方向，早期却因为“任务管理器看着没满”而被主观怀疑，绕了远路。
2. 观测“提交内存”而非物理占用：性能监视器中的提交字节与提交上限，才是判断页面文件是否够用的正确指标；物理内存占用率在这里具有误导性。
3. 二分复现定位问题资产：逐个启用子关卡加载，把“整个关卡崩溃”收敛为“某几个资产导致崩溃”，既能验证内存估算，也能为后续资产治理提供清单。
4. 破除“虚拟内存开太大有点害怕”的心理误区：页面文件本质是磁盘上的兜底空间，系统按需使用，不会因为上限设得大就主动吃满磁盘或拖慢性能；上限不足才会直接导致崩溃。与其 4–8 GB、8–16 GB 反复小步试探，不如按估算一次给足，再逐步收敛到稳定最小值。

五、总结

大型关卡打开或迁移崩溃，本质是“瞬时提交请求超出物理内存 + 页面文件上限”的容量问题，显存报错也常与系统内存压力同源。实操上记住三句话：第一，报错信息里的“页面文件太小”是准确的技术结论，照着修；第二，页面文件按关卡体量给足，本项目实测 32–64 GB 为稳定下限，更大的关卡按比例放大；第三，建立“相信报错与日志、用数据复现验证”的排障习惯，而不是凭直觉反复试错。虚拟内存不够，就诚实地加够——相信科学。