[ https://issues.apache.org/jira/browse/OMID-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16818659#comment-16818659 ]
Lars Hofhansl commented on OMID-145: ------------------------------------ So all transactions that are new than the new low-watermark will be aborted, right? And so I should roughly size the conflict map to the maximum expected number of rows in flight? Thanks again for explaining. That also explains why it so big by default, I was wondering about that. > 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)