[
https://issues.apache.org/jira/browse/HBASE-15716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15367838#comment-15367838
]
stack commented on HBASE-15716:
-------------------------------
This is part of a project that is trying to remove all or most points of
synchronization so threads can run free and burn all CPU at least in the simple
case such as this where all is cached and all is random read load. Currently we
leave lots of CPU idle especially on big machines [~lhofhansl]
I'm not measuring a 'run'. I'm putting up the load, letting it settle, then I
start honest profiler/perf and let it run for a minute.
I wouldn't be surprised if no wall clock improvement. Haven't measured it
though.
After this issue is addressed, we no longer show synchronization in tooling
such as JFR apart from some incidentals. Finding next tier of blockage that is
preventing our use of all CPU will take a different, tougher kind of analysis:
e.g. Counters burn most CPU so we are in there a lot; are they such a friction,
they slow down the macro throughput?
> HRegion#RegionScannerImpl scannerReadPoints synchronization constrains random
> read
> ----------------------------------------------------------------------------------
>
> 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.implementation.using.ScannerReadPoints.branch-1.patch,
> 15716.prune.synchronizations.patch, 15716.prune.synchronizations.v3.patch,
> 15716.prune.synchronizations.v4.patch, 15716.prune.synchronizations.v4.patch,
> 15716.wip.more_to_be_done.patch, HBASE-15716.branch-1.001.patch,
> HBASE-15716.branch-1.002.patch, HBASE-15716.branch-1.003.patch,
> HBASE-15716.branch-1.004.patch, HBASE-15716.branch-1.005.patch,
> ScannerReadPoints.java, ScannerReadPoints.v2.java, 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, Screen Shot 2016-06-30 at 9.52.52 PM.png, Screen Shot 2016-06-30 at
> 9.54.08 PM.png, TestScannerReadPointDoesntGoBack.java,
> TestScannerReadPoints.java, before_after.png,
> current-branch-1.vs.NoSynchronization.vs.Patch.png, hits.png,
> remove.locks.patch, 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)
