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 Tue, 28 Jun 2016 06:31:57 GMT

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

stack commented on HBASE-15716:

Address comment up on rb.

Also add hashcode and equals to region and to region scanner. Cache hashcode rather than get
it each time. Can see hash calculation adding keys to Map costs. More to do here. addChangedReaderObserver
has same issue. Scan hashcode is called a few times. Its intrinsic. Costs more than usual
method call but an actually calculated hashcode for Scan would be involved. TODO. But not
that important.

This patch would address the subject matter removing scannerReadPoints as point of contention.
What you think of the approach [~lhofhansl]? Depends on mvcc read point always going forward
and that when we get the smallest mvcc read point, it can't be less that a newly made scanner
since we don't proceed until we have registered a read point that is equal to current read
point. Also removes three or four needless synchronizes.

Doesn't get us much but just over 5% improvement in throughput on workloadc but we are on
to next hurdles, listed below.

Now Readers are mostly reading all the time blocked down in channel read. The handlers are
mostly doing channel writes. Making it so we can write back responses faster is next thing
to address. (Others are below):

1550 "RpcServer.FifoWFPBQ.default.handler=46,queue=1,port=16020" #91 daemon prio=5 os_prio=0
tid=0x00007f4255b4e000 nid=0x8909 runnable [0x00007f3a34bb0000]
1551    java.lang.Thread.State: RUNNABLE
1552   at java.lang.Object.hashCode(Native Method)
1553   at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1012)
1554   at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006)
1555   at java.util.Collections$SetFromMap.add(Collections.java:5461)
1556   at org.apache.hadoop.hbase.regionserver.HStore.addChangedReaderObserver(HStore.java:1161)
1557   at org.apache.hadoop.hbase.regionserver.StoreScanner.<init>(StoreScanner.java:199)

... is a version of our getting the Scan hash code anew. The Semaphore doing fastpath shows
up a bunch. For latter could try disruptor but how to write back faster will get biggest bang
for buck.

> 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.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,
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, 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

View raw message