[
https://issues.apache.org/jira/browse/HBASE-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-15046:
--------------------------
Attachment: ops.png
gc.png
Here is perf run with the latest patch from HBASE-15082: i.e. wait on read
point to match write point before releasing row lock.
In the graph, we have before and after and its ycsb:
load
workloada (50read/50update)
workloadb (95read/5update)
workloadc (100read)
workloadf (50/read-modify-write 50)
Graphs show that for the 100% read case, workloadc, we are doing worse... (?)
-- 35k before and 30k ops after -- otherwise, the graphs are very similar.
Need to do 95% write and 5% read compare too... also figure out why we are
doing more GC'ing when this patch is in place; that don't seem right.. .should
be less..
> Perf test doing all mutation steps under row lock
> -------------------------------------------------
>
> Key: HBASE-15046
> URL: https://issues.apache.org/jira/browse/HBASE-15046
> Project: HBase
> Issue Type: Sub-task
> Components: Performance
> Reporter: stack
> Assignee: stack
> Attachments: 1.2.svg, 1.2.v2.svg, 50threads_ycsb.png,
> all_under_lock.patch, all_under_lock.svg, call_times_0-1_and_1-3_ycsb.png,
> gc.png, latencies.png, ops.png, writes.png
>
>
> This issue is about perf testing a redo of the write pipeline so that rather
> than:
> * take rowlock
> * start mvcc
> * append to WAL
> * add to memstore
> * sync WAL
> * let go of rowlock
> * finish up mvcc
> instead.... try...
> * take rowlock
> * start mvcc
> * append to WAL
> * sync WAL
> * add to memstore
> * finish up mvcc
> * let go of rowlock
> The latter is more straight-forward undoing need of rolling back memstore if
> all does not succeed.
> It might be slower though. This issue is a look-see/try it.
> The redo will also help address the parent issue in a more general way so we
> can do without the special-casing done for branch-1.0 and branch-1.1 done in
> a sibling subtask.
> Other benefits are that the current write pipeline is copy/pasted in a few
> places -- in append, increment and checkand* -- and a refactor will allow us
> to fix this duplication.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
