hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jingcheng Du (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-14460) [Perf Regression] Merge of MVCC and SequenceId (HBASE-HBASE-8763) slowed Increments, CheckAndPuts, batch operations
Date Wed, 16 Dec 2015 02:51:46 GMT

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

Mime
View raw message