spark社区bug

1.SPARK-26114（已合）
repartitionAndSortWithinPartitions 后合并时 PartitionedPairBuffer 的内存泄漏    

原因

这个Spark源码的issue描述了在使用coalesce操作合并分区时可能会导致PartitionedPairBuffer内存泄漏的问题。具体来说，当在使用repartitionAndSortWithinPartitions操作进行shuffle操作后，再使用coalesce操作进行分区合并时，如果某些分区需要被合并的话，需要通过PartitionedPairBuffer存储更多的元素。如果合并分区的规模过大，会导致单个executor的内存使用率超过限制，导致OOM错误或executor被杀死的情况发生。

而这个issue中提到的问题是由CompletionIterator和ExternalSorter导致的内存泄漏。CompletionIterator是一个迭代器，用于在Spark任务完成时清理资源。而ExternalSorter是一个用于排序的工具类，用于对数据进行排序和合并操作。

在这个issue中，由于CompletionIterator没有正确地清理ExternalSorter中的资源，导致ExternalSorter内存泄漏。具体来说，当使用repartitionAndSortWithinPartitions操作时，会创建多个ExternalSorter对象，这些对象在排序和合并操作完成后，需要被释放。但是由于CompletionIterator没有正确地清理这些对象，导致这些对象一直占用着内存，从而导致内存泄漏问题。

为了解决这个问题，需要在CompletionIterator中添加对ExternalSorter对象的清理操作，以确保这些对象在任务完成后能够被正确地释放。通过这个操作，可以避免由于CompletionIterator和ExternalSorter导致的内存泄漏问题，提高Spark任务的稳定性和可靠性。

 

 

2.[SPARK-26152]（已合）

Handle RejectedExecutionException due to Worker Cleanup on Worker Shutdown，

 

3.[SPARK-26269][YARN]Yarnallocator should have same blacklist behaviour with yarn to maxmize use of cluster 

这个Spark源码的issue描述了YarnAllocator在黑名单策略上存在的问题。YarnAllocator是一个用于在YARN集群上分配资源的工具类，它在Spark中被广泛使用。在当前的实现中，YarnAllocator会将一些已经完成的容器的节点加入到黑名单中，但是只有当容器的退出状态是SUCCESS、PREEMPTED、KILLED_EXCEEDED_VMEM或KILLED_EXCEEDED_PMEM时才会这样做。而对于其他退出状态，例如KILLED_BY_RESOURCEMANAGER，YARN不会将相关节点添加到黑名单中。

这种黑名单策略的限制可能会导致集群资源的浪费。如果一个节点上的容器被ResourceManager杀死，但是该节点上的其他容器仍然可以使用，那么yarn 将该节点添加到黑名单中可能会导致该节点上的其他容器无法被分配。因此，将黑名单规则，并与YARN具有相同的黑名单行为，可以最大限度地利用集群资源。

4.[SPARK-26615][Core] Fixing transport server/client resource leaks in the core unittests，TransportClient/TransportServer   已合入

 

5.[SPARK-26713][CORE] Interrupt pipe IO threads in PipedRDD when task is finished，PipedRDD创建两个线程stdin writer和stdout reader，在任务异常失败可能会导致内存泄漏

这个 Spark 的 issue 解决了以下问题：

在 PipedRDD 中，为了执行 RDD 操作，会创建两个线程：stdin writer 和 stdout reader，其中 stdin writer 把数据从上一个 RDD 的分区写到另一个进程的标准输入，而 stdout reader 从进程的标准输出中读取数据并转换为 RDD 分区返回。然而，在某些情况下，PipedRDD 中的 stdin writer 和 stdout reader 不能正常终止，这会导致资源浪费和潜在的内存泄漏。此 issue 的解决方案是在任务完成后中断这些线程，确保它们在不再需要时能够正确关闭，从而解决了这个问题。

6.[SPARK-26751][SQL] Fix memory leak when statement run in background and throw exception which is not HiveSQLException，后台运行任务如果报错未抛出HIVESQLException，将会导致opHandle未正常关闭导致内存泄漏

 

这个 Spark 的 issue 是 Spark SQL 的一个 bug，当在后台运行的 Spark SQL 查询执行过程中抛出异常时，并且这个异常不是 HiveSQLException，那么查询过程中的资源可能没有被正确释放，从而导致内存泄漏问题。

具体而言，Spark SQL 支持在后台运行查询任务，即用户可以提交查询并在后台运行该查询，同时进行其他任务。当用户在运行查询的过程中，查询任务出现异常但不是 HiveSQLException 异常时，查询任务的 operationHandle 可能没有被正确关闭，以至于该查询任务占用的资源一直没有被释放，从而导致内存泄漏。

该 issue 的解决方案是在捕获异常时，当异常不是 HiveSQLException 时，显式调用 OperationHandle.close() 方法，释放查询任务占用的资源，避免内存泄漏问题的出现。

7.[SPARK-27021][CORE] Cleanup of Netty event loop group for shuffle chunk fetch requests，额外的Netty event loop group没有关闭导致泄漏，

 

这个 Spark 的 issue 描述了在使用 Netty 来进行 Shuffle 块（chunk）获取请求时可能会出现的内存泄漏问题。

具体来说，在 Spark 的 Shuffle 过程中，如果多个 Shuffle 服务（即多个 Spark 应用程序）运行在同一个节点上，那么每个 Spark 应用程序都可以创建自己的 Netty EventLoopGroup 对象，用于执行 Shuffle 块的获取请求。然而，由于 Netty 的实现方式，如果未正确关闭 EventLoopGroup，那么将会出现内存泄漏问题。

本 issue 的根本原因是每个 Spark 应用程序都会创建自己的 EventLoopGroup 对象，但只有一个 EventLoopGroup 对象被显式地关闭了。这导致在后面的 Shuffle 块获取请求中，引用的是其它未关闭的 EventLoopGroup 对象，从而导致资源泄漏而产生内存泄漏问题。

为了解决这个问题，本 issue 中的解决方案是在每个 Spark 应用程序使用的 Netty EventLoopGroup 对象使用后手动关闭，避免不必要的资源泄漏。同时，解决方案也要确保关闭 EventLoopGroup 的操作线程安全。

 

8.[SPARK-27041][PySpark] Use imap() for python 2.x to resolve oom issue，在Python2.7中大分区数据会导致oom

这个 Spark 的 issue 描述了在使用 PySpark 分布式处理大数据集时可能会发生 Out Of Memory（OOM）问题。

具体来说，在 Python 2.7 中 PySpark 使用 `map` 函数时，会将整个 RDD 数据分成多个小分区，在各个 Executor 节点上并行计算。然而，当使用 `map` 函数处理的数据集非常大时，会导致每个小分区需要缓存在内存中，从而可能出现 OOM 问题。

为了解决这个问题，Spark 社区在本 issue 中引入了 `imap` 函数。与 `map` 函数不同，`imap` 函数使用 lazy evaluation 来处理数据集，并将工作分解为多个并发任务，以减少缓存的数据量。这意味着在处理大数据集时，`imap` 函数只会在需要时才计算和缓存数据，而不像 `map` 函数在处理大数据集时会立即计算并缓存所有的数据。因此，使用 `imap` 函数可以减轻缓存数据的压力，从而避免 OOM 问题的发生。

需要注意的是，`imap` 函数只适用于 Python 2.7 版本。对于 Python 3.x 版本的 PySpark，不必使用 `imap` 函数，因为 Python 3.x 版本的 `map` 函数已经实现了 lazy evaluation。