I see in a few places [1] people start the GC logging in production servers (mission critical), e.g.
java -server -Xms1024m -Xmx1024m -XX:NewSize=256m \
-XX:MaxNewSize=256m \
-XX:+UseConcMarkSweepGC \
-XX:CMSInitiatingOccupancyFraction=70
-XX:+PrintGCDetails \
-XX:+PrintGCDateStamps \
-XX:+PrintTenuringDistribution \
-Xloggc:logs/gc.log \
-Djava.awt.headless=true
-Dcom.sun.management.jmxremote -classpath ...
Is it recommend practices in production env these days?
Update: I have included a link [2] from Oracle also suggest to monitor GC on production servers.
Sources:
[1] https://serverfault.com/questions/121490/java-opts-xxprintgcdetails-affect-on-performance
[2] http://docs.oracle.com/cd/E24290_01/coh.371/e22838/deploy_checklist.htm#CHHFADDF
Yes, this is a common practice. This is often highly recommended and I give examples and references below.
Why GC logging is good for production Java servers:
Minimal Overhead - The GC logging has a minimal overhead to the overall system performance.
- This is claimed e.g. by Charlie Hunt, ex-JVM Performance Architect and co-author of the Java Performance book.
- all the world record SPEC Benchmarks running Java Enterprise software are running production servers with GC logging enabled. This confirms that the logging has low overhead and also that the logging path is highly tuned by the performace experts publishing the benchmark results.
Long-term logging is absolutely crucial to the analysis of the Application Performance. The GC logging must be enabled all the time so that the Administrators are able to observe the GC behavior and tune the application accordingly.
Definitely not.
You would only load the prod server in this way if there was an issue that couldn't be reproduced on your QA system. And even then only for a short period to collect data then return to normal "lean" mode.