Monitor application server's Java process

As BellaDati is a Java application run on the application server and JVM tools like VisualVM can be used for monitoring the BellaDati's usage of memory, threads, etc. and can be a source of valuable information in solving performance issues.

There are 2 ways how the VisualVM can connect to the Java process of the running application server which host BellaDati:

Enable JMX

To enable JMX connection to the Java process running application server following JVM options need to be added to it:

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.local.only=true
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.rmi.port=9010
-Dcom.sun.management.jmxremote.port=9010
-Djava.rmi.server.hostname=localhost		

Once JVM options are added and application server is restarted, VisualVM can be connected to it by creating JMX connection to <server-address>:9010. In case the port is not publicly available and SSH connection is possible, port can be made available by port forwarding, e.g. on Linux based systems via:

ssh -L 9010:localhost:9010 <user>@<host>

Collect GC Logs

In case of memory issues, Java process running application server can be configured to collect garbage collection (GC) logs as well as to generate a heap dump in case of OutOfMemoryError. Also, switching the type of garbage collection algorithm can improve performance. To enable GC logs generation and heap dump generation as well as switch GC algorithm to G1 add following JVM options in the application server:

-XX:+UseG1GC
-Xloggc:<gc-log-dir>/gc-%t.log
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=20
-XX:GCLogFileSize=50M
-XX:+SafepointTimeout
-XX:+UnlockDiagnosticVMOptions
-XX:SafepointTimeoutDelay=1000
-XX:+PrintSafepointStatistics
-XX:PrintSafepointStatisticsCount=1
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=<heap-dump-dir>

where

The above configuration enables the GC log file rotation after the file reaches 50MB. Up-to 20 files are kept before the old ones are removed.


The above configuration generates a new GC log file name every time application server is started. The %t part in the file name converts to the current date & time of the server. The generated file name is kept for the whole run of the application server, even after log file rotation. Once the application server is restarted a new file name is generated and old ones are not deleted, old files must be deleted manually. Alternative is to exclude the %t part, but then existing GC log(s) needs to be copied before application server is restarted otherwise they will be overwritten.