[
https://issues.apache.org/jira/browse/HBASE-14460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15059394#comment-15059394
]
Jingcheng Du commented on HBASE-14460:
--------------------------------------
Thanks for comments!
You are right, [~stack].
In the current implementation, region caches a row lock context in lockedRows.
In the patch I wrap the lock into a RowContext, and add one more
RowOperationContext in RowContext, consequently the lockedRows cache the
RowContext instead.
bq. could we skip out on the wait in step #6 above in the first list.
If we skip the waiting, does it mean a user gets the response, but this cell is
not yet visible? Is it ok?
bq. 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......)
Yes, this is done on purpose. It tries to find the biggest lastWriteNumber
(which means this current WriteEntry for this batch has to wait for the biggest
lastWriteNumber is visible before it can continue in waitForRead). For each
RowOperationContext, it has the same nextWriteNumber (by using
context.setNextWriteNumber(nextWriteNumber)). Maybe the names are similar, and
get mixed up for reading?
In the given example, if RowOperationContext has write number 1 to 3, after the
loop is done, the lastWritenNumber for the WriteEntry is 3, and the
nextWriteNumber in each RowOperationContext has a new number (maybe 4).
> [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)
