Skip to end of banner
Go to start of banner

JVM Garbage Collection

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »


Overview

While profiling a FOLIO instance running Juniper release, we found out that it is using Mark and Sweep Garbage Collection phases but were not sure which Garbage Collection algorithm it was using. We created PERF-201 - Getting issue details... STATUS  - POC to investigate Garbage Collection in FOLIO modules


Investigations

Use -Xlog:gc flag to enable logging when a module loads up. For example, we used mod-data-export to experiment.

Experiments:

All experiments were carried out on openjdk-11.0

  1. Running mod-data-export locally on my laptop
java -jar -Xlog:gc=debug:file=gc.log target/mod-data-export-fat.jar

JVM automatically selected G1 Garbage Collector. G1 (Garbage First) Garbage Collector is designed for applications running on multi-processor machines with large memory space. 

My laptop is running on 6 cores


     2. Running mod-data-export in AWS ECS

JVM automatically selected Serial Garbage Collection. The Serial algorithm uses a single thread to do Garbage Collection. When JVM runs Garbage Collection, Java applications pause for few milliseconds.

mod-data-export is running inside a Docker Container which is running inside EC2 instance which is running Linux on 2 cores which are shared among 13 other backend FOLIO modules


       3. Explicitly select G1 Garbage Collector when loading mod-data-export using flag XX:+UseG1GC. Also, tried to override using -XX:+AlwaysActAsServerClassMachine flag. However, Data Export App in UI fails to poll the backend and crashes frequently.


       4. Tested in a cap planning environment that is running 8 Cores(m5.2xlarge EC2 instance type) but JVM is still using Serial Garbage Collection

 

Observations

For Java 9+ version, the default Garbage Collection is G1. So when running locally on my laptop, JVM automatically selected G1. However, there is a caveat that there must be enough CPU and memory resources in a multi-core OS. 

While EC2 instance with m5.xlarge instance type is running with default 2 CPU Cores. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cpu-options-supported-instances-values.html

https://serverfault.com/questions/691659/count-number-of-allowed-cpus-in-a-docker-container

https://stackoverflow.com/questions/52474162/why-is-serialgc-chosen-over-g1gc

https://www.baeldung.com/jvm-garbage-collectors

https://docs.oracle.com/javase/9/gctuning/available-collectors.htm#JSGCT-GUID-45794DA6-AB96-4856-A96D-FDE5F7DEE498

https://dzone.com/articles/pitfalls-in-jvm-and-docker-defaults



  • No labels