Enable recommended JVM arguments

[maracle6]

Is your feature request related to a problem? Please describe. Pega’s Helm charts for deploying into a Kubernetes environment have a variety of default settings and configurations applied. Currently, the charts don’t pass in any performance or heap related JVM arguments other than the minimum and maximum heap size.

Describe the solution you'd like Since the docker images use Java 11, they do get some of our recommendations by default in that version of the JDK. However we can tune the JVM with the following set of arguments: -XX:MetaspaceSize=512M -XX:MaxMetaspaceSize=1G -XX:ReservedCodeCacheSize=512M -XX:+DisableExplicitGC -XX:+ParallelRefProcEnabled -XX:+UseStringDeduplication -Djava.awt.headless=true -Xlog:gc*,gc+heap=debug,gc+humongous=debug:file=/usr/local/tomcat/logs/gc.log:tags,uptime,pid,level,time

Describe alternatives you've considered Adding these arguments has been a standard practice for many years, except that the set of arguments changes slightly with each JDK version

Additional context It would be ideal if these went into CATALINA_OPTS instead of JAVA_OPTS but I figured they could be default settings for the javaOpts setting for now and a customizable catalinaOpts would be a separate enhancement request.

In addition, we should also have -XX:+HeapDumpOnOutOfMemoryError at some point but that will be more complex due to the need to save the heap dump off somewhere any prevent the pod from being killed while the heap dump is being generated.

Finally I debated whether the GC logging, which is very useful for performance analysis, should be going to a file or stdout. If I understand the unified logging it seems like we can only do one or the other. While stdout would be captured by logging stacks, it can be challenging to separate the GC output from other logging. Generally the logs need to be turned back into a file to allow an analyzer to consume them. So it seemed simpler to keep it as a log that could be copied out of a container on demand, though at the risk of losing historical data. Would be open to differing options on this.