Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 23 Sep 2015 18:22:04 +0000 (UTC)
From: "stack (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12895334.1442898506000.52593.1443032524984@Atlassian.JIRA>
In-Reply-To: <JIRA.12895334.1442898506000@Atlassian.JIRA>
References: <JIRA.12895334.1442898506000@Atlassian.JIRA>
 <JIRA.12895334.1442898506554@arcas>
Subject: [jira] [Commented] (HBASE-14460) [Perf Regression] Merge of MVCC
 and SequenceId (HBASE-HBASE-8763) slowed Increments, CheckAndPuts, batch
 operations
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HBASE-14460?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D149=
04974#comment-14904974 ]=20

stack commented on HBASE-14460:
-------------------------------

bq. And hold the locks per row until after the sync.=20

Folks did a load of work to avoid our having to wait on sync while the row =
lock was held...=20

But that was another time. WAL has changed a bunch since then.

We'll have to check perf.... make sure no significant degradation... Ideall=
y, our group commit will absorb any extra friction doing an append ... and =
we won't back up to fill all handlers.

If we could lock across an append and perf was ok, then we could refactor t=
he current crazyness of append, then memstore, then sync...

HBASE-12751 went into trunk yesterday. Trying to backport it to branch-1 no=
w.

Don't we still do an mvcc transaction inside the row lock... we'll wait til=
l mvcc catches up after we take the row lock... then we complete it and on =
the end ... So, before releasing the row lock, we'd stamp the mvcc as curre=
nt writes sequenceid... unless it had already gone beyond us?

> [Perf Regression] Merge of MVCC and SequenceId (HBASE-HBASE-8763) slowed =
Increments, CheckAndPuts, batch operations
> -------------------------------------------------------------------------=
------------------------------------------
>
>                 Key: HBASE-14460
>                 URL: https://issues.apache.org/jira/browse/HBASE-14460
>             Project: HBase
>          Issue Type: Bug
>          Components: Performance
>            Reporter: stack
>            Assignee: stack
>            Priority: Critical
>         Attachments: 14460.txt, region_lock.png
>
>
> As reported by =E9=88=B4=E6=9C=A8=E4=BF=8A=E8=A3=95 up on the mailing lis=
t -- see "Performance degradation between CDH5.3.1(HBase0.98.6) and CDH5.4.=
5(HBase1.0.0)" -- our unification of sequenceid and MVCC slows Increments (=
and other ops) as the mvcc needs to 'catch up' to our current point before =
we can read the last Increment value that we need to update.
> We can say that our Increment is just done wrong, we should just be writi=
ng Increments and summing on read, but checkAndPut as well as batching oper=
ations have the same issue. Fix.


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