[
https://issues.apache.org/jira/browse/OMID-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16819253#comment-16819253
]
Lars Hofhansl edited comment on OMID-145 at 4/16/19 6:03 PM:
-------------------------------------------------------------
Won't this suffer in perf (like OMID-129) when the commit ts is not yet present
in the commit table?
Edit: Never mind. I missed this line:
{code}
commitCache.put(cell.getTimestamp(), Optional.<CommitTimestamp>absent());
{code}
was (Author: lhofhansl):
Won't this suffer in perf (like OMID-129) when the commit ts is not yet present
in the commit table?
> 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)
