[
https://issues.apache.org/jira/browse/HBASE-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-15046:
--------------------------
Attachment: writes.png
latencies.png
all_under_lock.svg
all_under_lock.patch
Simple patch that has all operations happen under the row lock (i.e. moves the
sync and catchup on mvcc all under the row lock where before these were done
after releasing locks).
TODO: this doMiniBatch method is pages long and hard to follow. It has DLR
handling and rollback of memstore (which will not be needed if we go forward on
this path where we sync the WAL first before updating memstore) as well as code
copy/pasted in increment, append, etc. methods. Could do with some cleanup.
Flamegraph shows that after moving the sync, the profile looks the same with a
few percent saved here and there.
The other two graphs show that the rate of operations is up slightly... on
average above 12k/second where without patch, its below 12k per second. The
second graph is showing the new metrics that have how many ops happen inside a
latency window. It shows that with the patch, more ops are completing inside
the 0-1ms window than w/o the patch.
Next up is more extensive compare. This is short runs of the YCSB write-only
workload.
If all could be done under row lock, I could then put in place the Increment
fast path as default done in sibling issue and rather than it having narrow
consistency, if I change all ops to this all_under_lock pattern, then we'll
have back our row-based consistency.
> 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
> Attachments: 1.2.svg, 1.2.v2.svg, all_under_lock.patch,
> all_under_lock.svg, latencies.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)
