[
https://issues.apache.org/jira/browse/OMID-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817998#comment-16817998
]
Ohad Shacham commented on OMID-145:
-----------------------------------
What is the size of the conflict table you are using? I understood that you
reduced the size in order to get a better GC. However, a better GC means
increasing the low water mark more frequently that might increase the abort
ratio.
The async post commit can be the reason, as you said, however, you should make
sure that the size of the conflict table is not too small and cause to many
aborts.
[~lhofhansl], is it OK with you that we ([~yonigo] :)) will add the caches in
here and then we will start the 1.0.1 release vote? We would like to make an
Omid release for the coming Phoenix release. Have you noticed any other urgent
issues?
> 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
> 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)
