This discussion is archived
4 Replies Latest reply: Apr 16, 2013 3:20 PM by jschellSomeoneStoleMyAlias RSS

Please analyze this heap dump.

allbory Newbie
Currently Being Moderated
Hi.

My tomcat server has crashed with below error message.
(Last error message was incorrect)

Apr 12, 2013 10:22:39 AM org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler process
SEVERE: Error reading request, ignored
java.lang.OutOfMemoryError: Java heap space
+     at org.apache.coyote.http11.InternalAprOutputBuffer.<init>(InternalAprOutputBuffer.java:67)+
+     at org.apache.coyote.http11.Http11AprProcessor.<init>(Http11AprProcessor.java:101)+
+     at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.createProcessor(Http11AprProtocol.java:632)+
+     at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:587)+
+     at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1675)+
+     at java.lang.Thread.run(Unknown Source)+

Here's my tomcat config.

-Dfile.encoding=UTF8-Dfile.encoding=UTF8
-XX:HeapDumpPath=./java.hprof
-Xms1024M
-Xmx2048M
-XX:NewSize=512M
-XX:MaxNewSize=1024M
-Xloggc:gc.txt
-XX:HeapDumpOnOutOfMemoryError+
-XX:MaxTenuringThreshold=10
-Xincgc
-XX:DisableExplicitGC+
-verbose:gc
-XX:PrintGCTimeStamps+
-Djavax.net.ssl.trustStore=D:/apache-tomcat-6.0.20/lib/secure/jssecacerts
-Djavax.net.ssl.trustStorePassword=changeit
-Djava.util.logging.config.file=D:\tomcat_product\apache-tomcat-6.0.35\conf\logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.endorsed.dirs=D:\tomcat_product\apache-tomcat-6.0.35\endorsed
-Dcatalina.base=D:\tomcat_product\apache-tomcat-6.0.35
-Dcatalina.home=D:\tomcat_product\apache-tomcat-6.0.35
-Djava.io.tmpdir=D:\tomcat_product\apache-tomcat-6.0.35\temp


Here's tomcat version and environment.(on windows 2003)

JVM: Java HotSpot(TM) 64-Bit Server VM (20.4-b02, mixed mode)
Java: version 1.6.0_29, vendor Sun Microsystems Inc.
Java Home: C:\Program Files\Java\jre6
JVM Flags: <none>

Heap dump on OOME: enabled

Tried to open dump file(java.hprof) with JVM. I saw 2 objects.
capture image :
http://twitpic.com/cjovfn
http://twitpic.com/cjowjr
http://twitpic.com/cjowoc

GC worked properly at first 1-2 hours. But after that GC didn't work on time.
That makes tomcat server went hang.

Here're my questions.

1. I'm sure that there's no memory leakage to use connection/preparedstatement/callablestatemet. Then should I close ArrayList after use of it by using below way?
> arrayname = null;
Right now I'm suspicious ArrayList memory leakage. But I don't know how to check this out.

2. I just opened dump file and tried to find any clue but I couldn't figure it out.
Is there any tools or file that can say which class file got memory leakage?

Thanks in advance.
Dan

Edited by: allbory on Apr 15, 2013 10:12 PM

Edited by: allbory on Apr 16, 2013 6:17 AM
  • 1. Re: Please analyze this heap dump.
    Kayaman Guru
    Currently Being Moderated
    allbory wrote:
    1. I'm sure that there's no memory leakage to use connection/preparedstatement/callablestatemet.
    Well, double check them anyways.
    Then should I close ArrayList after use of it by using below way?
    arrayname = null;
    You can't close ArrayLists. And you would only want to null them in case you knew you were hanging on to the references for longer than needed. And you wouldn't be asking this question if you were.
    Right now I'm suspicious ArrayList memory leakage. But I don't know how to check this out.
    ArrayList doesn't leak memory. Although it can allocate memory poorly, if you rely on the default growth pattern and fill it with let's say a million objects.
    2. I just opened dump file and tried to find any clue but I couldn't figure it out.
    Is there any tools or file that can say which class file got memory leakage?
    If only it was that easy. Then you wouldn't need to analyze anything.

    Are you doing reflection, custom class loading, anything weird in your program?
  • 2. Re: Please analyze this heap dump.
    allbory Newbie
    Currently Being Moderated
    First of all thanks.

    Replaces Xmx to 3G and initial size as well(2G).
    It is going to monitoring all day.

    I think permgen is safety.
    I couldn't see error message from permgen.

    Thanks again.
  • 3. Re: Please analyze this heap dump.
    gimbal2 Guru
    Currently Being Moderated
    If only it was as easy as increasing the amount of memory. Alas, 99/100 times that only delays the problem.

    You may want to consider upgrading to Tomcat 7 by the way: it is a vastly improved product and in my experience 100% backwards compatible with Tomcat 6.
  • 4. Re: Please analyze this heap dump.
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    allbory wrote:
    tried to find any clue but I couldn't figure it out.
    What you do is put this on the test box. Create some normal traffic that mimics what should happen.

    Then you start DECREASING the maximum heap. That will make the error appear much faster.
    Keep decreasing until you can reproduce the problem quickly. If you make it too low then you might run into legitimate OOMs. So don't decrease too much.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points