JVM is the heart of any java based applications. Most of the issues we face in our applications and servers are due to incorrect JVM settings and memory leaks. Memory leaks, well, we have no option we have to sit and debug the code. But the former is entirely a different task, Tuning a JVM is a dark art. You need to have complete knowledge about the JVM architecture. Also, tuning a JVM for a specific hardware is another headache. I have struggled a lot to configure our Glassfish server on Ubuntu with 16GB RAM. The default glassfish server JVM settings are not suitable for production use and that required some alteration. Now, after so much struggle, our server is running fine. So I thought this post would be helpful for some people who are struggling like me to configure JVM settings for different application servers. First we will learn about each segments of JVM in detail and in my next post I will show the glassfish jvm settings for production use.
-Xms: This jvm argument request the operating system to allocate the minimum amount of heap memory at start-up. i.e, -Xms1g allocates 1GB as the initial heap memory. It accepts m and g as the units
-Xmx: Set the maximum amount of JVM heap memory. OutOfMemoryException is thrown when memory goes beyond this level due to memory leaks or because of overload condition.
-XX:NewRatio: It defines the old/new generation ratio. In other words, this ratio defines the size of old(tenured) and new(eden) generation space. i.e,
-XX:NewRatio=2 allocates 2:1 ratio for old to new generation.
If our max heap space is -Xmx=9g, then the calculation goes like this
2 / 3 * 9 = 6GB for old generation
1 / 3 * 9 = 3GB for new generation
-XX:PermSize: Allocates the initial permanent generation non heap size
-XX:MaxPermSize: Allocates the maximum permanent generation non heap size
-XX:SurvivorRatio: This parameter controls the size of two survivor spaces. i.e, -XX:SurvivorRatio=6 sets the ratio between each survivor space and eden to be 1:6, each survivor space will be one-eighth of the young generation.
UseAdaptiveSizePolicy parameter must be disabled, otherwise jvm ignore this parameter. If the size is too small, copying collection overflows directly in to tenured space. If the size is too large, they will be empty.
-server: jvm can be tuned for client or server machine. For example, If you download glassfish app server, by default, it is configured for client machine using -client parameter. But for production, we have to change this parameter to -server for better performance. -client and -server changes the garbage collection algorithms. -client uses Serial collector and -server uses Parallel collector algorithms. We will see GC algorithms in a short while.
How Garbage Collection works?
All GC algorithms follows the same basic principle to deliver better memory utilization, though their implementation differs, some algorithms favor better throughput and some favor reduced latency. But their core principle is the same. When new instances/objects are created by the application, it is pushed in to Eden/young generation space, from there, algorithm detects whether its a short lived or long lived object, if its a long lived object, it is further moved on to survivor spaces and then on to tenured or old generation.
Finally when full GC occurs, this old object will be cleaned up if the object has no references. Short lived object stays in eden or in survivor spaces and cleaned up when short pause GC occurs.
-Xms: This jvm argument request the operating system to allocate the minimum amount of heap memory at start-up. i.e, -Xms1g allocates 1GB as the initial heap memory. It accepts m and g as the units
-Xmx: Set the maximum amount of JVM heap memory. OutOfMemoryException is thrown when memory goes beyond this level due to memory leaks or because of overload condition.
-XX:NewRatio: It defines the old/new generation ratio. In other words, this ratio defines the size of old(tenured) and new(eden) generation space. i.e,
-XX:NewRatio=2 allocates 2:1 ratio for old to new generation.
If our max heap space is -Xmx=9g, then the calculation goes like this
2 / 3 * 9 = 6GB for old generation
1 / 3 * 9 = 3GB for new generation
-XX:PermSize: Allocates the initial permanent generation non heap size
-XX:MaxPermSize: Allocates the maximum permanent generation non heap size
-XX:SurvivorRatio: This parameter controls the size of two survivor spaces. i.e, -XX:SurvivorRatio=6 sets the ratio between each survivor space and eden to be 1:6, each survivor space will be one-eighth of the young generation.
UseAdaptiveSizePolicy parameter must be disabled, otherwise jvm ignore this parameter. If the size is too small, copying collection overflows directly in to tenured space. If the size is too large, they will be empty.
-server: jvm can be tuned for client or server machine. For example, If you download glassfish app server, by default, it is configured for client machine using -client parameter. But for production, we have to change this parameter to -server for better performance. -client and -server changes the garbage collection algorithms. -client uses Serial collector and -server uses Parallel collector algorithms. We will see GC algorithms in a short while.
How Garbage Collection works?
All GC algorithms follows the same basic principle to deliver better memory utilization, though their implementation differs, some algorithms favor better throughput and some favor reduced latency. But their core principle is the same. When new instances/objects are created by the application, it is pushed in to Eden/young generation space, from there, algorithm detects whether its a short lived or long lived object, if its a long lived object, it is further moved on to survivor spaces and then on to tenured or old generation.
Finally when full GC occurs, this old object will be cleaned up if the object has no references. Short lived object stays in eden or in survivor spaces and cleaned up when short pause GC occurs.
No comments:
Post a Comment