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

stack commented on HBASE-15158:
-------------------------------

Thanks [~eclark]

Ran a few ITBLLs ... last one was 1B... and passed.

Doing one last perf compare with YCSB just to make sure this last patch does 
nothing unexpected. Bit blind since opentsdb does not work w/ master branch 
(need to update asynchbase to not expect table stuff in zk -- I think)

> Change order in which we do write pipeline operations; do all under row locks!
> ------------------------------------------------------------------------------
>
>                 Key: HBASE-15158
>                 URL: https://issues.apache.org/jira/browse/HBASE-15158
>             Project: HBase
>          Issue Type: Sub-task
>          Components: Performance
>            Reporter: stack
>            Assignee: stack
>             Fix For: 2.0.0
>
>         Attachments: 15158.patch, 15158v2.patch, 15158v3.patch, 
> 15158v4.patch, 15158v4.patch
>
>
> Change how we do our write pipeline. I want to do all write pipeline ops 
> under row lock so I lean on this fact fixing performance regression in 
> check-and-set type operations like increment, append, and checkAnd* (see 
> sibling issue HBASE-15082).
> To be specific, we write like this now:
> {code}
> # take rowlock
> # start mvcc
> # append to WAL
> # add to memstore
> # let go of rowlock
> # sync WAL
> # in case of error: rollback memstore
> {code}
> Instead, write like this:
> {code}
> # take rowlock
> # start mvcc
> # append to WAL
> # sync WAL
> # add to memstore
> # let go of rowlock
> ... no need to do rollback.
> {code}
> The old ordering was put in place because it got better performance in a time 
> when WAL was different and before row locks were read/write (HBASE-12751).
> Testing in branch-1 shows that a reordering and skipping mvcc waits gets us 
> back to the performance we had before we unified mvcc and sequenceid 
> (HBASE-8763). Tests in HBASE-15046 show that at the macro level using our 
> usual perf tools, reordering pipeline seems to cause no slowdown (see 
> HBASE-15046). A rough compare of increments with reordered write pipeline 
> seems to have us getting back a bunch of our performance (see tail of 
> https://issues.apache.org/jira/browse/HBASE-15082?focusedCommentId=15111703&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15111703
>  and subsequent comment).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to