[
https://issues.apache.org/jira/browse/OMID-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16818893#comment-16818893
]
Ohad Shacham commented on OMID-145:
-----------------------------------
A transaction is aborted if its start timestamp is smaller than the low water
mark. The reason is that entries that were committed after the transaction
started were removed from the conflict table and we can accidentally think that
the transaction can safely commit even though it had a conflict with one of the
entries that were removed.
So all transactions that started before the low water mark are aborted.
> And so I should roughly size the conflict map to the maximum expected number
>of rows in flight?
Something like this :), the conflict table is a bounded hash of bins so you
don't have any guarantees... but something like this can be good.
> High CPU usage during compactions.
> ----------------------------------
>
> Key: OMID-145
> URL: https://issues.apache.org/jira/browse/OMID-145
> Project: Apache Omid
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Priority: Major
> Fix For: 1.0.1
>
> Attachments: compactionTiming.png, omid-145.patch
>
>
> See attached image, almost all (96%!!) of the compaction time is spent in
> org.apache.hadoop.hbase.regionserver.CompactorScanner.queryCommitTimestamp()
> I guess that's when the shadowCell is not yet present.
> We already have problems with long compactions in HBase, prolonging these
> potentially by 25x (all the rest of the compaction logic took only 4% of the
> time), would not be a pleasant idea.
> Perhaps we can do that same caching we do with the commit cache during
> regular scanning...?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
