UE5.4 多进程 Cook
UE5.4 多进程 Cook
大型项目单进程 Cook 动辄几个小时,UE5.4 的多进程 Cook 把这件事拆成多个子进程并行做,用内存换并行度,资产量大的项目能省下可观的时间。
工作原理
多进程 Cook 把 Cook 工作拆成两类进程:
- Director 进程:负责把资产切分成若干组,分配给 worker,再把各 worker 的产物收集、合并起来。
- Worker 子进程:每个 worker 负责 Cook 分配给它的一组资产。
设 CookProcessCount = N:N ≤ 1 是单进程;N > 1 时是 1 个 Director + (N-1) 个 cook worker。
收益与限制
本质上这是拿内存换并行度——多进程 Cook 一定比单进程吃更多 RAM,要让它真正提速,机器得有足够内存。
收益:资产量大的项目省时间最明显。Epic 内部测过用 4 个子进程 Cook 一个大项目,相比单进程快了约 40%。
限制:所有 worker 目前只能跑在 Director 所在的同一台机器上,共享同一台机器的资源,这就给可用进程数划了上限。两个瓶颈:
- 内存:RAM 用尽后,Director 和 worker 会更频繁地触发 GC,GC 的开销反过来比多开 worker 带来的收益还大。
- 核心数:可用核心用完后,每个 worker 退化成单线程跑;那些本该在 worker 线程上跑的长耗时异步任务会卡住主线程,拖慢速度。
小项目不要用——只 Cook 一把资产时,多 worker 的进程/内存开销盖过了并行收益,反而更慢。
两种启用方式
最优的 CookProcessCount 因项目和机器资源而异,建议拿几个不同的值实测对比。注意 CookProcessCount 不要超过机器核心数,否则反而拖慢速度。
方式一:启动参数
通过 AutomationTool 把参数传给 cooker 进程:
-AdditionalCookerOptions="-cookprocesscount=N"
在 Project Launcher 的打包配置里,把这个参数加到额外的 cooker 选项中即可。
方式二:配置文件
在项目的 *Editor.ini 里给 [CookSettings] 加一项 CookProcessCount,设成大于 1 的整数:
[CookSettings]
CookProcessCount=4
实测结论
- 数据量小的项目不需要多进程 Cook。
- worker 数量由核数和内存共同决定,具体项目要实测找最佳值。
- worker 开多了内存会爆,Cook 直接失败报 Cook Failed for out of memory。可以试着加大虚拟内存(放在 SSD 上)来救。
- 6 核机器如果 RAM 很足,开两个 worker 速度也能快近一半。
- worker 数往上递增,基本是在上一档基础上再快一点点,很快会撞到瓶颈。
- Cooker 分配时会直接占用虚拟内存。
关于虚拟内存和物理内存的关系,Cook 时遇到 OOM 容易混淆,简单理一下:物理内存(RAM)是机器实际装的内存条,CPU 直接访问,速度快、容量有限;虚拟内存是操作系统拿硬盘上的分页/交换文件模拟出来的"内存",容量大但慢(走硬盘读写)。物理内存不足时,系统把暂时不活跃的数据换出到虚拟内存,腾出物理内存给当前活跃进程。所以 Cook 报 OOM 时加大分页文件(用 SSD)能缓解,但因为走硬盘,速度比真 RAM 慢很多,治标不治本——真要稳,还是加物理内存或减少 worker 数。
附录:实测数据
下表是不同机器配置 / 项目 / worker 数下的 Cook 耗时实测。结论一句话:CPU 核数和内存都充足时,**资产超过 10 万包的大型项目(项目A)**多进程能提升约 35%;而 Lyra、AncientGame 这种小项目反而会慢 50% 左右。表中 项目A、项目B 是内部项目,只按规格描述;Lyra 和 AncientGame 是 Epic 的公开示例工程。
| 机器配置 | 项目 | 引擎 | worker | 耗时 | 备注 |
|---|---|---|---|---|---|
| CPU 6 / RAM 128G | Lyra | UE5.4 | 单进程 | 22min | |
| CPU 6 / RAM 128G | Lyra | UE5.4 | 2 | 21min | 几乎没差 |
| CPU 6 / RAM 128G | AncientGame | UE5.4 | 单进程 | 3.1h | |
| CPU 6 / RAM 128G | AncientGame | UE5.4 | 2 | 4.5h | 明显变慢 |
| CPU 6 / RAM 128G | AncientGame | UE5.4 | 4 | 5.5h | 更慢 |
| CPU 10 / RAM 64G | 项目A(10W+ 资产) | UE5.3 | 单进程 | 57min | |
| CPU 10 / RAM 64G | 项目A | UE5.3 | 2 | 55min | |
| CPU 10 / RAM 64G | 项目A | UE5.3 | 4 | 40min | 内存占用 70% |
| CPU 10 / RAM 64G | 项目A | UE5.3 | 6 | 40min | 内存占用 95%,已到顶 |
| CPU 10 / RAM 256G | 项目B | UE5.4 | 单进程 | 7h | |
| CPU 10 / RAM 256G | 项目B | UE5.4 | 2 | 3h | |
| CPU 10 / RAM 256G | 项目B | UE5.4 | 3 | 2h42min | |
| CPU 10 / RAM 256G | 项目B | UE5.4 | 4 | 2h35min | |
| CPU 6 / RAM 256G | 项目B | UE5.4 | 单进程 | 9h | |
| CPU 6 / RAM 256G | 项目B | UE5.4 | 2 | 4h13min | |
| CPU 6 / RAM 256G | 项目B | UE5.4 | 3 | 3h22min | |
| CPU 6 / RAM 256G | 项目B | UE5.4 | 4 | 3h18min | |
| CPU 64 / RAM 128G | 项目B | UE5.4 | 单进程 | 6h20min | 内存 ≤98%,CPU 仅 3%~20% |
| CPU 64 / RAM 128G | 项目B | UE5.4 | 2 | 3h | |
| CPU 64 / RAM 128G | 项目B | UE5.4 | 3 | 2h24min | |
| CPU 64 / RAM 128G | 项目B | UE5.4 | 6 | 1h30min | 这一档最快 |
| CPU 64 / RAM 128G | 项目B | UE5.4 | 8 | 1h36min | 反而比 6 worker 慢 |
| CPU 64 / RAM 256G | 项目B | UE5.4 | 单进程 | 7h |
几个能看出来的规律:64 核机器在 6 worker 时到达最快(1h30min),加到 8 worker 反而回退,说明瓶颈已经不在 CPU;同一项目 CPU 10 核时,内存从 64G 到 256G 让可用 worker 数和提速幅度都更高;单进程时 CPU 利用率只有个位数到 20%,这正是多进程能吃下的空间。