[
https://issues.apache.org/jira/browse/HBASE-14460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15061691#comment-15061691
]
Elliott Clark commented on HBASE-14460:
---------------------------------------
bq. A larger locked code block impacts the put operations too?
Not really. In the latest branches we've made the row locks reader/writer. That
means that there can be any number of puts for the same row going on. So
holding the row lock until after the mvcc has been fully applied shouldn't
change the normal put flow. It also won't change the increment flow.
The only place it will matter is when there are increments and puts going to
the same row from different clients. That's always going to be the case since
we only have per row level locks.
> [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)
