spark-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Baker (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SPARK-21319) UnsafeExternalRowSorter.RowComparator memory leak
Date Wed, 05 Jul 2017 14:23:00 GMT

     [ https://issues.apache.org/jira/browse/SPARK-21319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

James Baker updated SPARK-21319:
--------------------------------
    Description: 
When we wish to sort within partitions, we produce an UnsafeExternalRowSorter. This contains
an UnsafeExternalSorter, which contains the UnsafeExternalRowComparator.

The UnsafeExternalSorter adds a task completion listener which performs any additional required
cleanup. The upshot of this is that we maintain a reference to the UnsafeExternalRowSorter.RowComparator
until the end of the task.

The RowComparator looks like

{code:java}
  private static final class RowComparator extends RecordComparator {
    private final Ordering<InternalRow> ordering;
    private final int numFields;
    private final UnsafeRow row1;
    private final UnsafeRow row2;

    RowComparator(Ordering<InternalRow> ordering, int numFields) {
      this.numFields = numFields;
      this.row1 = new UnsafeRow(numFields);
      this.row2 = new UnsafeRow(numFields);
      this.ordering = ordering;
    }

    @Override
    public int compare(Object baseObj1, long baseOff1, Object baseObj2, long baseOff2) {
      // TODO: Why are the sizes -1?
      row1.pointTo(baseObj1, baseOff1, -1);
      row2.pointTo(baseObj2, baseOff2, -1);
      return ordering.compare(row1, row2);
    }
}
{code}

which means that this will contain references to the last baseObjs that were passed in, and
without tracking them for purposes of memory allocation.

We have a job which sorts within partitions and then coalesces partitions - this has a tendency
to OOM because of the references to old UnsafeRows that were used during the sorting.

Attached is a screenshot of a memory dump during a task - our JVM has two executor threads.

It can be seen that we have 2 references inside of row iterators, and 11 more which are only
known in the task completion listener or as part of memory management.

  was:
When we wish to sort within partitions, we produce an UnsafeExternalRowSorter. This contains
an UnsafeExternalSorter, which contains the UnsafeExternalRowComparator.

The UnsafeExternalSorter adds a task completion listener which performs any additional required
cleanup. The upshot of this is that we maintain a reference to the UnsafeExternalRowSorter.RowComparator
until the end of the task.

The RowComparator looks like

{code:java}
  private static final class RowComparator extends RecordComparator {
    private final Ordering<InternalRow> ordering;
    private final int numFields;
    private final UnsafeRow row1;
    private final UnsafeRow row2;

    RowComparator(Ordering<InternalRow> ordering, int numFields) {
      this.numFields = numFields;
      this.row1 = new UnsafeRow(numFields);
      this.row2 = new UnsafeRow(numFields);
      this.ordering = ordering;
    }

    @Override
    public int compare(Object baseObj1, long baseOff1, Object baseObj2, long baseOff2) {
      // TODO: Why are the sizes -1?
      row1.pointTo(baseObj1, baseOff1, -1);
      row2.pointTo(baseObj2, baseOff2, -1);
      return ordering.compare(row1, row2);
    }
}
{code}

which means that this will contain references to the last baseObjs that were passed in, and
without tracking them for purposes of memory allocation.

We have a job which sorts within partitions and then coalesces partitions - this has a tendency
to OOM because of the references to old UnsafeRows that were used during the sorting.

This is a screenshot of a memory dump during a task - our JVM has two executor threads.

!hprof.png|thumbnail!

It can be seen that we have 2 references inside of row iterators, and 11 more which are only
known in the task completion listener or as part of memory management.


> UnsafeExternalRowSorter.RowComparator memory leak
> -------------------------------------------------
>
>                 Key: SPARK-21319
>                 URL: https://issues.apache.org/jira/browse/SPARK-21319
>             Project: Spark
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 2.0.0, 2.1.0, 2.2.0, 2.3.0
>            Reporter: James Baker
>         Attachments: hprof.png
>
>
> When we wish to sort within partitions, we produce an UnsafeExternalRowSorter. This contains
an UnsafeExternalSorter, which contains the UnsafeExternalRowComparator.
> The UnsafeExternalSorter adds a task completion listener which performs any additional
required cleanup. The upshot of this is that we maintain a reference to the UnsafeExternalRowSorter.RowComparator
until the end of the task.
> The RowComparator looks like
> {code:java}
>   private static final class RowComparator extends RecordComparator {
>     private final Ordering<InternalRow> ordering;
>     private final int numFields;
>     private final UnsafeRow row1;
>     private final UnsafeRow row2;
>     RowComparator(Ordering<InternalRow> ordering, int numFields) {
>       this.numFields = numFields;
>       this.row1 = new UnsafeRow(numFields);
>       this.row2 = new UnsafeRow(numFields);
>       this.ordering = ordering;
>     }
>     @Override
>     public int compare(Object baseObj1, long baseOff1, Object baseObj2, long baseOff2)
{
>       // TODO: Why are the sizes -1?
>       row1.pointTo(baseObj1, baseOff1, -1);
>       row2.pointTo(baseObj2, baseOff2, -1);
>       return ordering.compare(row1, row2);
>     }
> }
> {code}
> which means that this will contain references to the last baseObjs that were passed in,
and without tracking them for purposes of memory allocation.
> We have a job which sorts within partitions and then coalesces partitions - this has
a tendency to OOM because of the references to old UnsafeRows that were used during the sorting.
> Attached is a screenshot of a memory dump during a task - our JVM has two executor threads.
> It can be seen that we have 2 references inside of row iterators, and 11 more which are
only known in the task completion listener or as part of memory management.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org


Mime
View raw message