hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-14331) a single callQueue related improvements
Date Wed, 15 Jun 2016 03:31:44 GMT

    [ https://issues.apache.org/jira/browse/HBASE-14331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15331034#comment-15331034
] 

stack commented on HBASE-14331:
-------------------------------

Do you want to close this issue then in favor of HBASE-14479?

The handoff from Reader to Handler is a perf killer. Running more threads than there are CPUs,
at least in the read case where all is from cache, only makes us slower.

But the handoff of Reader to Handler is where we do request scheduling. Currently we have
a scheduling that will try to background requests that come from long-running Scans in favor
of other request types ('deadline'). It could be made do more sophisticated scheduling but
we should probably put this aside and just take on the recent FB addition of AdaptiveLifoCoDelCallQueue
as  our default policy (See http://queue.acm.org/detail.cfm?id=2839461). It is a general heuristic
that works well for a broad set of loadings.

So, where would we do scheduling if the Reader threads ran the request [~ikeda]? Thanks.

> a single callQueue related improvements
> ---------------------------------------
>
>                 Key: HBASE-14331
>                 URL: https://issues.apache.org/jira/browse/HBASE-14331
>             Project: HBase
>          Issue Type: Improvement
>          Components: IPC/RPC, Performance
>            Reporter: Hiroshi Ikeda
>            Assignee: Hiroshi Ikeda
>         Attachments: BlockingQueuesPerformanceTestApp-output.pdf, BlockingQueuesPerformanceTestApp-output.txt,
BlockingQueuesPerformanceTestApp.java, CallQueuePerformanceTestApp.java, HBASE-14331-V2.patch,
HBASE-14331-V3.patch, HBASE-14331-V4.patch, HBASE-14331-V5.patch, HBASE-14331-V6.patch, HBASE-14331-V6.patch,
HBASE-14331.patch, HBASE-14331.patch, SemaphoreBasedBlockingQueue.java, SemaphoreBasedLinkedBlockingQueue.java,
SemaphoreBasedPriorityBlockingQueue.java
>
>
> {{LinkedBlockingQueue}} well separates locks between the {{take}} method and the {{put}}
method, but not between takers, and not between putters. These methods are implemented to
take locks at the almost beginning of their logic. HBASE-11355 introduces multiple call-queues
to reduce such possible congestion, but I doubt that it is required to stick to {{BlockingQueue}}.
> There are the other shortcomings of using {{BlockingQueue}}. When using multiple queues,
since {{BlockingQueue}} blocks threads it is required to prepare enough threads for each queue.
It is possible that there is a queue starving for threads while there is another queue where
threads are idle. Even if you can tune parameters to avoid such situations, the tuning is
not so trivial.
> I suggest using a single {{ConcurrentLinkedQueue}} with {{Semaphore}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message