问题单号
|
DTS2024060329127
|
严重级别
|
一般
|
问题描述
|
Spark OmniOperator算子加速执行Insert语句且只有1个数据分区的场景,当出现50个表连续Sort Merge Join时,算子加速SMJ算子在堆外内存耗尽时调用new申请vector内存导致coredump问题。
|
根因分析
|
- 由于OmniOperator算子加速当前是列式处理,相比于原生Spark的行式处理,内存占用会更大,而且SMJ算子计算过程中申请的资源需要在task结束后才能释放。
- 出现问题的场景是Insert语句且只有1个数据分区,Spark只会生成1个task去执行任务。因此,会导致50个表的Sort Merge Join都在1个task内执行。此时用例配置的38g堆外内存在连续50个SMJ算子计算过程中已经耗尽,此时再通过new申请内存时,出现coredump。
|
影响评估
|
该用例属于比较极限的场景,Spark作业本身是为了利用大规模集群的并发优势,正常情况下不会存在单个task(单线程)执行大量表join的业务场景。当前暂未在真实业务场景下遇到该问题,对客户影响很小。
|
规避和应急措施
|
- 调整spark.memory.offHeap.size参数增大堆外内存后重新触发业务。
- 回退到原生Spark流程触发业务。
|
解决计划
|
- 已在特性指南上增加故障案例说明,当用户出现该问题时能够迅速完成定位和规避。
- 此问题单遗留,在下一个商用版本Kunpeng BoostKit 24.0.0 中解决。
|