Java Garbage Collection on Infobox Jelastic cloud hosting
Performance and price are two of the most significant factors in application hosting. We often ask ourselves how to spend less without degrading application performance. In this article, we will look at automatic memory management for Java applications hosted on Infobox Jelastic cloud hosting using garbage collection and Jelastic GC Agent. At the end of the article a little surprise.
First, let's define what garbage collection is and what it does for our Java application. Then we will talk in more detail from garbage collection processes in Jelastic.
Garbage Collection (GC) is a form of automatic memory management. Its goal is to search for objects in memory that applications no longer need and free up space they take up for future use.
')
The created object uses a certain amount of memory that remains allocated as long as there are references to this object. If there are no references to an object, it is considered no longer necessary and the memory occupied by it can be freed. Thus, you do not pay for unused resources and can reduce your costs.
If the user does not specify his own settings, Jelastic will configure the garbage collector as follows:
In this case, it does not matter how many clouds are consumed at a particular point in time. The garbage collector checks the maximum limit - the maximum number of cloudlet you allocate to the appropriate server.
ParNew - “stop the world” multithreaded garbage collector. He collects the younger generation of objects. Since the younger generation is usually small, in Jelastic this collector is used only for servers with a resource limit of less than 8 GB. An assembly based on the size of objects runs very quickly and has little effect on the operation of your application. In addition, the ParNew collector can free up unused memory, which allows vertical autoscaling to work correctly - one of the main functions of Jelastic.
Garbage-First (G1) is a server-type garbage collector for multiprocessor machines with large amounts of memory. A heap is divided into areas of fixed size and G1 tracks live data in these areas. When garbage collection is needed, gc starts with areas with less live data.
G1 focuses on applications that need large heaps with limited delays in garbage collection. After in-depth analysis, we concluded that 8 GB of memory is enough to use G1.
Together with these settings, the Jelastic specialized garbage collection agent is used, freeing up the used JVM memory in the OS.
If you are sure that the default GC settings in Jelastic are not optimal for your application, you can set them according to your needs. We recommend changing the settings only if you fully understand the effect they will have on the performance of your application.
You can set your garbage collection (GC) parameters based on the requirements of your application:
1. To configure Tomcat, TomEE, or Jetty, open the configuration files for your Java server.
2. Go to server > variables.conf .
3. In the open variables.conf file, you can specify the necessary garbage collector by setting one of the following values ​​as the GC parameter:
4. When setting up GlassFish, you should use the same format of the GC parameter.
Open the GlassFish admin panel, go to Configurations > gfcluster-config > JVM Settings > JVM Options and edit the corresponding line as shown in the image below.
5. After that, when launching your Java server, only the garbage collector you specify will be used, regardless of the allocated resources.
Please note that GC agent Jelastic works only with two types of garbage collectors:
If you manually specify another garbage collector, full garbage collection will be disabled.
6. You can also reduce the garbage collector's use of processor power and control how the JVM uses heap memory. To do this, you need to adjust the frequency of running garbage collection, specifying the -Xmx and -Xms parameters.
The -Xmx parameter is used to run a JVM with a large maximum heap and free up processor time for important processes.
The -Xms option ensures that the initial size of the JVM memory heap is equal to the maximum allocated memory limit (scaling limit).
These parameters must be specified in the variables.conf file for Tomcat, TomEE and Jetty or in the JVM settings for GlassFish.
Releasing a reserved, but at the same time, unused JVM memory in the OS is necessary for vertical autoscaling. Therefore, Jelastic uses a special garbage collection agent .
GC agent Jelastic includes an intelligent algorithm for monitoring consumed and free memory. By processing the monitoring results, he recognizes the ability to free up some of the memory for the OS and starts the full garbage collection. If the JVM does not have free memory that can be released for the OS, the Jelastic GC agent does not start the full garbage collection. This approach can potentially reduce the degradation of application performance to zero.
GC Jelastic agent works only for two types of garbage collectors (configured in Jelastic by default):
If you change the default GCs to any other ones that do not support compression and do not free up memory for the OS, the Jelastic GC agent will be disabled and will not be able to run full garbage collection.
To configure the Jelastic agent GC, go to server > variables.conf for Tomcat, TomEE or Jetty server.
For GlassFish GC, the Jelastic agent can be configured or disabled via the GlassFish administration panel in the gfcluster-config > JVM Settings > JVM Options section.
GC Jelastic agent is enabled by default for all newly created Java application servers.
If you want to enable the GC Jelastic agent in an existing container, you should load the jelastic-gc-agent.jar file and turn on the agent manually as follows:
1. Download the jelastic-gc-agent.jar file .
2. Go to the configuration files of your Java server and upload the downloaded .jar file to the home folder.
3. Go to server > variables.conf and specify the path to your jelastic-gc-agent.jar file in the -javaagent parameter.
The path depends on the Java server you are using:
4. Save the changes and restart the server.
If you notice that the Jelastic agent GC processes have caused performance degradation for your application, comment out the following line and restart the server:
-javaagent: /var/lib/jelastic/java/jelastic-gc-agent.jar
By default, the GC agent Jelastic performs a system check every 15 minutes (starting with each JVM launch) to force the memory of unused applications to be freed. The checkout period can be changed according to your needs.
To change the validation period, specify the time between runs of full garbage collection in seconds, as shown below:
-javaagent: /var/lib/jelastic/java/jelastic-gc-agent.jar=period=900
To apply the changes, save the file and restart the server.
You can enable debug mode as follows:
-javaagent: /var/lib/jelastic/java/jelastic-gc-agent.jar=debug=true
As a result, you can track the processes of the GC logs.
Please note that you can use both options (changing the test period and turning on debug mode) together:
-javaagent: /var/lib/jelastic/java/jelastic-gc-agent.jar=debug=true,period=900
Save the changes and restart the server.
To display the results of the configured periodic system checks and freeing memory, we will use the special Loader application.
1. Follow the link and download the Loader.war archive with the test application.
2. Download this .war archive to Jelastic.
3. Deploy this application in an environment with a Java application.
4. Open the configuration files and go to the server > variables.conf file to check the Jelastic agent Java settings.
In our case, to get the results as soon as possible, we changed the period to 60 seconds. If you change the settings, do not forget to save the changes and restart the server.
5. After that, open the application in a browser and add the following parameters to the link:
/ loader? mem = 500 & duration = 300
6. Now you can go to Statistics , where, after a while, you will see the results.
When you run an application request with the parameters added to the link, the memory consumption increases by 500 MB. This amount of memory will be used for 300 seconds (also in accordance with the specified parameter).
After that, memory usage will decrease as a result of launching with GC Jelastic agent for complete garbage collection. This is because the GC agent sees the opportunity to free up memory, because the application has completed its active processes and no longer needs the full amount of memory.
You can run the test application a few more times to load the memory and test its release process.
7. Since we enabled the debug mode for our Java agent, we can also track the process in the Log files.
The amount of available free memory (in bytes) can be viewed in catalina logs.
Thus, using this method, you can improve memory management for your application, which will reduce the memory consumption of the JVM. As a result, you will save your money and increase the performance of your application.
To everyone who read to the end of the article, we give 300 rubles to your Jelastic account. Register in the trial version , after the end of the trial, click on the button “Switch to the paid version” in Jelastic, fill in the information about yourself and send your login to trukhinyuri@infoboxcloud.com .
Successful use of Jelastic in the Infobox and great mood!
First, let's define what garbage collection is and what it does for our Java application. Then we will talk in more detail from garbage collection processes in Jelastic.
Garbage collection in Java: materiel
Garbage Collection (GC) is a form of automatic memory management. Its goal is to search for objects in memory that applications no longer need and free up space they take up for future use.
')
The created object uses a certain amount of memory that remains allocated as long as there are references to this object. If there are no references to an object, it is considered no longer necessary and the memory occupied by it can be freed. Thus, you do not pay for unused resources and can reduce your costs.
GC settings in Jelastic by default
If the user does not specify his own settings, Jelastic will configure the garbage collector as follows:
- ParNew for all servers with a resource limit of less than 8 GB;
- G1 for servers with a resource limit of more than 8 GB (64 or more cloudsets).
In this case, it does not matter how many clouds are consumed at a particular point in time. The garbage collector checks the maximum limit - the maximum number of cloudlet you allocate to the appropriate server.
ParNew garbage collector
ParNew - “stop the world” multithreaded garbage collector. He collects the younger generation of objects. Since the younger generation is usually small, in Jelastic this collector is used only for servers with a resource limit of less than 8 GB. An assembly based on the size of objects runs very quickly and has little effect on the operation of your application. In addition, the ParNew collector can free up unused memory, which allows vertical autoscaling to work correctly - one of the main functions of Jelastic.
Garbage – First garbage collector
Garbage-First (G1) is a server-type garbage collector for multiprocessor machines with large amounts of memory. A heap is divided into areas of fixed size and G1 tracks live data in these areas. When garbage collection is needed, gc starts with areas with less live data.
G1 focuses on applications that need large heaps with limited delays in garbage collection. After in-depth analysis, we concluded that 8 GB of memory is enough to use G1.
Together with these settings, the Jelastic specialized garbage collection agent is used, freeing up the used JVM memory in the OS.
Customizing GC settings in Jelastic
If you are sure that the default GC settings in Jelastic are not optimal for your application, you can set them according to your needs. We recommend changing the settings only if you fully understand the effect they will have on the performance of your application.
You can set your garbage collection (GC) parameters based on the requirements of your application:
- by editing your server's Tomcat, TomEE, or Jetty variables.conf file
- by changing the JVM settings in the GlassFish server admin panel
1. To configure Tomcat, TomEE, or Jetty, open the configuration files for your Java server.
2. Go to server > variables.conf .
3. In the open variables.conf file, you can specify the necessary garbage collector by setting one of the following values ​​as the GC parameter:
-XX:+UseParNewGC -XX:+UseG1GC -XX:+UseConcMarkSweepGC -XX:+UseSerialGC 4. When setting up GlassFish, you should use the same format of the GC parameter.
Open the GlassFish admin panel, go to Configurations > gfcluster-config > JVM Settings > JVM Options and edit the corresponding line as shown in the image below.
5. After that, when launching your Java server, only the garbage collector you specify will be used, regardless of the allocated resources.
Please note that GC agent Jelastic works only with two types of garbage collectors:
-XX:+UseParNewGC</li> -XX:+UseG1GC</li> If you manually specify another garbage collector, full garbage collection will be disabled.
6. You can also reduce the garbage collector's use of processor power and control how the JVM uses heap memory. To do this, you need to adjust the frequency of running garbage collection, specifying the -Xmx and -Xms parameters.
The -Xmx parameter is used to run a JVM with a large maximum heap and free up processor time for important processes.
The -Xms option ensures that the initial size of the JVM memory heap is equal to the maximum allocated memory limit (scaling limit).
These parameters must be specified in the variables.conf file for Tomcat, TomEE and Jetty or in the JVM settings for GlassFish.
-Xmx<>m -Xms<>m Jelastic garbage collection agent
Releasing a reserved, but at the same time, unused JVM memory in the OS is necessary for vertical autoscaling. Therefore, Jelastic uses a special garbage collection agent .
GC agent Jelastic includes an intelligent algorithm for monitoring consumed and free memory. By processing the monitoring results, he recognizes the ability to free up some of the memory for the OS and starts the full garbage collection. If the JVM does not have free memory that can be released for the OS, the Jelastic GC agent does not start the full garbage collection. This approach can potentially reduce the degradation of application performance to zero.
GC Jelastic agent works only for two types of garbage collectors (configured in Jelastic by default):
-XX:+UseParNewGC -XX:+UseG1GC If you change the default GCs to any other ones that do not support compression and do not free up memory for the OS, the Jelastic GC agent will be disabled and will not be able to run full garbage collection.
To configure the Jelastic agent GC, go to server > variables.conf for Tomcat, TomEE or Jetty server.
For GlassFish GC, the Jelastic agent can be configured or disabled via the GlassFish administration panel in the gfcluster-config > JVM Settings > JVM Options section.
Enable / Disable Gel Jelastic Agent
GC Jelastic agent is enabled by default for all newly created Java application servers.
If you want to enable the GC Jelastic agent in an existing container, you should load the jelastic-gc-agent.jar file and turn on the agent manually as follows:
1. Download the jelastic-gc-agent.jar file .
2. Go to the configuration files of your Java server and upload the downloaded .jar file to the home folder.
3. Go to server > variables.conf and specify the path to your jelastic-gc-agent.jar file in the -javaagent parameter.
The path depends on the Java server you are using:
- Tomcat / TomEE : / opt / tomcat / temp
- GlassFish : / opt / glassfish3 / temp
- Jetty : / opt / jetty / home
4. Save the changes and restart the server.
If you notice that the Jelastic agent GC processes have caused performance degradation for your application, comment out the following line and restart the server:
-javaagent: /var/lib/jelastic/java/jelastic-gc-agent.jar
Change of inspection period
By default, the GC agent Jelastic performs a system check every 15 minutes (starting with each JVM launch) to force the memory of unused applications to be freed. The checkout period can be changed according to your needs.
To change the validation period, specify the time between runs of full garbage collection in seconds, as shown below:
-javaagent: /var/lib/jelastic/java/jelastic-gc-agent.jar=period=900
To apply the changes, save the file and restart the server.
Enable debug mode
You can enable debug mode as follows:
-javaagent: /var/lib/jelastic/java/jelastic-gc-agent.jar=debug=true
As a result, you can track the processes of the GC logs.
Please note that you can use both options (changing the test period and turning on debug mode) together:
-javaagent: /var/lib/jelastic/java/jelastic-gc-agent.jar=debug=true,period=900
Save the changes and restart the server.
Verify garbage collection results
To display the results of the configured periodic system checks and freeing memory, we will use the special Loader application.
1. Follow the link and download the Loader.war archive with the test application.
2. Download this .war archive to Jelastic.
3. Deploy this application in an environment with a Java application.
4. Open the configuration files and go to the server > variables.conf file to check the Jelastic agent Java settings.
In our case, to get the results as soon as possible, we changed the period to 60 seconds. If you change the settings, do not forget to save the changes and restart the server.
5. After that, open the application in a browser and add the following parameters to the link:
/ loader? mem = 500 & duration = 300
6. Now you can go to Statistics , where, after a while, you will see the results.
When you run an application request with the parameters added to the link, the memory consumption increases by 500 MB. This amount of memory will be used for 300 seconds (also in accordance with the specified parameter).
After that, memory usage will decrease as a result of launching with GC Jelastic agent for complete garbage collection. This is because the GC agent sees the opportunity to free up memory, because the application has completed its active processes and no longer needs the full amount of memory.
You can run the test application a few more times to load the memory and test its release process.
7. Since we enabled the debug mode for our Java agent, we can also track the process in the Log files.
The amount of available free memory (in bytes) can be viewed in catalina logs.
Thus, using this method, you can improve memory management for your application, which will reduce the memory consumption of the JVM. As a result, you will save your money and increase the performance of your application.
300 rubles for Jelastic as a gift!
To everyone who read to the end of the article, we give 300 rubles to your Jelastic account. Register in the trial version , after the end of the trial, click on the button “Switch to the paid version” in Jelastic, fill in the information about yourself and send your login to trukhinyuri@infoboxcloud.com .
Successful use of Jelastic in the Infobox and great mood!
Source: https://habr.com/ru/post/230663/
All Articles