[
https://issues.apache.org/jira/browse/OMID-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16818279#comment-16818279
]
Ohad Shacham commented on OMID-145:
-----------------------------------
Any transaction t over 100k will force all current inflight transaction to
fail, however, t will pass.
The reason is that after t's conflict analysis will pass it will get a commit
timestamp c, which is the latest one. Then its 200 keys will be added to the
conflict table one by one with commit time stamp c. Once one of t's key's will
be removed from the conflict table the low water mark will be set to c. t will
still pass since the decision for its commit was already made, however, all the
inflight transactions will be aborted since their start timestamps are smaller
than c.
Thanks for finding all these bugs, it is great!
> 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
>
>
> 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)
