[
https://issues.apache.org/jira/browse/HBASE-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13265414#comment-13265414
]
Todd Lipcon commented on HBASE-5897:
------------------------------------
bq. So calling doMiniBatchPut multiple times on behalf of the same Put
operation should be happening relatively rarely.
True, unless there's a lot of contention on some rows. In the test I was doing,
I was slamming a fairly small number of rows with puts, so there was a lot of
this "back-off" behavior.
I bet we could improve performance by making it continue past a failed lock
acquisition and acquire as many as possible, while pushing those it missed back
onto the end of the list. Right now, as soon as it fails any lock acquisition,
it stops the batch there (so we always do contiguous ranges of ops instead of
arbitrary sets)
> prePut coprocessor hook causing substantial CPU usage
> -----------------------------------------------------
>
> Key: HBASE-5897
> URL: https://issues.apache.org/jira/browse/HBASE-5897
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.92.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Priority: Critical
> Fix For: 0.92.2, 0.94.0, 0.96.0
>
> Attachments: 5897-simple.txt, hbase-5897.txt
>
>
> I was running an insert workload against trunk under oprofile and saw that a
> significant portion of CPU usage was going to calling the "prePut"
> coprocessor hook inside doMiniBatchPut, even though I don't have any
> coprocessors installed. I ran a million-row insert and collected CPU time
> spent in the RS after commenting out the preput hook, and found CPU usage
> reduced by 33%.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
