[
https://issues.apache.org/jira/browse/HBASE-14460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058443#comment-15058443
]
stack commented on HBASE-14460:
-------------------------------
[[email protected]] Thanks. The explanation helps.
I think I understand now where the speedup comes from now (pardon my being so
dense).
Here is basic Increment flow:
1. get row lock
2. wait on ALL outstanding transactions to complete so can do a read and know
it will have the latest data
3. do get, then append...
4. call sync
4. let go of lock
5. wait on sync to complete
6. wait on read point to catch up with the write for the above added increment
so for sure the client and read what they wrote (this latter is probably not
needed given we start an increment by waiting on read to catch up with write --
TODO).
Your speed up comes of the following:
1. get row lock AND look to see if we have any write context for this row
already
2. if we don't have an existing write op on this row, proceed as per above but
if we do find an existing context....then all we have to do is wait on the
write number for this existing transaction to clean, NOT for all existing
writes to clear...
3. as per above, etc.
Do I have it right? If so, sweet (again)... and, yeah, could we skip out on the
wait in step #6 above in the first list.
Now to the patch.... some more questions (smile).
In begin, we do this:
{code}
long lastWriterNumber = -1;
for (RowOperationContext context : rowOperationContexts) {
if (context != null) {
if (lastWriterNumber < context.getNextWriteNumber()) {
lastWriterNumber = context.getNextWriteNumber();
}
context.setNextWriteNumber(nextWriteNumber);
}
}
{code}
Is the intent that all passed in rowOperationContexts all get the highest found
nextWrite Number? If so, this loop does not seem like it will achieve this (if
rowOperationContexts have write numbers 1 to 3 say, then after the loop is
done, all rowOperationContexts will have the same 1 to 3 write numbers... but
if write numbers are 3 to 1, then they will have a write number of 3......)
Let me look more... will be back.
> [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, 14460.txt,
> HBASE-14460-discussion.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)
