hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-15158) Change order in which we do write pipeline operations; do all under row locks!
Date Mon, 08 Feb 2016 06:45:40 GMT

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

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

I compared before and after using IncrementPerformanceTest

h2. UNPATCHED
{code}
      2016-02-07 22:41:51,312 INFO  [main] hbase.IncrementPerformanceTest: 75th=4097315.0,
95th=6597782.0, 99th=7659555.0

 Performance counter stats for './hbase/bin/hbase --config /home/stack/conf_hbase org.apache.hadoop.hbase.IncrementPerformanceTest':

     157419.795645 task-clock                #    2.113 CPUs utilized
         2,582,885 context-switches          #    0.016 M/sec
           291,467 cpu-migrations            #    0.002 M/sec
           132,919 page-faults               #    0.844 K/sec
   195,230,392,765 cycles                    #    1.240 GHz
   <not supported> stalled-cycles-frontend
   <not supported> stalled-cycles-backend
   109,736,031,635 instructions              #    0.56  insns per cycle
    20,548,309,471 branches                  #  130.532 M/sec
       679,777,380 branch-misses             #    3.31% of all branches

      74.495320701 seconds time elapsed
{code}

h2. PATCHED
{code}
2016-02-07 22:30:32,252 INFO  [main] hbase.IncrementPerformanceTest: 75th=2979505.0, 95th=4664926.0,
99th=5463442.0

 Performance counter stats for './hbase/bin/hbase --config /home/stack/conf_hbase org.apache.hadoop.hbase.IncrementPerformanceTest':

     157569.138177 task-clock                #    2.784 CPUs utilized
         2,588,954 context-switches          #    0.016 M/sec
           345,208 cpu-migrations            #    0.002 M/sec
           148,887 page-faults               #    0.945 K/sec
   200,320,654,874 cycles                    #    1.271 GHz
   <not supported> stalled-cycles-frontend
   <not supported> stalled-cycles-backend
   118,641,158,871 instructions              #    0.59  insns per cycle
    22,289,641,614 branches                  #  141.459 M/sec
       610,221,957 branch-misses             #    2.74% of all branches

      56.603756542 seconds time elapsed

{code}

Its 80 threads each doing 10k increments. Seems like patched does better.

> 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,
measurements.tgz
>
>
> 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)

Mime
View raw message