[
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
(v6.3.4#6332)
