[
https://issues.apache.org/jira/browse/HBASE-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13724944#comment-13724944
]
Chao Shi commented on HBASE-7266:
---------------------------------
We are experiencing this too. This happens when a large number of concurrent
scan requests on a single region. Because of the lock (on seek+read), only one
handler thread is effectively working. Our scan range is very small (just a few
adjacent rows, fits into 1 block).
> [89-fb] Using pread for non-compaction read request
> ---------------------------------------------------
>
> Key: HBASE-7266
> URL: https://issues.apache.org/jira/browse/HBASE-7266
> Project: HBase
> Issue Type: Improvement
> Reporter: Liyin Tang
>
> There are 2 kinds of read operations in HBase: pread and seek+read.
> Pread, positional read, is stateless and create a new connection between the
> DFSClient and DataNode for each operation. While seek+read is to seek to a
> specific postion and prefetch blocks from data nodes. The benefit of
> seek+read is that it will cache the prefetch result but the downside is it is
> stateful and needs to synchronized.
> So far, both compaction and scan are using seek+read, which caused some
> resource contention. So using the pread for the scan request can avoid the
> resource contention. In addition, the region server is able to do the
> prefetch for the scan request (HBASE-6874) so that it won't be necessary to
> let the DFSClient to prefetch the data any more.
> I will run through the scan benchmark (with no block cache) with verify the
> performance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
