hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Elliott Clark (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-15046) Perf test doing all mutation steps under row lock
Date Tue, 29 Dec 2015 03:30:51 GMT

    [ https://issues.apache.org/jira/browse/HBASE-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15073419#comment-15073419
] 

Elliott Clark edited comment on HBASE-15046 at 12/29/15 3:30 AM:
-----------------------------------------------------------------

bq.That was the whole point of rolling back the memstore, so that we can sync the wal to the
DNs without holding the row lock, I doubt we want to undo that part.

There can be any number of updates in flight for a single row. So holding the row lock longer
doesn't have the down side that it used to. Since every row lock is reader/writer the only
time that holding the lock longer has any performance issue is when there are puts and check/mutates
in flight to the same row. And @stack has already shown that increments are much faster by
not having to wait for mvcc ( made possible by holding the row lock longer).


was (Author: eclark):
bq.That was the whole point of rolling back the memstore, so that we can sync the wal to the
DNs without holding the row lock, I doubt we want to undo that part.

There can be any number of updates in flight for a single row. So holding the row lock longer
doesn't have the down side that it used to.

> 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
>
> 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)

Mime
View raw message