Scala Spark Structured Streaming/Kafka中可能存在小内存泄漏

我们有一个基于Spark Structured Streaming 2.4.6的应用程序，读取卡夫卡主题，根据用户配置进行一些计算或聚合（高度灵活且可定制），并写入卡夫卡和Kairosdb。它在K8S上使用spark submit运行

现在，在我们的测试中，配置驱动大约140个流式查询，其中有3个执行器，每个执行器都有3G内存和3G内存开销，它每5分钟处理大约77KB的传入数据（小摄取率测试）。但遗嘱执行人将在8小时内被杀。以下是来自驱动程序的错误日志：

TaskSchedulerImpl:192.168.36.255上的执行器3丢失：执行器心跳在122093毫秒后超时

TaskSchedulerImpl:192.168.36.255上丢失的执行器3:id为3的执行器已被用户或框架删除。

执行者的最后日志如下所示：

TaskMemoryManager:未能分配页面（33554432字节），请重试。

然后，我密切监视着记忆。我观察到，空闲堆的数量有明显的下降趋势（最终下降到只有200M），而Kafka common和client packages（）中的一些对象的数量有上升趋势。在最后的堆转储中，除了JDK对象之外，剩下的大部分对象都来自Kafka common和client包。 样本包括：

org.apache.kafka.common.MetricName

org.apache.kafka.common.metrics.KafkaMetric

org.apache.kafka.common.metrics.Sensor

org.apache.kafka.common.metrics.stats.SampledStat$Sample

org.apache.kafka.clients.ApiVersion

---

在我看来，Spark Structured Streaming/Kafka中存在一个小内存泄漏。它是SSS的bug还是卡夫卡的bug？以前有没有人遇到过类似的问题？有人能就如何解决这个问题提出一些建议吗？

我们在Spark 3.0.1 SStream上观察到了相同的问题，其中包含Kafka数据源和S3流。仍在调查中，但未释放的内存似乎属于卡夫卡客户端。自10月份以来，您找到解决方案了吗？