[
https://issues.apache.org/jira/browse/HBASE-15971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15326180#comment-15326180
]
stack commented on HBASE-15971:
-------------------------------
bq. Whether the mvcc decoding have an impact Stack?
Didn't see it show up here [~anoop.hbase] Not worried about where the CPU is
spent at moment, just about regression and then, being able to drive all the
CPU. Can then come along after and spend time on what the CPU is doing
(Counters are our worst offender in this workload).
> 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)
