[
https://issues.apache.org/jira/browse/HBASE-7336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13529647#comment-13529647
]
Lars Hofhansl commented on HBASE-7336:
--------------------------------------
I have a patch, that changes that synchronized to a ReentrantLock and reverts
to pread if the lock cannot be acquired.
That way we get seek + read when possible and pread when necessary or
requested. Not that this is only for scans. Get default to pread anyway.
With that patch I get the following behavior:
One client: 15s
Two clients: 22s each
Which seems reasonable given above numbers.
I wouldn't really consider this a proper fix, although I also wouldn't know
what the proper fix should be.
The limiting factor here is a single FSInputStream per store file, which can be
devastating for performance if many threads read the same store file and it
does not fit into the block cache (or the scans chose not to cache the blocks).
> HFileBlock.readAtOffset does not work well with multiple threads
> ----------------------------------------------------------------
>
> Key: HBASE-7336
> URL: https://issues.apache.org/jira/browse/HBASE-7336
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Priority: Critical
> Fix For: 0.96.0, 0.94.4
>
>
> HBase grinds to a halt when many threads scan along the same set of blocks
> and neither read short circuit is nor block caching is enabled for the dfs
> client ... disabling the block cache makes sense on very large scans.
> It turns out that synchronizing in istream in HFileBlock.readAtOffset is the
> culprit.
--
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
