0

We are trying to get an HP UX server up for running some Batch Jobs in Java. The problem in the nutshell is this:

These Batch Jobs are running on the Jeus Application Server (a Made in Korea product). Although most of the jobs are running on time, some Batch Jobs have reported the famous PermGen Out of Memory Error. We got a heap dump and started looking at the JVM options. They are as follows: Xms - 2048m Xmx - 2048m PermSize - 512m MaxPermSize - 512m. The old GC collector is CMS and the young generation collector is a Parallel Collector.

We noticed that the actual Heap size is quite fine and that the PErm Gen ran out of all its 512m of memory. HPJmeter showed that this was a gradual rise in the memory and hence, we suspected a memory leak. We looked at all the Class Loaders and there were about 168 instances of the core Jeus App Server ClassLoader. The memory leak estimator showed that the this Class Loader was leaking memory. It showed that the number of bytes held were only around 3MB.

We looked at the number of classes/types loaded by this class loader and there were around 512 items. The memory leak also showed some other objects as being involved in memory leaks.

I have the following questions:

  1. Now that the Classloader which is leaking has been identified, how do we identify the exact reference(s) which is causing the problem?
  2. If one class loader with a specific object id is shown as leaking memory, is it possible that the other instances of the same class loader leak the some varying amount of memory?
  3. Any guidance as to what to do next would be highly appreciated.

Aditya.

Aditya
  • 47
  • 1
  • 7

1 Answers1

1

Are you sure it's the class loader that's "leaking", or are the classes loaded by the loader still referenced?

Understand that a "user class loader" is typically used to load classes that may need to be unloaded at a later time. Eg, if classes are dynamically generated as some sort of web page generation scheme, these classes need to be loaded within their own class loader, used, and then all traces of references to the classes and their loaders need to be eliminated. When those references are gone the loaders and loaded classes will be collected.

If some sort of cache is hanging on to references to the classes (eg, by referencing objects of the classes, or by linking to the classes from other classes in other loaders) then collection doesn't occur.

Hot Licks
  • 47,103
  • 17
  • 93
  • 151
  • I guess some reference might still be hanging on to some of the classes loaded by the class loader. I checked with the Memory Leak estimator provided by HP Jmeter and it showed this Class Loader as one of the "leaks". I would like to know if there is a possible way of identifying which class/type is causing the leak? THere are around 500 classes/types loaded by this class loader. I am guessing that it would not be possible of say if other instances of the same class loader would be a problem because we would not know which class has a reference which is still holding on to it. Isnt that so? – Aditya Jul 18 '12 at 03:48
  • I don't know what tools may be available to tell you what classes are loaded by what class loaders. I think most "full JVM dump" tools will give you this info, if you dig through the mound for it. Look for classes with machine-generated names (or names corresponding to "scripts" of some sort) and figure out how those are getting generated. – Hot Licks Jul 18 '12 at 11:42