[
https://issues.apache.org/jira/browse/OMID-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16819796#comment-16819796
]
Ohad Shacham commented on OMID-145:
-----------------------------------
Good question, the compaction checks only whether transactions that started
below the low water mark are committed. The data of the ones that started after
the low water mark are kept and we don't care whether these are committed or
not.
Basically, transactions that started below the low water mark are aborted so
they should not influence the cache. There was a little race that we thought
about and opened OMID-146 because of it. After this fix, transaction won't be
able to commit if the low water mark is after its begin timestamp.
> 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)
