[
https://issues.apache.org/jira/browse/HBASE-14460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14904974#comment-14904974
]
stack commented on HBASE-14460:
-------------------------------
bq. And hold the locks per row until after the sync.
Folks did a load of work to avoid our having to wait on sync while the row lock
was held...
But that was another time. WAL has changed a bunch since then.
We'll have to check perf.... make sure no significant degradation... Ideally,
our group commit will absorb any extra friction doing an append ... and we
won't back up to fill all handlers.
If we could lock across an append and perf was ok, then we could refactor the
current crazyness of append, then memstore, then sync...
HBASE-12751 went into trunk yesterday. Trying to backport it to branch-1 now.
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?
> [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
(v6.3.4#6332)
