3

I have JDK 8 on multiple servers and the heap size keeps increasing till it reaches 90% and the application fails. During this time period multiple GCs run but the old generation keeps growing until the application fails. The current work around is to restart Tomcat. My server has 15GB RAM, 4 core CPU. My Java setup is:

-Xms12036M -Xmx12036M -Xmn800M 

Is there any recommendation on these values? I thought the GC would take care of it, but the old generation but appears not to be. I am new to Java and not sure if this indicates a memory leak or if the GC is not doing such thing?

entpnerd
  • 10,049
  • 8
  • 47
  • 68
raindrop
  • 525
  • 1
  • 9
  • 16

4 Answers4

2

I don't think there is something wrong with your parameters. I suggest looking for memory leaks in your code. Using a profiler is a good idea but you can also look for a leak pattern. Here is a very good collection: Creating a memory leak with Java

Community
  • 1
  • 1
asaad
  • 441
  • 2
  • 15
2

First check on memory leak front with JStacks/JMaps, thread dumps and Memory analyser tools. If you don't have any leaks in memory of your system, you have to fine tune garbage collector algorithms.

Java offers different types of garbage collectors.

Have a look at strengths & weakness of various GC algorithms

  1. The Serial Collector: The serial collector is the simplest one, and the one you probably won’t be using, as it’s mainly designed for single-threaded environments.

  2. The Parallel / Throughput collector: Its biggest advantage is that is uses multiple threads to scan through and compact the heap. The downside to the parallel collector is that it will stop application threads when performing either a minor or full GC collection.

  3. The CMS Collector: This algorithm uses multiple threads (“concurrent”) to scan through the heap (“mark”) for unused objects that can be recycled (“sweep”). It will be efficient if you either increase the size of the old generation (or the entire heap for that matter) or allocate more background threads to the collector.It uses more CPU in order to provide the application with higher levels of continuous throughput.

  4. The G1 Collector: The Garbage first collector (G1) introduced in JDK 7 update 4 was designed to better support heaps larger than 4GB. The G1 collector utilizes multiple background threads to scan through the heap that it divides into regions, spanning from 1MB to 32MB (depending on the size of your heap). using the –XX:+UseG1GC flag.

If you are using G1 collector, you have to fine tune region size parameter. If 15 GB is your heap size, your region size should be (15 GB / 2048 ) MB, which is around 7 MB. Do not experiment more on New Gen Size. You can stick to default settings since this algorithm provides best performance with default values.

Have a look at this article:

https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc_tuning.html

Ravindra babu
  • 37,698
  • 11
  • 250
  • 211
1

GC of the JVM is just response for objects which are not referenced by your main program,(included "reference cycle") ,

If there are many objects in the Heap can not be collected by GC, which caused OOM,two possibility :

  1. those objects are logically needed by your program :
    you need to add memory resource,or need to change the process of your program to avoid using huge amounts of memory resource.

  2. those objects are logically not needed,but still referenced by your main program , (ex:object were not needed ,but didn't removed from the list): it's memory leak in java ,it's a bug ,you must fix it in your program .

try to use some profiling tool ,or trace your code to figure out is it a memory leak issue .

柯鴻儀
  • 613
  • 1
  • 10
  • 25
0

The -Xmn800M (800MB young generation) seems like a pretty low value for a 12GB heap. Consider just outright killing that parameter and just retaining the -Xms12036M -Xmx12036M parameters.

Note that your old generation will continue to grow until a full GC runs. You will have lots of minor GCs that will do a GC on that first 800MB but not on the remaining 11.2GB. As such, try to compare heap dumps using something the Eclipse Memory Analysis Tool. Also, try to grab a few different heap dumps. Keep an eye for objects that are monotonically growing in size.

Community
  • 1
  • 1
entpnerd
  • 10,049
  • 8
  • 47
  • 68