How to enable Garbage Collection (GC) logging in JBoss Data Grid
Environment
- Red Hat JBoss Data Grid (JDG)
- 8.x
- 7.x
- 6.x
Issue
- How to enable Garbage Collection (GC) logging in JBoss Data Grid (JDG).
- How does one enable GC logging on JBoss Data Grid (JDG)?
- How do I enable garbage collection logging on JDG?
- How do I enable garbage collection logging on RHDG 8/7 in OCP?
Resolution
Refer to the linked articles below for general information about enabling Java garbage collection logging.
With respect to Red Hat JBoss Data Grid:
- If using embedded mode, garbage collection logging will be enabled at the container level (i.e., JBoss EAP, JBoss EWS, Apache Karaf, Weblogic).
- If using client/server mode, garbage collection logging (on the server end) can be enabled via the standalone.conf/clustered.conf (*nix OSes) or standalone.conf.bat/clustered.conf.bat (Windows OSes).
JDK 8
Add a line like the following to the bin/*.conf file:
JAVA_OPTS="$JAVA_OPTS -verbose:gc -Xloggc:{your directory}/gc.log.`date +%Y%m%d%H%M%S` -XX:+PrintGCDetails -XX:+PrintGCDateStamps"
Note It is highly recommended to use time stamps for GC logging to be able to have a relation between the server and GC logfiles.
JDK 11/ JDK 17
In JDK 11 the GC logs were consolidated at -Xlog, as the solution JDK 11 Logging mechanism with -Xlog Option describes. Therefore, add a line like the following to the bin/server.conf file or bin/server.sh - recommended is server.conf:
JAVA_OPTS="$JAVA_OPTS -Xlog:gc*:file={your directory}/gc.log"
This will enable the logging and store the GC in the file gc.log, if file=gc.log is used (without any path) the root will be where server.sh was started.
This will use GC with the wildcard * for other selectors and bring messages with level INFO, which is the default level. As such, to increase the level, one can use debug or trace as: -Xlog:gc*=debug or -Xlog:gc*=trace respectively. This difference is discussed in diagnostics steps of JDK 11 Logging mechanism with -Xlog Option.
Note: There is a known issue in Data Grid 8, This content is not included.JDG-4177, which
requires one to manually set the GC logs and makes the variable GC_LOGS=true inside server.conf useless on JDK 11.
For OCP Environment
Data Grid Operator 8.4.1 brings gc set by default (on /opt/infinispan/server/log/gc.log) , on previous versions, take the information above in regards to the JDK used in the image and then apply accordingly:
| Data Grid version | Method |
|---|---|
| Data Grid 8 Operator | set -Xlog:gc* (or -Xlog:gc*=debug) in the CR (since the CR is the base to each rollout): spec.container.extraJvmOpts |
| Data Grid 8 Helm Chart | set container: extraJvmOpts: "-XX:+UseG1GC -Xlog:gc*:file=/opt/gc.log:time,uptime,level,tags:filecount=4,filesize=10M" |
| Data Grid 7 | add an environment variable, e.g. JAVA_OPTS(with -Xlog:gc* for example) either in the template, in the Deployment Config, or in the Statefulset, depending on the deployment method. |
To collect the GC logs from the pod
Use: oc rsync <pod>:<path> , example: oc rsynch /opt/datagrid/standalone/log/gc.log.
The overall pod is ephemeral, and most of the time /opt directory too, which means that it will be gone if you scale-down the pod or if the pod crashes. The option to make it permanent would be to set the GC logs for another location, with a persistent volume (PV) mounted.
Related articles:
- Enabling and Understanding GC Logging
- How to enable date and time in the gc.log
- How do I enable Java garbage collection logging
- How to enable Garbage Collection (GC) logging in EAP 6 domain mode
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.