Eclipse
/
jetty.project
mirror of https://github.com/jetty/jetty.project.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fixes #1813 - Update Garbage Collection documentation to reflect JDK9 changes.

This commit is contained in:
Simone Bordet 2017-09-14 13:46:10 +02:00
parent aa4a77794e
commit 12220c2a66
1 changed files with 20 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
jetty-documentation/src/main/asciidoc/administration/tuning/garbage-collection.adoc
View File

@ -17,57 +17,43 @@
[[garbage-collection]]
=== Garbage Collection
Tuning the JVM garbage collection (GC) can greatly improve Jetty performance.
Specifically, you can avoid pauses while the system performs full garbage collections.
Optimal tuning of the GC depends on the behavior of the application and requires detailed analysis, however there are general recommendations.
Tuning the JVM garbage collection (GC) can greatly improve the performance of the JVM where Jetty
and your application are running.
Optimal tuning of the GC depends on the behavior of the application(s) and requires detailed analysis,
but there are general recommendations to follow to at least obtain comprehensive GC logs that
can be later analyzed.
See official https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/[Java 8 Garbage Collection documentation] for further assistance.
[[tuning-examples]]
==== Tuning Examples
[[garbage-collection-logging-configuration]]
==== Garbage Collection Logging Configuration
These options are general to the Oracle JVM, and work in a Java 8 installation.
They provide good information about how your JVM is running; based on that initial information, you can then tune more finely.
The most important thing you can do for yourself when considering GC is to capture the GC activity so that you can analyze what is happening and how often it happens.
These options are general to OpenJDK (and therefore also for the Oracle JVM).
They provide good information about the GC activity of your JVM, producing logs that can later
be analyzed to perform finer tuning.
.JDK 8 Garbage Collection Logging Configuration
[source,screen, subs="{sub-order}"]
....
-verbose:gc
-Xloggc:/path/to/myjettybase/logs/gc.log
-XX:+PrintGCDateStamps
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
-XX:+PrintTenuringDistribution
-XX:+PrintCommandLineFlags
-XX:+ParallelRefProcEnabled
-XX:+PrintReferenceGC
-XX:+PrintTenuringDistribution
-XX:+PrintAdaptiveSizePolicy
....
There are not many recommended options for GC that can apply to nearly all users.
.JDK 9 Garbage Collection Logging Configuration
....
Xlog:gc*,ergo*=trace,ref*=debug,age*=trace:file=/path/to/myjettybase/logs/gc.log:time,level,tags
....
However, the most obvious one is to disable explicit GC (this is performed regularly by RMI and can introduce an abnormal amount of GC pauses).
There are not many recommended options for GC that can apply to nearly all users.
However, the most obvious one is to disable explicit GC (this is performed regularly by RMI and
can introduce an abnormal amount of GC pauses).
[source,screen, subs="{sub-order}"]
....
-XX:+DisableExplicitGC
....
Before you apply any other GC tuning options, monitor your GC logs to see if https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html[tuning the CMS] makes sense for your environment.
A common setup for those just starting out with GC tuning is included below for reference.
____
[CAUTION]
This example configuration below could have a negative effect on your application performance, so continued monitoring of your GC log before and after is highly recommended to know if the configuration was beneficial or not.
____
[source,screen, subs="{sub-order}"]
....
-XX:MaxGCPauseMillis=250
-XX:+UseConcMarkSweepGC
-XX:ParallelCMSThreads=2
-XX:+CMSClassUnloadingEnabled
-XX:+UseCMSCompactAtFullCollection
-XX:CMSInitiatingOccupancyFraction=80
....