[
https://issues.apache.org/jira/browse/IMPALA-5713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Armstrong resolved IMPALA-5713.
-----------------------------------
Resolution: Fixed
Fix Version/s: Impala 2.10.0
IMPALA-5713: always reserve memory for preaggs
Before this change the preaggregation was frequently disabled when
running under some memory pressure, e.g. if the aggregation is at the
end of a pipeline of joins and those joins eat up all the memory.
This can result in huge performance degradation since all rows must then
be sent over the network.
This change always reserves 16 * (buffer size + 64kb) bytes per
preaggregation so that it is always able to build some hash tables and
reduce the input somewhat.
This has two parts:
* Changing the frontend reservation calculation
* Removing dead code in the backend that handled the case when the
initial partitions and hash tables could not be allocated.
Testing:
Passes exhaustive tests.
Change-Id: I2b544f9ec1a906719e2bbb074743926b95a3a573
Reviewed-on: http://gerrit.cloudera.org:8080/7739
Reviewed-by: Tim Armstrong <[email protected]>
Tested-by: Impala Public Jenkins
---
> Consider always reserving memory for grouping pre-aggregations
> --------------------------------------------------------------
>
> Key: IMPALA-5713
> URL: https://issues.apache.org/jira/browse/IMPALA-5713
> Project: IMPALA
> Issue Type: Sub-task
> Components: Backend
> Affects Versions: Impala 2.10.0
> Reporter: Tim Armstrong
> Assignee: Tim Armstrong
> Labels: resource-management
> Fix For: Impala 2.10.0
>
>
> The initial IMPALA-3200 code added the ability for a grouping pre-aggregation
> to run with zero reservation, passing through all of the rows. However, this
> is a very low performance mode for aggregations that reduce their input a
> lot, since it forces everything to be sent over the network. We would be
> better off in most cases requiring more memory but not allowing perf to
> degrade so much.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)