Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 16 Dec 2015 02:51:46 +0000 (UTC)
From: "Jingcheng Du (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12895334.1442898506000.35039.1450234306932@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=3D150=
59394#comment-15059394 ]=20

Jingcheng Du commented on HBASE-14460:
--------------------------------------

Thanks for comments!
You are right, [~stack].
In the current implementation, region caches a row lock context in lockedRo=
ws. In the patch I wrap the lock into a RowContext, and add one more RowOpe=
rationContext in RowContext, consequently the lockedRows cache the RowConte=
xt instead.

bq. could we skip out on the wait in step #6 above in the first list.
If we skip the waiting, does it mean a user gets the response, but this cel=
l is not yet visible? Is it ok?

bq. Is the intent that all passed in rowOperationContexts all get the highe=
st found nextWrite Number? If so, this loop does not seem like it will achi=
eve this (if rowOperationContexts have write numbers 1 to 3 say, then after=
 the loop is done, all rowOperationContexts will have the same 1 to 3 write=
 numbers... but if write numbers are 3 to 1, then they will have a write nu=
mber of 3......)
Yes, this is done on purpose. It tries to find the biggest lastWriteNumber =
(which means this current WriteEntry for this batch has to wait for the big=
gest lastWriteNumber is visible before it can continue in waitForRead). For=
 each RowOperationContext, it has the same nextWriteNumber (by using contex=
t.setNextWriteNumber(nextWriteNumber)). Maybe the names are similar, and ge=
t mixed up for reading?
In the given example, if RowOperationContext has write number 1 to 3, after=
 the loop is done, the lastWritenNumber for the WriteEntry is 3, and the ne=
xtWriteNumber in each RowOperationContext has a new number (maybe 4).

> [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: 0.94.test.patch, 0.98.test.patch, 1.0.80.flamegraph-=
7932.svg, 14460.txt, 98.80.flamegraph-11428.svg, HBASE-14460-discussion.pat=
ch, client.test.patch, flamegraph-13120.svg.master.singlecell.svg, flamegra=
ph-26636.094.100.svg, flamegraph-28066.098.singlecell.svg, flamegraph-28767=
.098.100.svg, flamegraph-31647.master.100.svg, flamegraph-9466.094.singlece=
ll.svg, m.test.patch, region_lock.png, testincrement.094.patch, testincreme=
nt.098.patch, testincrement.master.patch
>
>
> 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)