GCP Composer2 v2.4.3中DataprocSubmitJobOperator任务报SIGKILL故障求助

Negsignal.SIGKILL 提示任务进程被系统强制终止，核心原因大概率是Composer Worker节点内存不足。Composer 2.4.3对应Airflow 2.5.x系列版本，相比2.2.5对应的Airflow 2.3.x，新版本Airflow及配套依赖包的内存占用更高，小型集群的资源储备无法支撑任务执行。

解决方案 #

1. 升级Composer集群资源配置 #

• 提升Worker节点机器类型：将小型实例（如n1-standard-1）更换为内存更高的机型，比如n1-standard-2或内存优化型实例，直接增加单节点可用内存。
• 增加Worker节点数量：通过多节点分摊任务负载，避免单个节点内存耗尽。
• 调整Airflow组件内存参数：在Composer集群配置中，调高airflow-worker的memory_request和memory_limit值，给任务执行分配更多内存额度。

2. 优化任务执行逻辑 #

• 转移本地预处理操作：不要在DataprocSubmitJobOperator中执行大量数据加载或预处理工作，将这些操作迁移到Dataproc集群的作业中完成，减少Composer Worker的资源消耗。
• 拆分大任务：如果任务涉及批量操作，拆分为多个子任务分片执行，分散单任务的内存压力。

3. 对齐依赖包版本 #

Composer 2.4.3与2.2.5的依赖包版本存在差异，可能存在资源占用过高的问题：

• 在Composer的PyPI依赖配置中，指定google-cloud-dataproc等核心依赖包使用2.2.5集群中的稳定版本，回退测试是否解决内存问题。
• 尝试升级到最新的稳定版依赖包，新版本可能修复了内存泄漏或资源占用优化的BUG。

4. 强化监控定位问题 #

• 开启Composer节点内存监控：在GCP控制台查看Worker节点的实时内存使用率，确认是否是内存耗尽触发SIGKILL。
• 调高任务日志级别：将Airflow任务日志级别设为DEBUG，获取更详细的执行过程信息，定位内存占用过高的具体环节。

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