[
https://issues.apache.org/jira/browse/HBASE-15716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15259371#comment-15259371
]
stack commented on HBASE-15716:
-------------------------------
Smile.
Relies on the fact that as we create new scanners, they'll always be with the
same or newer read points. CHM which seems to have ok guarantees in face of
concurrency. getSmallestReadPoint can be called by more than one thread and
"Iterators and Enumerations return elements reflecting the state of the hash
table at some point at or since the creation of the iterator/enumeration. ...,
iterators are designed to be used by only one thread at a time.".. but should
be ok since only one thread will iterate at a time. Was thinking change this to
sortedset<Long> of read points and just get the oldest... then no iteration.
Thanks for looking [~lhofhansl]
> HRegion#RegionScannerImpl scannerReadPoints synchronization costs
> -----------------------------------------------------------------
>
> Key: HBASE-15716
> URL: https://issues.apache.org/jira/browse/HBASE-15716
> Project: HBase
> Issue Type: Bug
> Components: Performance
> Reporter: stack
> Attachments: 15716.prune.synchronizations.patch, Screen Shot
> 2016-04-26 at 2.05.45 PM.png, Screen Shot 2016-04-26 at 2.06.14 PM.png,
> Screen Shot 2016-04-26 at 2.07.06 PM.png, Screen Shot 2016-04-26 at 2.25.26
> PM.png, Screen Shot 2016-04-26 at 6.02.29 PM.png, remove_cslm.patch
>
>
> Here is a [~lhofhansl] special.
> When we construct the region scanner, we get our read point and then store it
> with the scanner instance in a Region scoped CSLM. This is done under a
> synchronize on the CSLM.
> This synchronize on a region-scoped Map creating region scanners is the
> outstanding point of lock contention according to flight recorder (My work
> load is workload c, random reads).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
