Java Heap Space - Out of memory issue

955690

Hi All,

We have 2 servers which has same heapsize setting (min and max 20 MB) and receives same load for processing.
But we receive heap memory issue in only one of the server.

Increasing the heap size only reduces the frequency of the occurence

What can be the possible causes ?


More details on the issue:*

The process invokes java calls via JNI and many instances of this process is configured with same settings in
both the servers. Both the servers are JDK1.6 configured.

The heap memory however is not reclaimed in one of the server. This issue is thrown while parsing XML to java object as shown below:

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at org.apache.xmlbeans.impl.store.Cur$CurLoadContext.xmlns(Cur.java:3018)
at org.apache.xmlbeans.impl.store.Locale$SaxHandler.startElement(Locale.java:3209)
at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.reportStartTag(Piccolo.java:1082)
at org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.parseAttributesNS(PiccoloLexer.java:1822)
at org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.parseOpenTagNS(PiccoloLexer.java:1521)
at org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.parseTagNS(PiccoloLexer.java:1362)
at org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.parseXMLNS(PiccoloLexer.java:1293)
at org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.parseXML(PiccoloLexer.java:1261)
at org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.yylex(PiccoloLexer.java:4808)
at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yylex(Piccolo.java:1290)
at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yyparse(Piccolo.java:1400)
at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.parse(Piccolo.java:714)
at org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3435)
at org.apache.xmlbeans.impl.store.Locale.parse(Locale.java:706)
at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:690)
at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:677)
at org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:208)


Any inputs for resolving the issue will be of great help!

gimbal2

A memory leak is a general case for heap space running out (note that 20mb is very low, that can't be correct). In Java a "memory leak" is the act of holding on to object references even after they are no longer used. It can also be caused by not calling some sort of close or cleanup method that is tied to native resources. Note that the XML thing can be a red herring, it is simply the spot that the JVM runs out of memory, it does not mean that it is the spot where memory is eaten up.

A profiler tool can help you find out which parts of your application are eating up memory which will be a likely spot to find dodgy code; if you are using an IDE there may be a profiler built into it.

And yeah there is always the possibility that the application during runtime simply needs more memory than you are giving it and you simply need to find the proper maximum heap space setting for things to remain stable. Setting min and max to the same number generally isn't a good idea, although that changes between garbage collector implementations.

955690

thanks for your inputs.

Yes, the exception thrown is only the point where jvm has run out of memory

We had increased the setting to 70 MB in the server where this heap out of space is thrown.
however only the frequency of this issue is reduced.

Used jmap histo to analyze loaded Objects..It only highlights the char,string,byte objects instance that has consumed more memory. Couldn't derive solution from it..

The code mostly nullifies objects in finally block. There are dynamically class loading mechanism Involved in few cases.

The doubt is why it throws in one server and not in another, when the other parameters like JdK version, volume of orders it processes is approx same.?

How to check if garbage collection is invoked at certain intervals? Any command/config setting to check the difference in JVM GC setting between the servers?

Thanks,
JayaVignesh

EJP

The code mostly nullifies objects in finally block.

Then the code is poorly written, and it therefore probably exhibits numererous other fallacies as well, some of which may be causing excess memory usage. Nulling out local references in finally blocks accomplishes precisely nothing, and strongly suggests that the authors lacked competence.

955690

Can you please elaborate on this --> exhibits numererous other fallacies as well, some of which may be causing excess memory usage.

gimbal2

Let me translate: "The code sucks and probably has plenty of mistakes in it that lead to stability problems".

Note that 70mb is STILL very low. I would expect something in the range of 128mb min - 256mb max for an average webapp to have enough breathing space.

955690

Actually this is a java process configured with separate heap settings. Web app is configured with larger setting.

the question is why same code runs out of memory in one server and not in another?

Why is the leaky nature is reflected in only one box?

gimbal2

952687 wrote:
the question is why same code runs out of memory in one server and not in another?

Different machine, different environment, simply not the same. So different behavior.

Stop talking about leaks when you have no proof. Profile it and get some hard facts in stead of guesses.