---
title: 遗留问题
description: "| 问题单号 | DTS2024060329127 |"
url: https://www.hikunpeng.com/document/detail/zh/kunpengboostkithistory/240RC2/bds/kunpengbds_omniruntime_28_0043.html
sourcePath: /source/zh/kunpengboostkithistory/240RC2/bds/kunpengbds_omniruntime_28_0043.html
indexId: 9ea6aba8c926c98a4ac89c3e02f3561cf05f983a8c6664c1eced9ef43800216980
---
# 遗留问题

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