[
https://issues.apache.org/jira/browse/CASSANDRA-16201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17222647#comment-17222647
]
Yifan Cai commented on CASSANDRA-16201:
---------------------------------------
Just went over the 40 patch. It looks good to me overall. Listing the
nits/feedbacks below.
* {{BatchStatement#updatedRows}} is no longer used. Please remove it
* Maybe change the single table update detection from
"{{!stmt.metadata.equals(metadata)"}} to "{{metadata != null &&
!stmt.metadata.equals(metadata)"}} in order to avoid the unnecessary
comparison, although the cost of comparing with null should be negligible.
* Please update the comments for {{perPartitionKeyCounts}} in both
{{BatchUpdatesCollector}} and {{SingleTableUpdatesCollector}}, since the count
is no longer an estimation.
* Maybe remove the comment in {{ModificationStatement#requiresRead}} since the
original implementation is removed.
* The new implementation of {{BatchUpdatesCollector#getMutationBuilder}} is
essentially the same as the previous {{computeIfAbsent}} except calling
dk.getKey() twice. In the case of NativeDecoratedKey, the new implementation is
slightly more expensive.
* Similarly, the new implementation of {{BatchUpdatesCollector#keyspaceMap}}
is equivalent to the previous {{computeIfAbsent}} except the supplied map being
different. I think the {{computeIfAbsent}} approach looks more elegant. But it
is just a style thing.
> Reduce amount of allocations during batch statement execution
> -------------------------------------------------------------
>
> Key: CASSANDRA-16201
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16201
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
> Reporter: Thomas Steinmaurer
> Assignee: Marcus Eriksson
> Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png
>
>
> In a Cas 2.1 / 3.0 / 3.11 / 4.0b2 comparison test with the same load profile,
> we see 4.0b2 going OOM from time to time. According to a heap dump, we have
> multiple NTR threads in a 3-digit MB range.
> This is likely related to object array pre-allocations at the size of
> {{BatchUpdatesCollector.updatedRows}} per {{BTree}} although there is always
> only 1 {{BTreeRow}} in the {{BTree}}.
> !screenshot-1.png|width=100%!
> So it seems we have many, many 20K elemnts pre-allocated object arrays
> resulting in a shallow heap of 80K each, although there is only one element
> in the array.
> This sort of pre-allocation is causing a lot of memory pressure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
