[
https://issues.apache.org/jira/browse/HBASE-15971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15331972#comment-15331972
]
Sean Busbey commented on HBASE-15971:
-------------------------------------
Hurm. I'm fine with either 1) just calling this out as a known issue for 1.0 -
1.2 with instructions on configuring the change, or 2) changing the default as
done here since there are instructions in the release note about how folks can
ensure they keep the deadline scheduler if they need it for some reason.
Strictly speaking, #1 would be more conservative. But since it makes such a big
difference out of the box, and our only way of doing "known issues" would be to
add a notice box to the ref guide section "Request Queues", I'm inclined to be
bend.
what do other folks think?
> 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
> Affects Versions: 2.0.0, 1.3.0
> Reporter: stack
> Assignee: stack
> Priority: Critical
> Fix For: 2.0.0, 1.3.0
>
> Attachments: 098.hits.png, 098.png, HBASE-15971.branch-1.001.patch,
> HBASE-15971.branch-1.002.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)
