Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Date: Mon, 8 Feb 2016 18:47:40 +0000 (UTC)
From: "stack (JIRA)" <jira@apache.org>
To: dev@hbase.apache.org
Message-ID: <JIRA.12895334.1442898506000.331093.1454957260518@Atlassian.JIRA>
In-Reply-To: <JIRA.12895334.1442898506000@Atlassian.JIRA>
References: <JIRA.12895334.1442898506000@Atlassian.JIRA>
 <JIRA.12895334.1442898506554@arcas>
Subject: [jira] [Resolved] (HBASE-14460) [Perf Regression] Merge of MVCC and
 SequenceId (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.atlassi=
an.jira.plugin.system.issuetabpanels:all-tabpanel ]

stack resolved HBASE-14460.
---------------------------
       Resolution: Fixed
    Fix Version/s: 1.0.4
                   1.1.4
                   1.2.1
                   1.3.0
                   2.0.0
     Release Note:=20
This release note tries to tell the general story. Dive into sub-tasks for =
more specific release noting.

Increments, appends, checkAnd* have been slow since hbase-.1.0.0. The unifi=
cation of mvcc and sequence id done by HBASE-8763 was responsible.

A =E2=80=98fast-path=E2=80=99 workaround was added by HBASE-15031 =E2=80=9C=
Fix merge of MVCC and SequenceID performance regression in branch-1.0 for I=
ncrements=E2=80=9D. It became available in 1.0.3 and 1.1.3. To enable the f=
ast path, set "hbase.increment.fast.but.narrow.consistency" and then rollin=
g restart. The workaround was for increments only (appends, checkAndPut, et=
c., were not addressed. See HBASE-15031 release note for more detail).

Subsequently, the regression was properly identified and fixed in HBASE-152=
13 and the fix applied to branch-1.0 and branch-1.1. As it happens, hbase-1=
.2.0 does not suffer from the performance regression (though the thought wa=
s that it did -- and so it got the fast-path patch too via HBASE-15092) nor=
 does the master branch. HBASE-15213 identified that HBASE-12751 (as a side=
 effect) had cured the regression.

hbase-1.0.4 (if it is ever released -- 1.0 has been end-of-lifed) and hbase=
-1.1.4 will have the HBASE-15213 fix.  If you are suffering from the increm=
ent regression and you are on 1.0.3 or 1.1.3, you can enable the work aroun=
d to get back your increment performance but you should upgrade.

  was:Regression addressed narrowly on branch-1 (1.0.3+, 1.1.3+, and 1.2.0)=
. You need to set a  "hbase.increment.fast.but.narrow.consistency" and roll=
ing restart to enable a 'fast path' for increments only (appends, checkAndP=
ut, etc., are not address in branch-1). See the sub-task release notes for =
more detail. On master branch, a more substantial change is done changing w=
rite path so all check-and-put type operations -- i.e. increment, append, c=
heckAnd*, etc. -- have the regression addressed.


> [Perf Regression] Merge of MVCC and SequenceId (HBASE-8763) slowed Increm=
ents, 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
>             Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4, 1.0.4
>
>         Attachments: 0.94.test.patch, 0.98.test.patch, 1.0.80.flamegraph-=
7932.svg, 14460.txt, 14460.v0.branch-1.0.patch, 98.80.flamegraph-11428.svg,=
 HBASE-14460-discussion.patch, client.test.patch, flamegraph-13120.svg.mast=
er.singlecell.svg, flamegraph-26636.094.100.svg, flamegraph-28066.098.singl=
ecell.svg, flamegraph-28767.098.100.svg, flamegraph-31647.master.100.svg, f=
lamegraph-9466.094.singlecell.svg, hack.flamegraph-16593.svg, hack.uncommit=
ted.patch, m.test.patch, region_lock.png, testincrement.094.patch, testincr=
ement.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)