[
https://issues.apache.org/jira/browse/SPARK-24437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840498#comment-16840498
]
Eyal Farago commented on SPARK-24437:
-------------------------------------
[~mgaido], looking at this again I suspect in this case loosing the broadcast
does not necessarily means loosing the lineage as the broadcast was built by
executing a plan and this plan is still available in case the broadcast isn't.
I think the usage of broadcast variables inside spark sql is different than
that of directly using them in the RDD API. While in the RDD API the
broadcasted data is actually originated at the driver and spark has no way of
reconstructing this data, in the spark-sql scenario the broadcasted data is
built by spark and the knowledge of reconstructing this data is still available
for spark so in the rare event both the broadcast and part of the cached
partitions are lost it's possible to reconstruct the broadcasted value (by
executing the plan that produced this data in the first place) and then
recompute the missing partitions again.
I think it's at least theoretically possible to identify cached plans based on
broadcasted data and change the relevant operators to reference the broadcast
variable via a soft/weak reference. unfortunately I believe it'd turn out to be
quite difficult, especially in the face of no-deterministic operators.
> Memory leak in UnsafeHashedRelation
> -----------------------------------
>
> Key: SPARK-24437
> URL: https://issues.apache.org/jira/browse/SPARK-24437
> Project: Spark
> Issue Type: Bug
> Components: SQL
> Affects Versions: 2.2.0
> Reporter: gagan taneja
> Priority: Major
> Attachments: Screen Shot 2018-05-30 at 2.05.40 PM.png, Screen Shot
> 2018-05-30 at 2.07.22 PM.png, Screen Shot 2018-11-01 at 10.38.30 AM.png
>
>
> There seems to memory leak withÂ
> org.apache.spark.sql.execution.joins.UnsafeHashedRelation
> We have a long running instance of STS.
> With each query execution requiring Broadcast Join, UnsafeHashedRelation is
> getting added for cleanup in ContextCleaner. This reference of
> UnsafeHashedRelation is being held at some other Collection and not becoming
> eligible for GC and because of this ContextCleaner is not able to clean it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
