[
https://issues.apache.org/jira/browse/OMID-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16819577#comment-16819577
]
Lars Hofhansl edited comment on OMID-145 at 4/16/19 11:20 PM:
--------------------------------------------------------------
Oh one more question. Is it possible that a transaction becomes committed
during the compaction, and would a stale cache pose a problem in that case?
(compaction can be quite a long running operation)
(I realize we cannot have it both ways, just asking about the implications. :) )
was (Author: lhofhansl):
Oh one more question. Is it possible that the transaction becomes committed
during the compaction, and would a stale cache pose a problem in that case?
(compaction can be quite a long running operation)
> 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)
