impala-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Armstrong (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (IMPALA-3748) Compute memory reservation in planner and claim atomically in Prepare()
Date Wed, 12 Jul 2017 04:23:00 GMT

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

Tim Armstrong resolved IMPALA-3748.
-----------------------------------
       Resolution: Fixed
    Fix Version/s: Impala 2.10.0

The below commit completes the frontend part of the change and plumbs it to the backend. The
backend doesn't do anything with it yet because nothing uses the reservations. The IMPALA-4674
patch will include the remaining plumbing.

IMPALA-4862: make resource profile consistent with backend behaviour

This moves away from the PipelinedPlanNodeSet approach of enumerating
sets of concurrently-executing nodes because unions would force
creating many overlapping sets of nodes. The new approach computes
the peak resources during Open() and the peak resources between Open()
and Close() (i.e. while calling GetNext()) bottom-up for each plan node
in a fragment. The fragment resources are then combined to produce the
query resources.

The basic assumptions for the new resource estimates are:
* resources are acquired during or after the first call to Open()
  and released in Close().
* Blocking nodes call Open() on their child before acquiring
  their own resources (this required some backend changes).
* Blocking nodes call Close() on their children before returning
  from Open().
* The peak resource consumption of the query is the sum of the
  independent fragments (except for the parallel join build plans
  where we can assume there will be synchronisation). This is
  conservative but we don't synchronise fragment Open() and Close()
  across exchanges so can't make stronger assumptions in general.

Also compute the sum of minimum reservations. This will be useful
in the backend to determine exactly when all of the initial
reservations have been claimed from a shared pool of initial reservations.

Testing:
* Updated planner tests to reflect behavioural changes.
* Added extra resource requirement planner tests for unions, subplans,
  pipelines of blocking operators, and bushy join plans.
* Added single-node plans to resource-requirements tests. These have
  more complex plan trees inside a single fragment, which is useful
  for testing the peak resource requirement logic.

Change-Id: I492cf5052bb27e4e335395e2a8f8a3b07248ec9d
Reviewed-on: http://gerrit.cloudera.org:8080/7223
Reviewed-by: Tim Armstrong <tarmstrong@cloudera.com>
Tested-by: Impala Public Jenkins

> Compute memory reservation in planner and claim atomically in Prepare()
> -----------------------------------------------------------------------
>
>                 Key: IMPALA-3748
>                 URL: https://issues.apache.org/jira/browse/IMPALA-3748
>             Project: IMPALA
>          Issue Type: Sub-task
>          Components: Backend
>    Affects Versions: Impala 2.7.0
>            Reporter: Tim Armstrong
>            Assignee: Tim Armstrong
>            Priority: Minor
>              Labels: resource-management
>             Fix For: Impala 2.10.0
>
>
> Once we have the reservation infrastructure available, we want to make use of it by claiming
memory reservations upfront in the Prepare() phase of the query. 
> * Compute minimum buffer pool memory requirements for each operator, and compute the
peak requirement (execution of some nodes does not overlap, so this depends on the plan shape).
> * Claim those reservations for the query at start of Prepare(), so we can fail fast if
the memory isn't available
> * Distribute the reservations to the exec nodes.
> For the initial work, we can assume conservatively that all fragments run on all daemons,
so that we don't need scheduling information to compute the estimates. This may over-reserve
memory in some cases, since some fragments are unpartitioned or have fewer scan ranges than
daemons.



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

Mime
View raw message