[jira] [Commented] (IMPALA-6969) Profile doesn't include the reason that a query couldn't be dequeued from admission controller

2019-02-21 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/IMPALA-6969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774446#comment-16774446
 ] 

ASF subversion and git services commented on IMPALA-6969:
-

Commit bce16750fe763d1a8b50d4e3ffc32718eacea1f2 in impala's branch 
refs/heads/2.x from Tim Armstrong
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=bce1675 ]

IMPALA-6969: add AC last queued reason to profile

The reason is updated during initial admission and when the query is at
the head of the queue but can't be admitted. It is not updated while
the query is in the middle of the queue.

Together with the async admission change, this makes it possible to
determine from the profile why the query has not been admitted yet.

Testing:
Added admission control tests that check that the
string is set for queries queued based both on the
query count and the max memory.

Looped the tests overnight to confirm non-flakiness.

Change-Id: Ida9b75dc50dfb7a27f59deda91bad6ac838130a1
Reviewed-on: http://gerrit.cloudera.org:8080/10731
Reviewed-by: Impala Public Jenkins 
Tested-by: Impala Public Jenkins 


> Profile doesn't include the reason that a query couldn't be dequeued from 
> admission controller
> --
>
> Key: IMPALA-6969
> URL: https://issues.apache.org/jira/browse/IMPALA-6969
> Project: IMPALA
>  Issue Type: Improvement
>  Components: Backend
>Affects Versions: Impala 3.0, Impala 2.12.0
>Reporter: Tim Armstrong
>Assignee: Tim Armstrong
>Priority: Major
>  Labels: admission-control, observability
> Fix For: Impala 3.1.0
>
>
> I noticed this while playing around on a local minicluster with AC enabled.
> The admission controller adds the reason for initial queuing to the profile, 
> but does not expose why the query couldn't execute when it got to the head of 
> the line. E.g. if it was initially queued because the queue was non-empty but 
> then couldn't execute once it got to the head of the line because of memory.
> {noformat}
> Request Pool: root.queueA
> Admission result: Admitted (queued)
> Admission queue details: waited 1130 ms, reason: queue is not empty (size 
> 4); queued queries are executed first
> {noformat}
> We should still include the initial reason for queuing, but also include the 
> most reason for queuing once it got to the head of the line. It's probably 
> most useful to keep the profile updated with the latest reason at all times 
> (since the details can change while the query is at the head of the line).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org



[jira] [Commented] (IMPALA-6969) Profile doesn't include the reason that a query couldn't be dequeued from admission controller

2018-05-15 Thread Tim Armstrong (JIRA)

[ 
https://issues.apache.org/jira/browse/IMPALA-6969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476583#comment-16476583
 ] 

Tim Armstrong commented on IMPALA-6969:
---

I prototyped a fix of this. It touches the same code as the async queuing, so I 
won't finish it off until that is merged.

> Profile doesn't include the reason that a query couldn't be dequeued from 
> admission controller
> --
>
> Key: IMPALA-6969
> URL: https://issues.apache.org/jira/browse/IMPALA-6969
> Project: IMPALA
>  Issue Type: Improvement
>  Components: Backend
>Affects Versions: Impala 3.0, Impala 2.12.0
>Reporter: Tim Armstrong
>Assignee: Tim Armstrong
>Priority: Major
>  Labels: admission-control, observability
>
> I noticed this while playing around on a local minicluster with AC enabled.
> The admission controller adds the reason for initial queuing to the profile, 
> but does not expose why the query couldn't execute when it got to the head of 
> the line. E.g. if it was initially queued because the queue was non-empty but 
> then couldn't execute once it got to the head of the line because of memory.
> {noformat}
> Request Pool: root.queueA
> Admission result: Admitted (queued)
> Admission queue details: waited 1130 ms, reason: queue is not empty (size 
> 4); queued queries are executed first
> {noformat}
> We should still include the initial reason for queuing, but also include the 
> most reason for queuing once it got to the head of the line. It's probably 
> most useful to keep the profile updated with the latest reason at all times 
> (since the details can change while the query is at the head of the line).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org