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

stack commented on HBASE-15716:
-------------------------------

bq. Calculating the smallest readpoint can be called by another thread, even 
before the loop is complete. 

Yes.

I think it ok though since we do not let the scanner construction progress 
until for sure we've stamped the scannerReadPoints with current read point.

But thinking more prompted by your comments, I cannot say for certain that my 
hackery is 'safe'. There are too many 'holes' in between the reading of the 
mvcc readpoint and my setting it into scannerReadPoints. Then at read time, the 
CHM "...Iterators and Enumerations return elements reflecting the state of the 
hash table at some point at or since the creation of the iterator/enumeration. 
" makes for another 'hole'.

Let me keep they synchronization but redo to make it more narrow and to address 
your too-much-information comment above.

Thanks [~ikeda]



> 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
>            Assignee: stack
>         Attachments: 15716.prune.synchronizations.patch, 
> 15716.prune.synchronizations.v3.patch, 15716.prune.synchronizations.v4.patch, 
> 15716.prune.synchronizations.v4.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, Screen Shot 2016-04-27 at 9.49.35 AM.png, 
> current-branch-1.vs.NoSynchronization.vs.Patch.png, hits.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)

Reply via email to