[
https://issues.apache.org/jira/browse/HBASE-14460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15059596#comment-15059596
]
stack commented on HBASE-14460:
-------------------------------
First, now that I understand, I like your idea. We should do it. Lets work on
your patch. Will give some more feedback tomorrow (need to consider your
response on rowOperationContexts... try it).
We need more speed up though. Looks like your change could get us from 10x to 3
or 4x what it used be which is close. Trying to figure how to get it closer in.
One unformed thought is a means of exploiting the context you've uncovered and
somehow using it to do aggregations of counts that are stuck waiting on a
rowlock and or mvcc; i.e. if a handler arrives and we are waiting on mvcc
and/or row lock, add our increment elsewhere, park until the increment has been
applied and then skip out on doing the increment path ourselves. Probably not
possible without compounding complexity and synchronization points so could
slow more than it speeds us up.
bq. ...but this cell is not yet visible? Is it ok?
We are out past the sync of the write at this point and while the increment is
not yet generally available, as soon as someone needs to read it, they'll be
forced to wait till the mvcc catches up. Given this, I think we might be able
to get away with this if we narrow the options around when Increments become
'visiible'.
We need another 2x to get us within shouting distance of how it used all work
in 0.98/0.94 timeframe. Some folks are late upgrading and they've built their
apps based on a fast Increment. They are kinda hosed w/o it.
> [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,
> 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)
