Server User Manual

Tracing Garbage Collection
The two primary measures of garbage collection performance are throughput and pauses.
Throughput is the percentage of the total time spent on other activities apart from GC. Pauses
are times when an application appears unresponsive due to GC.
Two other considerations are footprint and promptness. Footprint is the working size of the
JVM process, measured in pages and cache lines. Promptness is the time between when an
object becomes dead, and when the memory becomes available. This is an important
consideration for distributed systems.
A particular generation size makes a trade-o between these four metrics. For example, a large
young generation likely maximizes throughput, but at the cost of footprint and promptness.
Conversely, using a small young generation and incremental GC will minimize pauses, and thus
increase promptness, but decrease throughput.
JVM diagnostic output will display information on pauses due to garbage collection. If you start
the server in verbose mode (use the command asadmin start-domain --verbose domain),
then the command line argument -verbose:gc prints information for every collection. Here is
an example of output of the information generated with this JVM ag:
[GC 50650K->21808K(76868K), 0.0478645 secs]
[GC 51197K->22305K(76868K), 0.0478645 secs]
[GC 52293K->23867K(76868K), 0.0478645 secs]
[Full GC 52970K->1690K(76868K), 0.54789968 secs]
On each line, the rst number is the combined size of live objects before GC, the second number
is the size of live objects after GC, the number in parenthesis is the total available space, which is
the total heap minus one of the survivor spaces. The nal gure is the amount of time that the
GC took. This example shows three minor collections and one major collection. In the rst GC,
50650 KB of objects existed before collection and 21808 KB of objects after collection. This
means that 28842 KB of objects were dead and collected. The total heap size is 76868 KB. The
collection process required 0.0478645 seconds.
Other useful monitoring options include:
■
-XX:+PrintGCDetails for more detailed logging information
■
-Xloggc:file to save the information in a log le
Other Garbage Collector Settings
For applications that do not dynamically generate and load classes, the size of the permanent
generation has no eect on GC performance. For applications that dynamically generate and
load classes (for example, JSP applications), the size of the permanent generation does aect GC
performance, since lling the permanent generation can trigger a Full GC. Tune the maximum
permanent generation with the -XX:MaxPermSize option.
Managing Memory and Garbage Collection
Sun GlassFish Enterprise Server 2.1 Performance Tuning Guide • January 200986