[
https://issues.apache.org/jira/browse/IMPALA-5497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Armstrong resolved IMPALA-5497.
-----------------------------------
Resolution: Fixed
Fix Version/s: Impala 2.10.0
IMPALA-5497: spilling hash joins that output build rows hit OOM
The bug is that the join tried to bring the next spilled partition into
memory while still holding onto memory from the current partition.
The fix is to return earlier if the output batch is at capacity so
that resources are flushed.
Also reduce some of the redundancy in the loop that drives the spilling
logic and catch some dropped statuses..
Testing:
The failure was originally reproduced by my IMPALA-4703 patch. I was
able to cause a query failure with the current code by reducing the
memory limit for an existing query. Before it failed with up to 12MB of
memory. Now it succeeds with 8MB or less.
Ran exhaustive build.
Change-Id: I075388d348499c5692d044ac1bc38dd8dd0b10c7
Reviewed-on: http://gerrit.cloudera.org:8080/7180
Reviewed-by: Dan Hecht <dhe...@cloudera.com>
Tested-by: Impala Public Jenkins
> Right anti, right outer and full outer hash joins sometimes do not flush
> resources early enough
> -----------------------------------------------------------------------------------------------
>
> Key: IMPALA-5497
> URL: https://issues.apache.org/jira/browse/IMPALA-5497
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
> Affects Versions: Impala 2.10.0
> Reporter: Tim Armstrong
> Assignee: Tim Armstrong
> Labels: resource-management
> Fix For: Impala 2.10.0
>
>
> This bug was found by running with IMPALA-4703 with the minimum possible
> reservation. The scenario is:
> 1. Processing of the last output build partition finishes (in
> OutputUnmatchedBuild())
> 2. Memory from that partition is attached to the output batch, bringing it to
> capacity.
> 3. Execution continues, with more memory allocated in
> PrepareSpilledPartitionForProbe()
> The bug is that we should be flushing all memory before moving onto the next
> spilled partition - the code for processing a new spilled partition assumes
> that all of the reserved buffers are available.
> {code}
> // Flush the remaining unmatched build rows of any partitions we are
> done
> // processing before moving onto the next partition.
> OutputUnmatchedBuild(out_batch);
> if (!output_build_partitions_.empty()) break;
> // Finished outputting unmatched build rows, move to next partition.
> DCHECK_EQ(builder_->num_hash_partitions(), 0);
> DCHECK(probe_hash_partitions_.empty());
> bool got_partition;
> RETURN_IF_ERROR(PrepareSpilledPartitionForProbe(state, &got_partition));
> if (!got_partition) {
> *eos = true;
> break;
> }
> if (out_batch->AtCapacity()) break;
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
