Enabling object statistics in JFR: impact of applications memory
Java Flight recorder (JFR)
JFR allows you to collect the (low level) information relating to the JAVA virtual machine and the java application. These information can then be used to 1) understand behaviour of the java application and 2) to identify any performance related issues (e.g. memory leaks). When configuring the JFR, one can control the amount of data to be recorded by 1) enabling/disabling event types 2) by setting thresholds 3) enabling/disable stack traces and 4) by adjusting recording frequency [1]. JFR comes with several pre-configured profiles which can be used to collect different types of statistics about the JVM and Java application. One such profile is the default profile. It has been pointed out that the default profile can be always-on due it is very low performance overhead [2]. Enabling certain types of events in JFR, however, can have a significant impact on the application’s performance.
In this blog, I will investigate, the behaviour of applications memory when we enable object (heap) statistics and class loading. These options can be enabled by creating custom profile. Refer to [3] for more information about custom templates and how to enable these options. When object statistics and class loading are enabled JFR collects heap statistics such as classes that take more than 0.5% of the heap and thread local allocation buffer statistics . Such information can be used for identifying memory leaks and so on.
Memory impact analysis
Let’s now have a look at the usage of memory before and after enabling object statistics. Note that JFRS provided in this blog are from WSO2 APIM GW node. The performance test is done for a period of 20 min and the two 10 min sections (before and after) of these JFRS have been considered in the blog.
Details of the performance test: APIM Version 2.0.0, set-up:distributed; scenario: number 2, concurrency: 150, number of nodes: 6, work-load generator: JMETER. For information WSO2 APIM refer to [4].
Note that before enabling the object statistics the memory usage curve closely follows saw tooth pattern [5]. After enabling objects statistics there has been some distortions in this pattern due to noise introduced by major garbage collections etc. Notice that the before enabling object statistics the number of garbage collections =181 out of which there is only 1 major garbage collection (refer to the figures below for the GC behaviour). After enabling the heap statistics there is a significant increase in the number of GC pauses. Note that there are 485 total GC pauases and 104 of these GC pauses are due to the major garbage collections. After enabling the object statistics, the total GC time has increased significantly i.e. from 5 s and 738 ms to 1 min 59 s 220 ms
It is important to note that after enabling the object statics, the GC pauses contributes to 20% of the total run time whereas before enabling it this value is about 1%.
Conclusion
In this blog, I looked at the impact of enabling object statistics on the memory usage and the applications run time. We noticed that object statistics events having a significant impact on the application’s performance. Once enabled, GC pauses contributes to 20% of the total run time whereas for the default profile this value is about 1%.
[1] https://docs.oracle.com/javacomponents/jmc-5-5/jfr-runtime-guide/about.htm#JFRRT108
[2] https://docs.oracle.com/cd/E15289_01/doc.40/e15070/config_rec_data.htm
[3] http://isuru-perera.blogspot.com/2016/03/specifying-custom-event-settings-file.html3]
