Hi Tolga,
GridDhtPartitionTopologyImpl is created per cache. If you destroy a
cache this object should be GCed. However you should use cache.destroy()
for that.
Please also make sure that you make "live set" heap dumps only. Try to
perform GC explicitly before making the dump because a collector may
clean dead objects much later depending on its heuristics.
--
Denis
On 4/7/2016 8:27 AM, Tolga Kavukcu wrote:
Hi Denis,
Thanks for the response. I will try
IGNITE_ATOMIC_CACHE_DELETE_HISTORY_SIZE parameter. The screnshots
taken from eclipse memory analyser which opens and analyses heap dump.
I understand heap requirement for wrapping and indexing off-heap entry
positions. But also found out that instances of
/org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl
/is constantly increasing within jvm.
I also create and destroy so many small caches during the lifecycle,
do you think that it is possible to destroyed caches leaves a
footprint in heap.
The previous scrreenshots was dominator tree view of memory analyser.
I attached again with headers.
You can see that each of GridDhtPartitionTopologyImpl uses 20mb~
heap. And there are 72 instances of GridDhtPartitionTopologyImpl living.
Also i attached screenshots of leak suspect report of memory analyzer,
which is taken periodically. You an see that instances of
/GridDhtPartitionTopologyImpl keeps increasing. /
Any ideas or suggestions?
On Wed, Apr 6, 2016 at 6:00 PM, Denis Magda <[email protected]
<mailto:[email protected]>> wrote:
Hi Tolga,
GridDhtPartitionTopologyImpl contains list of partitions that
belong to a specific node. In case of offheap caches each
partition (concurrent map) contains set of wrappers around
keys->values, stored offheap. The wrapper holds information that's
needed to unswap a value or a key to Java heap from offheap when
required by a user application.
So Ignite requires extra space for internal needs even when
offheap mode is used.
I would recommend you trying to reduce
IgniteSystemProperties.IGNITE_ATOMIC_CACHE_DELETE_HISTORY_SIZE.
This is the size of the queue that keeps deleted entries for
internal needs as well.
https://apacheignite.readme.io/v1.5/docs/capacity-planning
BTW, could you explain what columns from your screenshot mean
exactly? What tool did you use to create the memory snapshot?
--
Denis
On 4/6/2016 3:02 PM, Tolga Kavukcu wrote:
Hi everyone,
I use partitioned ignite cache for a very dynamic data. Means
that there are many updates,deletes and puts with around 5m~ row.
So to avoid gc pauses i use off-heap mode. But when i analyse
heap i see that count and heap size of
/org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl/
is
increasing constantly.
Please see attached screenshots taken from mat heap dump.
<bean class="org.apache.ignite.configuration.CacheConfiguration"
name="DEFAULT"> <property name="atomicityMode" value="ATOMIC" />
<property name="cacheMode" value="PARTITIONED" /> <property
name="memoryMode" value="OFFHEAP_TIERED" /> <property
name="backups" value="1" /> <property name="affinity"> <bean
class="org.apache.ignite.cache.affinity.fair.FairAffinityFunction">
<constructor-arg index="0" type="int" value="6"/> </bean>
</property><property name="writeThrough" value="false" />
<property name="writeBehindEnabled" value="false" /> </bean>
Thanks for helping out.
There are totally 1.2 heap used by GridDhtPartitionTopologyImpl,
almost equals to my data size. Do you think that there are
problems with configuration.
*Tolga KAVUKÇU
*
--
*Tolga KAVUKÇU
*
