[
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)
