[
https://issues.apache.org/jira/browse/IGNITE-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280539#comment-16280539
]
Alexei Scherbakov commented on IGNITE-7083:
-------------------------------------------
Hi [~sunnychanclsa]
Thanks for investigation.
The optimization won't give you much, because CachePartitionFullCountersMap
will contain zeroes only if no cache updates were done.
Apache Ignite community is aware of heap consumption issues by CPFCM and other
cache/exchange related data structures if number of caches/partitions is quite
large.
I'm going soon to create a bunch of tickets related to several optimization
that needs to be done on the subject.
> Reduce memory usage of CachePartitionFullCountersMap
> ----------------------------------------------------
>
> Key: IGNITE-7083
> URL: https://issues.apache.org/jira/browse/IGNITE-7083
> Project: Ignite
> Issue Type: Improvement
> Components: cache
> Affects Versions: 2.3
> Environment: Any
> Reporter: Sunny Chan
> Assignee: Alexey Goncharuk
> Fix For: 2.4
>
>
> The Cache Partition Exchange Manager kept a copy of the already completed
> exchange. However, we have found that it uses a significant amount of memory.
> Upon further investigation using heap dump we have found that a large amount
> of memory is used by the CachePartitionFullCountersMap. We have also observed
> in most cases, these maps contains only 0s.
> Therefore I propose an optimization for this: Initially the long arrays to
> store initial update counter and update counter in the CPFCM will be null,
> and when you get the value and see these tables are null then we will return
> 0 for the counter. We only allocate the long arrays when there is any
> non-zero updates to the the map.
> In our tests, the amount of heap used by GridCachePartitionExchangeManager
> was around 70MB (67 copies of these CPFCM), after we apply the optimization
> it drops to around 9MB.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
