You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "stack (JIRA)" <ji...@apache.org> on 2016/06/06 03:01:02 UTC

[jira] [Commented] (HBASE-15716) HRegion#RegionScannerImpl scannerReadPoints synchronization constrains random read

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

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

Interesting observation was hacking out this lock, I ran then into my being blocked responding... 

{code}
"RpcServer.reader=1,bindAddress=ve0528.halxg.cloudera.com,port=16020" #34 daemon prio=5 os_prio=0 tid=0x00007fa76d886800 nid=0x59f0 runnable [0x00007f9f515e9000]
   java.lang.Thread.State: RUNNABLE
        at sun.nio.ch.NativeThread.current(Native Method)
        at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:501)
        - locked <0x00007fa41f096f40> (a java.lang.Object)
        - locked <0x00007fa41f096f28> (a java.lang.Object)
        at org.apache.hadoop.hbase.ipc.BufferChain.write(BufferChain.java:105)
        at org.apache.hadoop.hbase.ipc.RpcServer.channelWrite(RpcServer.java:2401)
        at org.apache.hadoop.hbase.ipc.RpcServer$Responder.processResponse(RpcServer.java:1072)
        at org.apache.hadoop.hbase.ipc.RpcServer$Responder.doRespond(RpcServer.java:1136)
        at org.apache.hadoop.hbase.ipc.RpcServer$Call.sendResponseIfReady(RpcServer.java:570)
        - locked <0x00007f9fbf7652d0> (a org.apache.hadoop.hbase.ipc.RpcServer$Call)
        at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:139)
        at org.apache.hadoop.hbase.ipc.SimpleRpcScheduler.dispatch(SimpleRpcScheduler.java:274)
        at org.apache.hadoop.hbase.ipc.RpcServer$Connection.processRequest(RpcServer.java:1871)
        at org.apache.hadoop.hbase.ipc.RpcServer$Connection.processOneRpc(RpcServer.java:1762)
        at org.apache.hadoop.hbase.ipc.RpcServer$Connection.process(RpcServer.java:1608)
        at org.apache.hadoop.hbase.ipc.RpcServer$Connection.readAndProcess(RpcServer.java:1588)
        at org.apache.hadoop.hbase.ipc.RpcServer$Listener.doRead(RpcServer.java:838)
        at org.apache.hadoop.hbase.ipc.RpcServer$Listener$Reader.doRunLoop(RpcServer.java:696)
        - locked <0x00007fa06a26acc0> (a org.apache.hadoop.hbase.ipc.RpcServer$Listener$Reader)
        at org.apache.hadoop.hbase.ipc.RpcServer$Listener$Reader.run(RpcServer.java:667)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
{code}


Other notes on this synchronization are that as the throughput goes up, this synchronization becomes more of an obstacle. At rates of hundreds of ops a second, the churn in the CSLM shows... I should be able to do an array of volatiles or something sized by handlers/readers? I should also be able to do something with the fact that readpt is always incrementing... will be back.

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