Linux下Python多进程实现高维矩阵计算时进程异常、耗时大幅波动问题

进程数不足的核心诱因 #

• 当前代码每轮迭代都会执行全量进程池的创建、销毁流程：Linux下Python多进程Pool默认采用fork模式启动进程，当实验室公共系统的内存、CPU配额被其他用户占用时，内核会直接拒绝新的进程创建请求，自然无法稳定拉起20个进程。
• 任务传参方式存在严重内存浪费：通过partial绑定全量data、W矩阵作为入参的方式，会让每个提交的任务都附带全量高维矩阵的序列化数据，当矩阵规模达到数GB级别时，序列化传输阶段会占用大量内存，触发系统OOM Killer提前回收还未完成启动的子进程，最终表现为进程数凑不满20个。
• 反复创建销毁进程的操作本身会产生大量系统开销：每轮迭代都新建20个进程、计算完成后立刻全量杀掉的模式，会让系统在短时间内出现进程上下文切换高峰，一旦遇到系统cgroup限流、单用户进程数上限限制，就会出现启动进程数不达标的情况。

耗时波动极大的核心原因 #

• Linux fork的copy-on-write内存机制特性：第一轮49.9s的低耗时，正是因为第一次创建进程池时，fork出来的子进程共享主进程的物理内存页，不需要立刻拷贝全量的data、W数据；但从第二轮开始，因为每轮都销毁重建进程池，新启动的子进程都需要重新完成全量矩阵的序列化拷贝，这个过程的耗时完全取决于当时系统的空闲内存状态——实验室为多用户共享环境，其他程序占用内存触发磁盘交换时，序列化拷贝的耗时会出现数十到上百倍的波动，直接导致单轮耗时从几十秒飙升到近900秒。
• 公共环境的资源抢占不可控：没有做进程绑定、资源预留的情况下，Linux的CPU调度器为全局抢占式逻辑，如果子进程被调度到和其他用户高负载任务同核运行，进程的实际计算时间会因为频繁的上下文切换被拉长，相同计算量的任务出现数倍的耗时差属于正常现象。
• 不必要的对象创建开销：每个子进程的循环里反复创建小型sparse.csc_matrix对象，频繁触发Python的垃圾回收逻辑，一旦遇到NUMA节点的内存访问延迟升高，这类小对象的GC开销会被进一步放大，加剧耗时波动。

• 全局复用进程池，避免反复创建销毁：把进程池的初始化逻辑放到类的初始化函数中，在迭代循环开始前就创建好固定20个进程的常驻进程池，整个训练迭代过程中不执行close、join操作，从机制上保证20个进程长期驻留，彻底解决进程数启动不足的问题。
• 优化传参逻辑，减少内存拷贝：利用Linux fork模式下子进程天然共享主进程内存的特性，不要通过任务入参传递全量data、W矩阵，将矩阵存储在类的成员变量中，任务函数只需要传入对应的批次数组索引即可，完全省掉全量矩阵反复序列化的巨大开销。
• 减少临时对象的创建：将循环内的稀疏矩阵构造逻辑提前，避免逐元素创建小型稀疏对象，统一用numpy数组完成中间计算，最后再转成需要的稀疏格式，降低垃圾回收带来的耗时抖动。
• 增加基础资源监控：在每轮计算前后打印当前系统的空闲内存、CPU占用率，如果发现资源被其他进程大量抢占，可以通过taskset绑定进程到空闲CPU核上，避免调度抢占带来的耗时波动。

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