使用Dask map_partitions并行化pandas.apply时全量数据集进程被杀死如何解决？

SIGKILL信号在MacOS下明确为内存溢出（OOM）后被系统强制杀死进程，结合你的场景核心诱因是多进程调度下大对象inData的重复复制开销：你使用的processes调度器为多进程模式，Python多进程默认没有共享内存机制，每启动1个工作进程就会完整复制1份700MB的inData对象，加上Dask分区数据、计算中间结果的开销，总内存占用会远超单进程原生pandas的运行开销，最终触发系统内存上限。
你已经排除了分区数量的影响，可按以下方案解决：

1. 优先优化调度器避免大对象重复复制 #

如果你的my_fun没有GIL锁限制（比如大部分逻辑调用C扩展、numpy/pandas底层操作），直接替换为多线程调度器即可，多线程模式下所有线程共享同一份inData，完全消除重复复制开销，修改代码如下：

# 仅修改scheduler参数即可
applied = ddf.map_partitions(lambda dframe: dframe.apply(lambda x: my_fun(inData, x), axis=1)).compute(scheduler='threads')

如果必须使用多进程调度，可通过multiprocessing.Manager封装inData为全局只读共享对象，或者提前将inData序列化为内存映射文件，每个工作进程只读加载避免多份副本开销。

2. 优化计算逻辑减少冗余开销 #

• 避免在map_partitions内嵌套两层lambda，将分区计算逻辑封装为独立函数，减少Python闭包带来的额外内存引用，同时明确指定meta参数避免Dask自动推导类型时额外触发样本分区计算：

def partition_worker(dframe, in_data):
    return dframe.apply(lambda x: my_fun(in_data, x), axis=1)

# meta根据你的my_fun返回值类型调整，示例为返回object类型的单列结果
applied = ddf.map_partitions(partition_worker, inData, meta=('result', object)).compute(scheduler='threads')

• 如果my_fun内存在临时对象未释放的问题，可在apply的每次调用结束后手动删除无用变量、触发gc回收。

3. 资源兜底配置 #

如果调整后仍有内存压力，可开启Dask内存溢出 spilling 配置，将超出内存的中间结果暂存到本地磁盘，避免进程被直接杀死：

import dask
dask.config.set({'distributed.worker.memory.spill': True, 'distributed.worker.memory.target': 0.6})

内容的提问来源于stack exchange，提问作者Intelligent-Infrastructure