When the Java VM runs low on memory, you should see two behaviors:

To confirm the presence of a memory leak, add -verbose:gc to your JAVA_ARGS and monitor the number of sessions on your site (see the Garbage Collection section for details). As an alternative, set the gcOnSample property to true in the /atg/dynamo/server/ServerMonitor component. This setting forces a garbage collection once in each sampling interval (by default, every 10 minutes). This allows you to get accurate free memory statistics from the Server Monitor without the possibly substantial overhead of using the -verbose:gc Java argument. If you see free memory decrease over time as your site has a constant number of sessions, you may have a memory leak. Before deciding that you have a memory leak, make sure you have given the system enough time to fill all caches and reach a stable state after startup.

Memory leaks in Java are caused by data structures that hold onto objects that are no longer needed. This is often due to a Vector or Hashtable that is not coded correctly. For example, if you store objects in a Hashtable using a session ID as a key, but you do not remove these objects when the session expires, this Hashtable will grow without bounds.

You can use OptimizeIt to help find these errors. Another way to detect when a Hashtable or Vector is growing without bounds is to use a modified version of the standard Hashtable and Vector that is instrumented to print a message each time the 10000th, 20000th, etc. element is added. Of course, if you use a different Collection class, this will not find that problem.

One frequent cause of Java memory leaks is the use of an addXXXListener() method without a corresponding removeXXXListener() method. Review your code to make sure you haven’t made this mistake.

loading table of contents...