hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiroshi Ikeda (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-15971) Regression: Random Read/WorkloadC slower in 1.x than 0.98
Date Mon, 13 Jun 2016 06:39:21 GMT

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

Hiroshi Ikeda commented on HBASE-15971:
---------------------------------------

There seems excessive contention when the reader threads put requests into the blocking queue.
Even LinkedBlockingQueue is not optimized for simultaneous puts and for simultaneous takes.

For the FIFO queue, replacing LinkedBlockingQueue with LinkedTransferQueue is the easiest
way if you uses Java 7 or later, or you can create a pseudo one using semaphore and ConcurrentLinkedQueue.
For the priority queue you can create a pseudo one using semaphore and ConcurrentSkipListMap.


The "pseudo" means it seems difficult to completely implement the contract of the blocking
queue interface, and you will cheat by throwing AssertionError or something for some methods.
In actual, complete blocking queues are not required for the RPC handlers, but introducing
a new interface is followed by non-trivial changes (and I was exhausted in HBASE-14331 :P)


> Regression: Random Read/WorkloadC slower in 1.x than 0.98
> ---------------------------------------------------------
>
>                 Key: HBASE-15971
>                 URL: https://issues.apache.org/jira/browse/HBASE-15971
>             Project: HBase
>          Issue Type: Sub-task
>          Components: rpc
>            Reporter: stack
>            Assignee: stack
>            Priority: Critical
>         Attachments: 098.hits.png, 098.png, HBASE-15971.branch-1.001.patch, Screen Shot
2016-06-10 at 5.08.24 PM.png, Screen Shot 2016-06-10 at 5.08.26 PM.png, branch-1.hits.png,
branch-1.png, flight_recording_10172402220203_28.branch-1.jfr, flight_recording_10172402220203_29.09820.0.98.20.jfr,
handlers.fp.png, hits.fp.png, hits.patched1.0.vs.unpatched1.0.vs.098.png, run_ycsb.sh
>
>
> branch-1 is slower than 0.98 doing YCSB random read/workloadC. It seems to be doing about
1/2 the throughput of 0.98.
> In branch-1, we have low handler occupancy compared to 0.98. Hacking in reader thread
occupancy metric, is about the same in both. In parent issue, hacking out the scheduler, I
am able to get branch-1 to go 3x faster so will dig in here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message