[IMPALA-2399] Cleanup/rethink QueryMaintenance() calls in the BE.

• Type: Improvement
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Affects Version/s: Impala 2.3.0
• Component/s: Backend
• Labels: performance query-lifecycle
• Target Version: Product Backlog
• Assignee: Unassigned
• Reporter: Alexander Behm
• Created: 23/Sep/15 20:41
• Updated: 19/May/20 20:37

Description

In our BE execution, we currently call QueryMaintenance() and check for cancellation very generously, e.g., at the beginning of every GetNext() or in tight loops that could run for a long time (e.g. due to selective predicates).

Our current pattern of usage has several problems:
1. QueryMaintenance() is expensive, but the function name is rather opaque to this fact. It traverses the mem tracker hierarchy checking for the mem limit, and also checks the query status under a spin lock. It is not clear that these checks need to be coupled and called so frequently. We should place these checks judiciously/appropriately because QueryMaintenance() can become a performance bottleneck especially in subplan execution.

2. We always couple QueryMaintenance() with checking for cancellation. There is an existing TODO in the code to address this (see runtime-state.cc RuntimeState::CheckQueryState()).

See these code reviews for additional discussion:
http://gerrit.cloudera.org:8080/894
http://gerrit.cloudera.org:8080/901

Issue Links

• depends upon: IMPALA-5844 Fix management of FunctionContext "local" allocations.
• is blocked by: IMPALA-2384 Check memory limits in RowBatch constructor and RowBatch::Reset().
• is related to: IMPALA-6997 Query execution should notice UDF MemLimitExceeded errors more quickly
• is related to: IMPALA-2712 Investigate increasing batch size