You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@impala.apache.org by "Riza Suminto (Jira)" <ji...@apache.org> on 2024/04/19 19:30:00 UTC

[jira] [Resolved] (IMPALA-12980) Translate CpuAsk into admission control slot to use

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

Riza Suminto resolved IMPALA-12980.
-----------------------------------
    Fix Version/s: Impala 4.4.0
       Resolution: Fixed

> Translate CpuAsk into admission control slot to use
> ---------------------------------------------------
>
>                 Key: IMPALA-12980
>                 URL: https://issues.apache.org/jira/browse/IMPALA-12980
>             Project: IMPALA
>          Issue Type: Improvement
>          Components: Distributed Exec, Frontend
>            Reporter: Riza Suminto
>            Assignee: Riza Suminto
>            Priority: Major
>             Fix For: Impala 4.4.0
>
>
> Admission control slot accounting is described in IMPALA-8998. On each backend, number of. It compute 'slots_to_use' for each backend based on the max number of instances of any fragment on that backend. This is simplistic, because multiple fragments with same number of instance count, say 4 non-blocking fragments each with 12 instances, only request the max instance (12) admission slots rather than sum of it (48).
> When COMPUTE_PROCESSING_COST is enabled, Planner will generate a CpuAsk number that represent the cpu requirement of that query over a particular executor group set. This number is an estimation of what is the largest number of query fragments that can run in-parallel given the blocking operator analysis. Therefore, the fragment trace that sums into that CpuAsk number can be translated into 'slots_to_use' as well, which will be a closer resemblance of maximum parallel execution of fragment instances.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)