[
https://issues.apache.org/jira/browse/HBASE-15971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15325494#comment-15325494
]
stack commented on HBASE-15971:
-------------------------------
Looking at stack traces, they look similar. Only difference was this:
hbase.ipc.server.reservoir.direct.buffer I set it to false in branch-1 and made
no difference in throughput (made the stack traces look the same). 0.98 has the
same ugly contention on registration of region scanners that 1.0 has and this
is what shows in stack traces -- adding and removal of Scanners. Will be back
to fix this (HBASE-15716). With the 0.98 scheduler in place under branch-1, the
difference is 280k/sec to 335k/sec, about 25% (the scheduler that sorts by
priority costs us 25% throughput... 210k/sec vs 270k/sec)... so looking for
culprit for this other 25% still.
> 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,
> branch-1.hits.png, branch-1.png, 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)
