[
https://issues.apache.org/jira/browse/KUDU-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16850574#comment-16850574
]
Xu Yao commented on KUDU-749:
-----------------------------
This problem also exists in our production environment. The reason for this
problem is that when updating the key, it is necessary to find out which RowSet
the Key is in, and this process needs to determine whether the Key has been
deleted in the RowSet. But in our production scenario, there is no delete row
operation. So we added a configuration item to the table that supports delete
row. If the table does not support delete row, this check will be ignored.
> Improve performance for zipfian update
> --------------------------------------
>
> Key: KUDU-749
> URL: https://issues.apache.org/jira/browse/KUDU-749
> Project: Kudu
> Issue Type: Improvement
> Components: perf, tablet
> Affects Versions: Private Beta
> Reporter: Todd Lipcon
> Priority: Major
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> A zipfian 50/50 update/read workload on YCSB gets slower and slower until
> it's pretty intolerable (random reads taking 100+ms of CPU). It seems like
> all the CPU is spent in DMSIterator::PrepareBatch. We're probably doing
> something dumb here - let's look for some low hanging fruit to fix this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
