Managing Memory and Garbage Collection
When the new generation fills up, it triggers a minor collection in which the surviving objects are moved to the old generation. When the old generation fills up, it triggers a major collection which involves the entire object heap.
Both HotSpot and Solaris JDK use thread local object allocation pools for
Choosing the Garbage Collection Algorithm
Pauses during a full GC of more than four seconds can cause intermittent failures in persisting session data into HADB.
While GC is going on, the Application Server isn’t running. If the pause is long enough, the HADB times out the existing connections. Then, when the application server resumes its activities, the HADB generates errors when the application server attempts to use those connections to persist session data. It generates errors like, “Failed to store session data,” “Transaction Aborted,” or “Failed to connect to HADB server.”
To prevent that problem, use the CMS collector as the GC algorithm. This collector can cause a drop in throughput for heavily utilized systems, because it is running more or less constantly. But it prevents the long pauses that can occur when the garbage collector runs infrequently.
▼To use the CMS collector
1Make sure that the system is not using 100 percent of its CPU.
2Configure HADB timeouts, as described in the Administration Guide.
3Configure the CMS collector in the server instance.
To do this, add the following JVM options:
■
■
Additional Information
Use the jvmstat utility to monitor HotSpot garbage collection. (See “Further Information” on page 91
For detailed information on tuning the garbage collector, see Tuning Garbage Collection with the 5.0 Java Virtual Machine.
Chapter 4 • Tuning the Java Runtime System | 85 |
