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-14460) [Perf Regression] Merge of MVCC and SequenceId (HBASE-HBASE-8763) slowed Increments, CheckAndPuts, batch operations
Date Thu, 17 Dec 2015 17:28:47 GMT

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

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

[~eclark] Are you talking about a Put and Increment going against same Cell in your scenario;
if so, yes, they will mess each other up.

This issue is about fixing Increment in branch-1 first. The patch will come with a constraint:
i.e. you can only use the Increment codepath making Increments. This is a change in behavior
but what is there currently is broke. I could add a switch that turned this behavior on/off
but that seems OTTT.

Please correct me if I am misunderstanding you.

Yeah, will rejigger the write path for all Mutations to get us the straight run of synced-append-to-WAL
and then memstore so Put and Increment can be intermixed but that will be a subsequent patch
after I've done some tests to see perf difference.

bq. Getting this into a branch before the reader/writer re-write is going to be painful.

Sorry, what do you mean here Sir?

On [~ram_krish] scenario, I think it fine they both fail (the Put is a 'normal' failure that
this patch has nothing to do with... and would the checkAndPut proceed at all if a bad WAL
caused the first Put fail? Won't the Put from checkAndPut also fail since it is coming in
 later).

Ram's scenario does give me pause though and makes me think that on branch 1, we should only
do Increments with this treatment. Increments are usually higher-rate than checkAnd*; a slow
checkAnd* is probably tolerable in branch-1. Can fix in later branches.

On the use of READ_UNCOMMITTED, its use is narrow, confined to the Increment case; we are
only reading Increment cells. We can't do 1., in branch-1 or at least not in versions up to
hbase-1.2. If we do 2., we are slow again.

Great feedback lads. Patch should be for Increments only with big warning that bets are off
if you mix Put and Increment . Hows that sound?





> [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.patch, client.test.patch, flamegraph-13120.svg.master.singlecell.svg,
flamegraph-26636.094.100.svg, flamegraph-28066.098.singlecell.svg, flamegraph-28767.098.100.svg,
flamegraph-31647.master.100.svg, flamegraph-9466.094.singlecell.svg, hack.flamegraph-16593.svg,
hack.uncommitted.patch, m.test.patch, region_lock.png, testincrement.094.patch, testincrement.098.patch,
testincrement.master.patch
>
>
> As reported by 鈴木俊裕 up on the mailing list -- 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 writing Increments
and summing on read, but checkAndPut as well as batching operations have the same issue. Fix.



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

Mime
View raw message