All geek questions in one place

Appropriate heap and legacy calibration for JVM for data intensive application

  • I am running a server application using the sunjava-1.6.0_21 .
  • My application is data heavy and acts like a cache server. Thus, it stores a lot of long live data that we do not expect to receive GC throughout the application.
  • I set the following JVM parameters -Xmx16384M and -Xms16384M .
  • After loading the necessary data, memory usage by the application follows
  • Total Heap Space: 13969522688
  • Maximum heap space: 15271002112
  • Free Heap Space: 3031718040
  • Long-term (old gene) heap storage: Used=10426MB Max=10922MB Used/Max=95%

Using the old generation - I confirmed that this is due to actual data and is not expected to be free. My question is that by default the JVM is the size of the heap space (it allocates the 10922MB old gene), which leaves very little free space in the section of the old generation.

  • Can less free space in the old gene affect the application?
  • If so, how do I do this? Should I experiment with JVM settings like newratio and try to increase the space available for the old generation, or in any other way, I have to configure the application.
+6
source share
2 answers

Can less free space in the old gene affect the application?

If your Tenured Gen is fully populated, a large collection will happen, and this type of collection will be expensive. You can use the following options: -verbose:gc and -XX:+PrintGCDetails to find out if a full-screen GC occurs frequently. If so, yes, it may affect the performance of your application.

If so, how do I do this? Should I experiment with JVM settings such as newratio and try to increase the space available for the old generation or in any other way, I have to configure the application.

You can try NewRatio, but keep in mind that if your eden is too short, your shadow gene will most likely fill up faster.

In conclusion, you should use a monitoring tool to better understand the parameters of the virtual machine that you should use. It will easily show you how your generations fill up during application execution, it is easier to read and understand than gc logs;)

+3
source

If you know that the lifespan of your objects is a long game with parameters that specify the size of the areas relative to each other.

You can establish relationships in young generation and old generation (eden and ternured spaces), as well as survivors.

The goal is to minimize complete garbage collection by allowing a small garbage collection to free up all memory.

You prohibit garbage collection to free objects while keeping them available in your application. I mean, you only need to make sure that those objects are removed by small collections of garbage.

Enable options

 -verbose:gc -Xloggc:/opt/tomcat/logs/gc.out -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

Then, using the GCViewer tool , you can see the time spent in gc and the number (size) of deleted objects. Among some useful indicators.

+2
source

Source: https://habr.com/ru/post/917499/

More articles:


All Articles