hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-15716) HRegion#RegionScannerImpl scannerReadPoints synchronization constrains random read
Date Fri, 08 Jul 2016 15:46:11 GMT

    [ 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)

Mime
View raw message