Python multiprocessing创建大进程池导入大库报DLL加载失败等错误

报错核心提示The paging file is too small for this operation to complete，故障本质是Windows系统虚拟内存（分页文件）配额不足，和CPU品牌无直接关联。
Windows环境下Python的multiprocessing默认使用spawn进程启动模式：每个子进程启动时会完整加载主进程已导入的所有依赖，无法像Linux的fork模式那样复用父进程的内存页。导入numpy这类重型第三方库时，单个进程加载库及关联DLL就需要占用数百MB内存，32个进程同时启动的瞬间，系统提交的总内存（物理内存+分页文件预留额度）会触达上限，即便物理内存仍有剩余，分页文件预留不足也会抛出内存错误。
低配置Intel笔记本可正常运行，核心原因是该设备默认开启了系统自动管理分页文件，而32核AMD设备的分页文件被手动设置为较小值。PyCharm的Max Heap Size配置仅影响PyCharm程序本身的内存占用，和运行的Python子进程内存配额无关。

按落地优先级排序：

• 调整Windows分页文件配置：打开「此电脑→属性→高级系统设置→高级→性能设置→高级→虚拟内存」，取消自动管理所有驱动器的分页文件大小，为系统盘设置自定义分页文件：初始大小设为物理内存的1.5倍（即49152MB），最大值设为物理内存的2倍（即65536MB），保存设置后重启设备即可解决分页文件不足的报错。
• 延迟导入重型依赖：不要在全局作用域导入numpy这类大型库，将导入语句移到子进程执行的函数内部，仅在子进程实际执行业务逻辑时加载依赖，避免子进程启动阶段就重复加载重型库带来的内存尖峰，示例写法：

import multiprocessing

def f():
    # 子进程内部延迟导入，启动阶段不加载numpy
    import numpy as np
    # 业务逻辑代码
    pass

if __name__ == "__main__":
    pool = multiprocessing.Pool(32)
    for i in range(5):
        pool.apply_async(f)
    pool.close()
    pool.join()

• 合理设置进程池规模：numpy、pandas这类科学计算库底层默认开启多线程并行计算，会自动调用CPU核心做运算。如果开32个进程，每个进程内部又启动多个计算线程，总线程数会远超CPU核心数，反而会因为频繁的上下文切换降低运行效率。这类场景下进程池大小设置为8~16，实际运行效率往往高于32进程，也不会触发内存不足问题。
• 替换进程后端：如果不希望修改系统配置，可以使用joblib库替代原生multiprocessing，其内置的loky后端对子进程启动逻辑做了优化，可减少重复导入依赖带来的额外内存开销。

内容的提问来源于stack exchange，提问作者diego