hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Elliott Clark (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, 23 Sep 2015 18:46:04 GMT

    [ https://issues.apache.org/jira/browse/HBASE-14460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14905021#comment-14905021

Elliott Clark commented on HBASE-14460:

bq.Folks did a load of work to avoid our having to wait on sync while the row lock was held...
Yeah my thought only works after locks are reader/writer.

bq.Don't we still do an mvcc transaction inside the row lock... we'll wait till mvcc catches
up after we take the row lock... then we complete it and on the end ... So, before releasing
the row lock, we'd stamp the mvcc as current writes sequenceid... unless it had already gone
beyond us?

Yeah so that will slow us down in situations where we're highly contented on the same row.
However if there are lots of rows having a check and mutate operation run on then there is
no need to wait of other mvcc transactions to complete. Currently even if there is no in flight
transaction for the row you're trying to read modify write, the server waits for all transactions
to complete. Holding the lock just gets us up to a point where the server will only wait on
transactions for the row that is in question.

> [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: 14460.txt, region_lock.png
> 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

View raw message