You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Jiatao Tao (Jira)" <ji...@apache.org> on 2020/11/03 08:06:00 UTC
[jira] [Commented] (CALCITE-4358) Potential memory leak in
VolcanoPlanner#materializations due to circular reference
[ https://issues.apache.org/jira/browse/CALCITE-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225221#comment-17225221 ]
Jiatao Tao commented on CALCITE-4358:
-------------------------------------
We use ForkJoinPool for optimizing, <Java Local> thread comes from this.
In the dump, we found it is full of VolcanoPlanner instance, and I dig into found it circle.
> Potential memory leak in VolcanoPlanner#materializations due to circular reference
> ----------------------------------------------------------------------------------
>
> Key: CALCITE-4358
> URL: https://issues.apache.org/jira/browse/CALCITE-4358
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Jiatao Tao
> Assignee: Jiatao Tao
> Priority: Major
> Attachments: screenshot-1.png
>
>
> Hi fellows
> We use Calcite's materialization view in our product env, and it OOM times, I dig the memory dump and found there are all of RelOptMaterialization instance.
>
> We will call Planner#clear before every query and will new a new Planner just as org.apache.calcite.prepare.CalcitePrepareImpl did, and inside the dump, there are lots of planner instance, so I suspect it is a circular reference that JVM can not GC them, here's the chain:
>
> 1. org.apache.calcite.plan.volcano.VolcanoPlanner#materializations: List<RelOptMaterialization>
> 2. org.apache.calcite.plan.RelOptMaterialization#queryRel: AbstractRelNode
> 3. org.apache.calcite.rel.AbstractRelNode#cluster: RelOptCluster
> 4. org.apache.calcite.plan.RelOptCluster#planner: VolcanoPlanner
> 5. org.apache.calcite.plan.volcano.VolcanoPlanner#materializations: List<RelOptMaterialization>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)