0
votes

I have a tomcat that does session clustering with IGNITE. I have a sample login call that creates a session for one user and after a successful login, i see the below logs that gets printed where heap size is fluctuating a lot.

My questions are

  1. What does this mean. How can one single Spring session object take so much space?.

  2. Why is the whole heap size fluctuating?.

  3. Am i gonna bring down the whole server if i do 100 consecutive logins?.

Metrics for local node (to disable set 'metricsLogFrequency' to 0) ^-- Node [id=fadf3af0, name=lockGrid] ^-- H/N/C [hosts=3, nodes=3, CPUs=6] ^-- CPU [cur=8.33%, avg=3.7%, GC=0.07%] ^-- Heap [used=261MB, free=85.03%, comm=318MB] ^-- Public thread pool [active=0, idle=6, qSize=0] ^-- System thread pool [active=0, idle=16, qSize=0] ^-- Outbound messages queue [size=0] p2016-07-29 14:12:50,205 [r-#23%lockGrid%] INFO IgniteKernal%lockGrid

Metrics for local node (to disable set 'metricsLogFrequency' to 0) ^-- Node [id=fadf3af0, name=lockGrid] ^-- H/N/C [hosts=3, nodes=3, CPUs=6] ^-- CPU [cur=0.23%, avg=3.65%, GC=0%] ^-- Heap [used=402MB, free=77.01%, comm=453MB] ^-- Public thread pool [active=0, idle=6, qSize=0] ^-- System thread pool [active=0, idle=16, qSize=0] ^-- Outbound messages queue [size=0] 2016-07-29 14:13:50,204 [r-#23%lockGrid%] INFO IgniteKernal%lockGrid

Metrics for local node (to disable set 'metricsLogFrequency' to 0) ^-- Node [id=fadf3af0, name=lockGrid] ^-- H/N/C [hosts=3, nodes=3, CPUs=6] ^-- CPU [cur=0.27%, avg=3.64%, GC=0%] ^-- Heap [used=188MB, free=89.22%, comm=363MB] ^-- Public thread pool [active=0, idle=6, qSize=0] ^-- System thread pool [active=0, idle=16, qSize=0] ^-- Outbound messages queue [size=0] 2016-07-29 14:14:50,211 [r-#23%lockGrid%] INFO IgniteKernal%lockGrid

Any pointers are appreciated.

Regards, Aravind

1

1 Answers

0
votes

Heap memory is managed by JVM, not by Ignite. Part of the memory is always consumed by temporary objects which will be eventually removed by GC, but the moment of time it will happen is undefined. If your application is not failing with out of memory errors and if there are no long GC pauses, there is nothing to worry about.