Java Garbage Collection in Jelastic Cloud

performance and price are two big considerations in application hosting that always matter. and, very often, we question ourselves on how to decrease dollars spent, without affecting the performance of apps at the same time. in this article we’d like to address automatic memory management for java applications hosted with jelastic using garbage collection.

firstly, let’s define what garbage collection is and what it does for your java app. and then we will be more specific about garbage collection processes in jelastic’s cloud.

java garbage collection overview

garbage collection (gc) is a form of automatic memory management. its aim is to find data objects in memory that are no longer demanded and make their space available for reuse.

the created object uses some memory that remains allocated until there are references for the use of the object. when there are no references for an object, it is considered to be no longer required and the memory occupied by the object can be reclaimed. in such a way, you don’t pay for unused resources and can cut your costs.

jelastic default gc settings

in one of our earlier publications we covered the topic of garbage collection (gc) in jelastic. there, we tested different kinds of garbage collectors and defined the most appropriate for the java applications hosted on our cloud, taking into consideration the automatic vertical scaling that we provide.

since then, we continued to experiment to find the best solution. as a result of our new investigations, we changed the default settings of garbage collectors in jelastic in order to increase the benefits for our users.

now, if no custom gc is specified, jelastic will configure it as follows:

• parnew for all servers with resource limits below 8gb
• g1 for servers with resource limits above 8gb (64 cloudlets and more)

in this case, it doesn’t matter how many cloudlets are actively consumed. garbage collector takes into consideration a scaling limit – the maximum amount of cloudlets that you set for each server.

parnew garbage collector

parnew is a “stop-the-world” multi-threaded garbage collector. it collects the young generation of objects. since the young generation is normally small in size, in jelastic this parnew collector is used only for servers with resource limits below 8gb. based on the size, the collection is very fast and does not impact your application too much. in addition, parnew collector has a compaction of unused ram that enables support of automatic vertical scaling – one of the prominent jelastic features.

garbage-first garbage collector

the garbage-first (g1) collector is a server-style garbage collector for multi-processor machines with large memories. the heap is partitioned into fixed-sized regions and g1 tracks the live data in those regions. when garbage collection is required, it collects from the regions with less live data first.

g1 is focused on applications that require large heaps with limited gc latency. after deep analysis, we reached the conclusion that 8gb of ram consumption is big enough for using g1.

together with these settings, a special jelastic gc agent is used to release unused ram by jvm to os (more details are described below in this article).

customization of gc settings in jelastic cloud

if you believe that the default jelastic settings of garbage collector can have a negative impact on your application, you can tune them according to the requirements of your app. we recommend to customize these configurations only if you fully understand the impact of such changes on your app’s performance.

you can set a custom gc parameter based on your application requirements by:

• editing the variables.conf file of your tomcat, tomee or jetty server
• editing jvm option in the admin panel of glassfish server

1. to configure tomcat, tomee or jetty open conf files of your java server.

2. navigate to the server > variables.conf file.

3. in the opened variables.conf file you can configure garbage collector settings by stating the needed parameter in the following format:

-xx:+useparnewgc
-xx:+useg1gc
-xx:+useconcmarksweepgc
-xx:+useserialgc

4. while configuring glassfish, you need to use the same format of gc parameter.

open glassfish admin panel, navigate to configurations > gfcluster-config > jvm settings > jvm options and edit the appropriate jvm option as it is shown in the picture below.

5. after this, only the specified garbage collector will be used while starting your java server without taking into consideration the amount of allocated resources.

6. also, you can reduce the usage of cpu power by gc and control how jvm handles its heap memory. for that you need to tune the frequency of gc processes by stating -xmx and -xms switches.

-xmx switch is used to start the jvm with a higher maximum heap memory and to release cpu time for the important processes.
-xms parameter is stated to ensure that the size of jvm’s initial heap memory is equal to the maximum allocated memory (scaling limit).

these parameters should be specified in the variables.conf file for tomcat,tomee and jetty or in jvm options for glassfish.

-xmx< size >m
-xms< size >m

jelastic garbage collection agent

currently jvm does not have any feature to call full gc periodically. releasing reserved, but at the same time unused ram by jvm to os is required for automatic vertical scaling, configured in jelastic cloud. that’s why jelastic uses a special garbage collection agent .

jelastic gc agent works only for two kinds of garbage collection (set in jelastic by default):

• -xx:+useparnewgc
• -xx:+useg1gc

if you change the default gc settings to any other which does not provide compaction and can not release ram to os by design, then jelastic gc agent will be disabled and won’t call full gc.

to tune the settings of jelastic gc agent, navigate to the server > variables.conf file for tomcat , tomee or jetty application server.

gc agent for glassfish can be configured or disabled via the glassfish admin panel in gfcluster-config > jvm settings > jvm options .

enable/disable jelastic gc agent

jelastic gc agent is enabled for all newly created java application servers by default.

if you want to enable jelastic gc agent in already existing containers, you need to upload the jelastic-gc-agent.jar file and set the agent manually in the following way:

1. download the jelastic-gc-agent.jar file.

2. navigate to the conf files of your java server and upload the downloaded .jar file to the home folder.

3. navigate to server > variables.conf file and state the path to your jelastic-gc-agent.jar file in the java agent parameter.

the path can differ based on the java server you use:

• tomcat/tomee : /opt/tomcat/temp
• glassfish : /opt/glassfish3/temp
• jetty : /opt/jetty/home

4. save the changes and restart the server.

if you think that jelastic gc agent processes may cause performance degradation for your application, please comment the following line and restart the server:

-javaagent:/var/lib/jelastic/java/jelastic-gc-agent.jar

change the period of checks

by default, jelastic gc agent initiates system checking every 15 minutes (beginning from every jvm start) to force freeing of unused application memory. the period of checks can be changed based on your requirements.

to change the time period of checks, specify the duration between calls of full gc in seconds, as shown below:

-javaagent:/var/lib/jelastic/java/jelastic-gc-agent.jar=period=900

save your edits and restart the server to apply the changes.

enable debug mode

you can also enable debug mode in the following way:

-javaagent:/var/lib/jelastic/java/jelastic-gc-agent.jar=debug=true

as a result, you’ll be able to track gc processes in the logs.

save your changes and restart the server.

check gc results

to check the result of the configured periodical checks and ram releasing we are going to use a special loader application.

1.  follow the link to download loader.war archive with the testing application.

2. upload this .war archive to the jelastic cloud.

3. deploy this loader application to the environment with the java application.

4. open config files and navigate to server > variables.conf file in order to check the jelastic java agent settings.

in our case, we changed the period value to 60 seconds to get a faster result.
if you also edit the configurations, then 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 navigate to the statistics where after some time you’ll see the results.

when you request the application, the memory usage increases by 500 mb due to the parameters added to the app link. such an amount of ram is going to be used during 300 seconds (also due to stated parameter).

and after that, the memory usage will decrease as the jelastic java agent calls full gc. this is performed because the jelastic gc agent recognizes the possibility to release some ram as the app completed its active processes and does not require the full amount of memory.

you can request the testing application again in order to load the memory several times and check the process of its release.

7. as we switched on 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 seen in the catalina logs

hence, using this method, you can improve your application memory management which will lead to a reduction of ram consumption by jvm. as a result, you will save your money and increase the performance of your application.

proof that this is an effective solution, is from feedback on this functionality from one of our existing customers:

“i’m loving the new gc agent! look at the money it is saving!” – katherine morgan demchinsky

that kind of feedback means so much to the team at jelastic. it acknowledges that our commitment to making jelastic better is useful and appreciated! stay tuned to see what other new features and functions are added to jelastic.