Java: frequent spikes at "used memory" graph

1
votes

For some time I get performance problems with my Java application, I used JavaMelody for profiling and the unusual thing is the "Used Memory" graph. It has a lot of short spikes which seems to reach ~8GB line really fast and then, as I understand, GC is cleaning up the memory. Does someone has the experience to track what do these spikes mean? Seems like they point to some specific problem.

GC and JVM are configured as: -XX:PermSize=384m -XX:MaxPermSize=512m -XX:+UseCompressedOops -XX:+UseFastAccessorMethods -XX:+CMSClassUnloadingEnabled -XX:+UseParNewGC -XX:-UseParallelOldGC -XX:-UseAdaptiveSizePolicy -XX:SurvivorRatio=128 -XX:NewSize=4055m -XX:MaxNewSize=4055m -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=60 -XX:+UseCMSInitiatingOccupancyOnly -Xms12888m -Xmx12888m -Dsun.rmi.dgc.client.gcInterval=1800000 -Dsun.rmi.dgc.server.gcInterval=1800000

The graph is (Green is "mean", Blue is "Maximum"): Memory graph - 16:00 - 8:00 system without load, 8:00+ - system is under load

Until 8:00 there was no load at the system.

After 8:00 it's under load, but not huge one (~20 simultanious operations)

1
javamemory-leaksgarbage-collection

1 Answers

0
votes

This looks like you are allocating objects in your Eden space which is normal operation for a JVM. I suggest you use a memory profiler such as Flight Recorder to find out what the allocation rates is and see if there is any way you can reduce it.

In particular , if you GC-ing more often than once every couple of seconds, I would try to reduce the amount of garbage you are creating. If it is long than this it depends on your use case as to whether it is important.

If you haven't done a memory profile recently, I suggest doing so, just to get a different view of your application. I have found it useful finding bugs even when performance wasn't an issue.

-XX:SurvivorRatio=128

This is pretty high and suggests you have a lot of very short lived objects. These might be easy to optimise away.

I recently worked on a rules engine for a client in New York and by spending a day reducing the allocation rate we increased it's performance by a factor of 2.3x. By spending a second day on CPU we got this to 4x the throughput.