ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Scherbakov (Jira)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-7083) Reduce memory usage of CachePartitionFullCountersMap
Date Thu, 03 Oct 2019 13:59:00 GMT

    [ https://issues.apache.org/jira/browse/IGNITE-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16943621#comment-16943621

Alexei Scherbakov commented on IGNITE-7083:


Looks like the issue is no longer actual because we have cache groups for a long time now.
CachePartitionFullCountersMap size expected to be reduced twice after IGNITE-11794.
Closing the issue.

> 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
>            Priority: Major
>             Fix For: 2.9
> 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

View raw message