如何分析Dask Worker被意外终止问题？附场景与环境信息

开发者阿泽

2026-6-27

问题描述

数据情况：30GB未压缩空间数据，以Parquet格式存储，包含id、tags、coordinates三列，行组大小设置为64MB。
处理流程：使用dask.read_parquet并指定block_size=32MiB，生成118个分区；所有处理阶段均调用DataFrame.persist，配合distributed.wait或progress等待处理完成，前序步骤无异常。
报错场景：执行自定义保存逻辑时触发Worker崩溃，代码如下：

dfs = features.to_delayed()
layer_path = os.path.join(self._path, layer)
filenames = [ os.path.join(layer_path, f"{layer}-{i}.parquet") for i, df in enumerate(dfs)]
writes = [delayed(save)(df, layer, fn) for df, fn in zip(dfs, filenames)]
dd.compute(*writes)

报错信息：

Exception: TerminatedWorkerError('A worker process managed by the executor was unexpectedly terminated. This could be caused by a segmentation fault while calling the function or by an excessive memory usage causing the Operating System to kill the worker.\n\nThe exit codes of the workers are {SIGKILL(-9)}')

保存前分区状态：

layer geometry properties
npartitions=118                            
                 object   object     object
                    ...      ...        ...
...                 ...      ...        ...
                    ...      ...        ...
                    ...      ...        ...
Dask Name: apply, 2 graph layers

补充配置：集群共10个Worker节点，每个Worker配备8核CPU、48GB可用内存；已尝试使用Worker插件但未获取有效日志，需要更有效的排查方案。

排查方法

优先排查内存超限问题
- 启用Worker内存监控：启动Worker时添加参数--memory-limit 40GB（预留8GB给系统进程），同时开启--nanny模式，让Nanny进程监控Worker内存使用，触发超限后自动重启并记录详细日志。
- 检查系统OOM日志：直接查看节点的/var/log/syslog或执行dmesg命令，搜索Out of memory或kill process关键字，确认是否是系统OOM Killer主动终止了Worker进程。
- 计算单分区内存占用：执行client.submit(lambda df: df.memory_usage(deep=True).sum(), features.get_partition(0)).result()，算出单个分区的实际内存消耗，评估10个Worker同时处理分区时的总内存压力（每个Worker最多处理12个左右分区，需确保总占用不超过Worker内存限制）。
排查自定义save函数的问题
- 简化保存逻辑：暂时替换save函数为最基础的Parquet保存代码，比如df.to_parquet(fn, engine='pyarrow')，排除自定义逻辑中的内存泄漏或Segfault触发点。
- 单分区测试：手动取出一个分区df = features.get_partition(0).compute()，调用save(df, layer, test_fn)执行保存，排查是否是特定分区的异常数据导致崩溃。
优化调度与资源配置
- 降低并行写任务数：尝试减少同时执行的写任务数量，比如先一次只写5个分区，看是否还会触发Worker崩溃，逐步定位并行度是否过高。
- 调整Worker线程数：8核Worker建议设置--nthreads 4，避免单进程线程过多导致内存竞争或资源耗尽。
- 开启Worker DEBUG日志：启动Worker时添加--log-level DEBUG --log-file /tmp/dask-worker.log，将日志输出到本地文件，Worker崩溃后查看日志最后几行的报错细节。
排查Parquet引擎与数据类型兼容性
- 切换Parquet引擎：尝试将保存时的引擎从默认值切换为pyarrow或fastparquet，排查是否是引擎与空间数据（比如geometry列）的兼容性问题引发Segfault。
- 检查异常数据：确认geometry列是否存在空值、格式错误的WKT/WKB等异常数据，这类数据在序列化时可能导致内存溢出或进程崩溃。

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