[
https://issues.apache.org/jira/browse/OMID-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16818132#comment-16818132
]
Lars Hofhansl commented on OMID-145:
------------------------------------
Ah yes. That too. I set it to 100.000. Good catch! Does that mean that any
transaction over 100k rows would automatically fail?
Interestingly, I did not see any aborts. Even though in the end I UPSERTed 200k
rows in one transaction.
Thanks for looking at all these issues. I'm not aware of any other pressing
issues. And in general I'm a fan of frequent, small releases anyway. If you put
of a 1.0.1 I will do my (non-binding, I'm not a PMC member) vote.
> 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)
