[jira] [Updated] (HBASE-15158) Change order in which we do write pipeline operations; do all under row locks!

["stack (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HBASE-15158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

stack updated HBASE-15158:
--------------------------
    Attachment: 15158v3.patch

Just the changes in HRegion now (with a few little ripples).  Here is changelog:

{code}
   4 Subject: [PATCH] HBASE-15158 Change order in which we do write pipeline
   5  operations; do all under row locks!
   6
   7 M hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/DefaultMemStore.java
   8   White space
   9
  10 M hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
  11   Removed timeout for latch that has break waiting on sequenceid
  12   assignment.
  13
  14   In flush, add doc and formatting. Be sure to complete mvcc on exit.
  15   Formatting is in part because complaint that method is too long so
  16   broke out stuff like fat loggint to own methods.
  17
  18   Undid an extraneous mvcc transaction that wrapped flush. This changed
  19   indent. Also moved call to sync out to WALUtil call.
  20
  21   Added logFatLineOnFlush and doAbortFlushWal, and
  22   doSyncOfUnflushedWALChange methods to make the flush method smaller.
  23
  24   Changed getNextSequenceId so it no longer adds fake edit to WAL only
  25   to have it discarded.. Since sequenceid font is inside mvcc, just get
  26   the next.
  27
  28   Renamed BatchOperationInProgress to BatchOperation and renamed
  29   doMiniBatchMutation as doMiniBatchMutate so it goes with its caller,
  30   batchMutate.
  31
  32   Some refactor of doMiniBatchMutate to make slightly smaller adding
  33   doc, breaking out methods, and removing redundancies but not enough. Needs rewrite.
  34
  35   Did the new common treatment of append/sync/mvcc careful on the end
  36   to call complete on mvcc before skipping out. This pattern is done
  37   in all wal writing in this patch. Also includes the flip in order
  38   where we do mvcc, append, sync, update memstore, stop mvcc instead
  39   of what we had previous which was mvcc, append, memstore, sync, mvcc.
  40
  41   Redo increment and append. They were 95% the same thing.
  42   Both now call doDelta.
  43
  44   Renamed doGet as get.
  45
  46   Removed main and a few DLR methods no longer used.
  47
  48 M hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSWALEntry.java
  49   Less dancing.
  50
  51 M hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLogKey.java
  52   Use methods because I want to clean up all the variants of sequenceid
  53   in here.
  54
  55 M hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/WALUtil.java
  56   Cleanup and do complete append, sync and mvcc in here rather than in
  57   caller. That is ok because methods in here are adding to WAL only, not
  58   to mem.
  59
  60 M hbase-server/src/main/java/org/apache/hadoop/hbase/wal/WALKey.java
  61   Doc. Cleanup.
  62
  63 M hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegion.java
  64   Test changes with above changes. Used to expect 'true' though we were
  65   asked to skip the WAL because our trick of doing fake empty append was
  66   tripping the coprocessor append flag.
{code}

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