Tomcat memory consumption increased after turning on session replication

[jpori]

http://java-monitor.com/postedimages/eb111f3e-4656-4c14-8c30-e90e922fa5da.png

Hi,

I have relatively small grails application on tomcat running nicely until now. For some reason it has started to consume more memory, but I have profiled the app in local dev and in test env, it works fine.
Major difference is that the production has session replication enabled(between 2 tomcats)

For some reason I think it's related to session, but not sure how to check the session(s) size or count from tomcat.

Here area configs:
JAVA_OPTS="${JAVA_OPTS} -server -Xms2G -Xmx3G -XX:PermSize=512m -XX:MaxPermSize=1024m -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC "
JAVA_OPTS="${JAVA_OPTS} -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:MaxNewSize=256m -XX:NewSize=128m "
JAVA_OPTS="${JAVA_OPTS} -XX:+DisableExplicitGC -Djava.net.preferIPv4Stack=true"

java: Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
os: ubuntu 10.04(64)
tomcat: 6.0.30

[Kees de Kooter]

You can view the session count in the tomcat manager application.

[jpori]

yeah I notice that, but there is now around 1000 session active, but still the memory goes up and down about 1g(between 1g and 2g).
I was monitoring this at the night when there was no trafic(from access log) and still the memory was continuing the same way. The active session count from the java-monitor was about 200 at that time.

[kjkoster]

Dear jpori,

This kind of memory pattern is typical for applications that cache data for a short time. Long enough to be promoted from the young generation memory pool into the old generation. This means that the garbage needs to be collected with a full garbage collect.

You can try to increase the size of your young generation (to avoid promoting so many objects to the old generation). Alternately (and probably better) is for you to reduce the volume of data you cache.

Since you mention sessions: try to not store as much crap in the HTTP session and see if that helps. :)

Kees Jan

[jpori]

Hi,

Thanks for the fast reply.

Cache was the reason that I ran the Jprofiler yesterday for 4 sessions. And that came out that there was only few(as expect) our objects in the cache.
And if I run the same app in test env, which is identical (except the session replication) to production, and it behaves fine.

In production, even after reboot, the memory consumption is high(even if there are no traffic). That is the reason that I think the tomcat session replication is causing this. But seems that it quit hard to find out the sizes of the active sessions .

These thing are sometimes hard to find.