Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 5 Jan 2016 09:46:39 +0000 (UTC)
From: "Heng Chen (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12924586.1451349736000.19581.1451987199972@Atlassian.JIRA>
In-Reply-To: <JIRA.12924586.1451349736000@Atlassian.JIRA>
References: <JIRA.12924586.1451349736000@Atlassian.JIRA>
 <JIRA.12924586.1451349736087@arcas>
Subject: [jira] [Comment Edited] (HBASE-15046) Perf test doing all mutation
 steps under row lock
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HBASE-15046?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D150=
82733#comment-15082733 ]=20

Heng Chen edited comment on HBASE-15046 at 1/5/16 9:45 AM:
-----------------------------------------------------------

{quote}
not sure why reads would be faster but 95/5 seems a tad slower (in middle i=
s an aborted run =E2=80=93 the patch seems to bring on mvcc lockup... need =
to look into that).
{quote}
Did all read requests happen on the latest inserted rows? what's the reques=
tdistribution param, uniform, zipfian or latest ?


was (Author: chenheng):
{quote}
not sure why reads would be faster but 95/5 seems a tad slower (in middle i=
s an aborted run =E2=80=93 the patch seems to bring on mvcc lockup... need =
to look into that).
{quote}
Is all read requests happens on latest inserted rows? what's the requestdis=
tribution param, uniform, zipfian or latest ?

> 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
>            Assignee: stack
>         Attachments: 1.2.svg, 1.2.v2.svg, 50threads_ycsb.png, all_under_l=
ock.patch, all_under_lock.svg, call_times_0-1_and_1-3_ycsb.png, latencies.p=
ng, writes.png
>
>
> This issue is about perf testing a redo of the write pipeline so that rat=
her 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 do=
ne in a sibling subtask.
> Other benefits are that the current write pipeline is copy/pasted in a fe=
w places  -- in append, increment and checkand* -- and a refactor will allo=
w us to fix this duplication.


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