Garbage Collection (GC) logging data is generated by the -verbose:gc
command line option. The log information is really useful for
monitoring Java applications, and for helping you diagnose performance
or memory problems. Often, you want to diagnose a problem when it first
happens. To do this, you need to enable logging so that you already
have the monitoring information.
The problem with enabling any logging or tracing is that it can
affect the overall performance of the system. How do you determine the
impact of enabling -verbose:gc on an IBM Java Runtime? How do you
decide if the cost of continual logging is too great?
In theory, the performance impact of GC logging should be very low.
The data is always generated internally by the garbage collector,
because it is used to enable self-tuning. There should be no
significant overhead for logging the values. The cost of enabling
-verbose:gc should be the same as adding any output markup, then
writing the output to either stderr or a log file.
For a running Java application we would expect the GC overhead: (the
percentage of time spent running GC versus the time spent running Java
code) to be around 3% or less. Some very basic quantitative tests we
carried out during development work has shown us that GC logging causes
GC to take about 1% longer, and thereby would increase that GC overhead
to 3.03%. This shows that the overall performance cost of enabling GC
logging is as low as 0.03%.
From this we can see that enabling GC logging has no real
performance impact on the application, but gives you the benefit of
monitoring for potential performance and memory problems, and helping
you to diagnose them the first time they happen.
The other consideration for any logging is making sure that you
store the logs for later analysis. This almost always requires disk
space. With the -verbose:gc option, you can choose to log the data to a
file rather than the default stderr, by using the following command
where the optional <X> and <Y> parameters are the number
of files to write to, and the number of garbage collection cycles a
file should contain. This allows logging to occur on a circular basis.
So, in summary, it is often a good idea to run your application with
-verbose:gc switched on; the performance overhead is very low, and the
disk space required by the logging output can be managed using rotating