Objects are created in the memory to service incoming requests. Once requests are serviced, newly created objects will become useless (i.e. garbage). This garbage must be evicted from the memory so that there is enough room created in the memory to service the new incoming requests. If there isn’t sufficient memory, the application can experience poor response times, Out Of Memory Error, and fatal crashes.
In Java, Android, C#…, garbage collection is automatic, whereas in the several predecessor programming languages (C, C++) – programmer must write code explicitly to release the objects after they are used. So, it’s a major convenience for Java, Android, and C# application developers. But this automatic garbage collection is not free, it comes with a price. Automatic Garbage Collection can have a profound impact on:
- Application Response Time
Table of Contents
Application Response Time
To garbage collect objects automatically, entire application has to be paused intermittently to mark the objects that are in use and sweep away the objects that are not used. During this pause period, all customer transactions which are in motion in the application will be stalled (i.e. frozen). Depending on the type of GC algorithm and memory settings that you configure, pause times can run from few milliseconds to few seconds to few minutes. Thus, Garbage Collection can affect your application SLA (Service Level Agreement) significantly.
Garbage collection consumes a lot of CPU cycles. Each application will have thousands/millions of objects sitting in memory. Each object in memory should be investigated periodically to see whether they are in use? If it’s in use, who is referencing it? Whether those references are still active? If they are not in use, they should be evicted from memory. All these investigations and computation requires a considerable amount of CPU power.
Of course, poor GC configuration can lead to high memory consumption and vice versa. Most applications saturate memory first before saturating other resources (CPU, network bandwidth, storage). Most applications upgrade their EC2 instance size to get additional memory rather to get additional CPU or network bandwidth.
Thus to have top notch SLAs and reduce the bill from your cloud hosting provider, your applications Garbage collection has to be function effectively.
In order to study and optimize Garbage Collections impact on the application’s performance, one has to enable Garbage Collection Logging. Besides that, Garbage Collections logs can be used to troubleshoot memory-related problems in the application.
Enabling GC logs
GC Logging can be enabled by passing below-mentioned system properties during application startup
Until Java 8:
Below is the system property that is supported by all version of Java until JDK 8.
-XX:+PrintGCDetails -Xloggc:<gc-log-file-path> Example: -XX:+PrintGCDetails -Xloggc:/opt/tmp/myapp-gc.log
From Java 9:
Below is the system property that is supported by all version of Java starting from JDK 9.
-Xlog:gc*:file=<gc-log-file-path> Example: -Xlog:gc*:file=/opt/tmp/myapp-gc.log
How to analyze GC logs?
Here is a sample GC log generated when above system properties were passed:
GC log has rich information, however, understanding GC log is not easy. There isn’t sufficient documentation to explain GC log format. On top of it, GC log format is not standardized. It varies by JVM vendor (Oracle, IBM, HP, Azul, …), Java version (1.4, 5, 6, 7, 8, 9), GC algorithm (Serial, Parallel, CMS, G1, Shenandoah), GC system properties that you pass (-XX:+PrintGC, -XX:+PrintGCDetails, -XX:+PrintGCDateStamps, -XX:+PrintHeapAtGC …). Based on this permutation and combination, there are easily 60+ different GC log formats.
Thus, to analyze GC logs, it’s highly recommended to use GC log analysis tools such as GCeasy, HPJmeter. These tools parse GC logs and generate great graphical visualizations of data, reports Key Performance Indicators and several other useful metrics.
Here is a sample GC log analysis report generated by the GCeasy tool.