Java Reference
In-Depth Information
log, and then look back to when the most recent CMS cycle started. The CMS-initial-mark
line will show how full the old generation was when the CMS cycle started:
89.976: [GC [1 CMS-initial-mark: 702254K(1398144K)]
772530K(2027264K), 0.0830120 secs]
[Times: user=0.08 sys=0.00, real=0.08 secs]
In this example, that works out to about 50% (702 MB out of 1,398 MB). That was not soon
enough, so the CMSInitiatingOccupancyFraction needs to be set to something lower than
50. (Although the default value for that flag is 70, this example started the CMS threads
when the old generation was 50% full because the UseCMSInitiatingOccupancyOnly flag
was not set.)
The temptation here is just to set the value to 0 or some other small number so that the back-
ground CMS cycle runs all the time. That's usually discouraged, but as long as you are aware
of the trade-offs being made, it may work out fine.
The first trade-off comes in CPU time: the CMS background thread(s) will run continually,
and they consume a fair amount of CPU—each background CMS thread will consume 100%
of a CPU. There will also be very short bursts when multiple CMS threads run and the total
CPU on the box spikes as a result. If these threads are running needlessly, that wastes CPU
resources.
On the other hand, it isn't necessarily a problem to use those CPU cycles. The background
CMS threads have to run sometimes, even in the best case. Hence, the machine must always
have enough CPU cycles available to run those CMS threads. So when sizing the machine,
you must plan for that CPU usage.
Could those CPU cycles be used for something else when the CMS background thread isn't
running? Not usually. If another application uses those cycles, it has no way of knowing
when the CMS thread is running. As a result, the other application and the CMS thread will
compete for CPU, which will make the CMS thread more likely to lose its race. Sophistic-
ated operating system tuning can sometimes be used to run those competing applications
with a priority that ensures the CMS thread takes precedence, but that can be tricky to get
right. So yes, when CMS cycles run too frequently, far more CPU cycles are used, but those
CPU cycles would otherwise just be idle.
The second trade-off is far more significant and has to do with pauses. As the GC log
showed, certain phases of the CMS cycle stop all the application threads. The main reason
CMS is used is to limit the effect of GC pauses, so running CMS more often than needed is
Search WWH ::




Custom Search