[
https://issues.apache.org/jira/browse/HBASE-22346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Shelukhin updated HBASE-22346:
-------------------------------------
Description:
I was looking at using the priority (deadline) queue for scanner requests; what
I see is that AnnotationReadingPriorityFunction, the only impl of the deadline
function available, implements getDeadline as sqrt of the number of next()
calls, from HBASE-10993.
However, CallPriorityComparator.compare, its only caller, adds that "deadline"
value to the callA.getReceiveTime() in milliseconds...
That results in some sort of a meaningless value that I assume only make sense
"by coincidence" for telling apart broad and specific classes of scanners... in
practice next calls must be in the 1000s before it becomes meaningful vs small
differences in ReceivedTime
When there's contention from many scanners, e.g. small scanners for meta, or
just users creating tons of scanners to the point where requests queue up, the
actual deadline is not accounted for and the priority function itself is
meaningless... In fact as queueing increases, it becomes worse because
receivedtime differences grow.
was:
I was looking at using the priority (deadline) queue for scanner requests; what
I see is that AnnotationReadingPriorityFunction, the only impl of the deadline
function available, implements getDeadline as sqrt of the number of next()
calls, from HBASE-10993.
However, CallPriorityComparator.compare, its only caller, adds that "deadline"
value to the callA.getReceiveTime() in milliseconds...
That results in some sort of a meaningless value that I assume only make sense
"by coincidence" for telling apart broad and specific classes of scanners... in
practice next calls must be in the 1000s before it becomes meaningful vs small
differences in ReceivedTime
When there's contention for many scanners, e.g. small scanners for meta, or
just users creating tons of scanners to the point where requests queue up, the
actual deadline is not accounted for and the priority function itself is
meaningless... In fact as queueing increases, it becomes worse because
receivedtime differences grow.
> scanner priorities/deadline units are invalid for non-huge scanners
> -------------------------------------------------------------------
>
> Key: HBASE-22346
> URL: https://issues.apache.org/jira/browse/HBASE-22346
> Project: HBase
> Issue Type: Bug
> Reporter: Sergey Shelukhin
> Priority: Major
>
> I was looking at using the priority (deadline) queue for scanner requests;
> what I see is that AnnotationReadingPriorityFunction, the only impl of the
> deadline function available, implements getDeadline as sqrt of the number of
> next() calls, from HBASE-10993.
> However, CallPriorityComparator.compare, its only caller, adds that
> "deadline" value to the callA.getReceiveTime() in milliseconds...
> That results in some sort of a meaningless value that I assume only make
> sense "by coincidence" for telling apart broad and specific classes of
> scanners... in practice next calls must be in the 1000s before it becomes
> meaningful vs small differences in ReceivedTime
> When there's contention from many scanners, e.g. small scanners for meta, or
> just users creating tons of scanners to the point where requests queue up,
> the actual deadline is not accounted for and the priority function itself is
> meaningless... In fact as queueing increases, it becomes worse because
> receivedtime differences grow.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
