You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Petkov, Rossen" <Ro...@tmag.com> on 2006/05/25 00:37:07 UTC
Tomcat Memory Leak
Hello,
I am having a problem with Tomcat 5.0.19 on windows with JDK
1.4.2_03.The memory that java.exe is using keeps growing till the point
that tomcat
Runs out of memory.
Using a profiler, doesn't seem to help me much. I can see the memory
being used by certain classes go up (mainly char[] and byte[] and some
tomcat classes, please see the tables below) and even reach all the way
to the point that used java heap equals to the java heap, then GC
probably kicks but, while running Tomcat throws an OutOfMemory
exception. I have allocated -Xmx896M. I'm now forcing a GC when the
free memory drops to 15%. With every GC, the freed memory is less and
less, which to me is an indication of memory leak.
I can't figure out where all those char[] objects are coming
from or why they aren't being reclaimed by the garbage collector. I
know that something is holding memory and isn't letting it go, and I
know that the leaked memory consists of char[] and byte[] objects (see
below tables). What I can't figure out is how to determine what's doing
the leaking.
After several hours of heavy usage, the GC runs and frees less
memory than the previous run. This gives me on day of normal operation
and I have to restart Tomcat after hours to be ready for the next day,
not a really acceptable solution.
I noticed the 3 tomcat classes:
org.apache.tomcat.util.buf.MessageBytes,
org.apache.tomcat.util.buf.ByteChunk and
org.apache.tomcat.util.buf.CharChunk. The memory occupied my these seems
to never be released. Can they be the cause of the multiple byte[] and
char[]?
Some info about the application/environment:
- Tomcat 5.0.19 on windows with JDK 1.4.2_03.
- MVC type web application
- front Controller dispathing requests to business classes and
forwards to appropriate JSP, passing necessary data objects in the
request object
- heavy JDBC use and DAO/DTO components, mainly using
PreparedStatement
- Oracle stored procedures and functions acccessed thru
CallableStatement
- Oracle database
I am doing the usual for closing all jdbc database related objects like
ResultSet, PreparedStatement and connections.
Here are some thoughts that I have, that could be the reason for the
leak, these are more questions:
1. DTO objects are being passed from the data layer to the
business layer and finnaly to the JSP. After using the DTOs on the JSP,
they are not explicitly set to null in the JSP. I see that all DTO
declarations are in the "service" method of the compiled JSPs. Can this
be a problem?
2. HashMaps, HashTables and LinkedHashMaps are being passed the
same way thru the layers and end up in the JSPs. These are not set to
null either. Can this be a problem?
3. PreparedStatement and CallableStatement are always closed,
but not always set to null.
Can any of these be the cause?
Below are some metrics from my environemnt:
After a several hours of heavy usage, BEFORE GC:
Name Instance count Size
char[ ] 2,200,184 425,721
kB
byte[ ] 199,003 178,902
kB
java.lang.String 1,825,003 42,773
kB
java.lang.StringBuffer 925,351 21,687
kB
<class>[ ] 679,935 19,181
kB
org.apache.naming.resources.FileDirContext$FileResourceAttributes
122,254 8,595 kB
org.apache.tomcat.util.buf.MessageBytes 117,876 5,525
kB
org.apache.tomcat.util.buf.ByteChunk 135,061 5,275
kB
org.apache.tomcat.util.buf.CharChunk 132,558 5,178
kB
java.util.HashMap$ValueIterator 97,551 3,04
...more
AFTER GC:
This is the top of the list, sorted by size:
Name Instance count Size
byte[ ] 47,866 167,877
kB
char[ ] 69,387 151,906
kB
org.apache.tomcat.util.buf.MessageBytes 117,928 5,527
kB
org.apache.tomcat.util.buf.ByteChunk 135,120 5,278
kB
org.apache.tomcat.util.buf.CharChunk 132,616 5,180
kB
<class>[ ] 71,550 4,711
kB
int[ ] 22,195 1,408
kB
java.text.DecimalFormat 7,351 804 kB
java.lang.String 32,828 769 kB
org.apache.tomcat.util.http.MimeHeaderField 28,098 658 kB
java.util.HashMap 15,598 609 kB
java.util.GregorianCalendar 7,351 516 kB
long[ ] 4,927 498 kB
java.text.DecimalFormatSymbols 7,351 402 kB
...more
As you can see, one third of the char[] and almost all of the byte[]
remain after the GC. As for the three tomcat classes, they remain almost
unchanged.
All your input will be much appreciated!
Regards,
Rossen Petkov
rossen.petkov@tmag.com
TMaG Carlsbad
1.760.918.6228
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat Memory Leak
Posted by Antonio Petrelli <br...@tariffenet.it>.
Petkov, Rossen ha scritto:
> Hello,
> I am having a problem with Tomcat 5.0.19 on windows with JDK
> 1.4.2_03.The memory that java.exe is using keeps growing till the point
> that tomcat
> Runs out of memory.
>
Try this: http://wiki.apache.org/tomcat/OutOfMemory
Ciao
Antonio
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat Memory Leak
Posted by Rocio Alfonso Pita <ro...@fadesa.es>.
El Jueves 25 Mayo 2006 07:44, Bill Barker escribió:
> If you are using the AJP/1.3 Connector, then 5.0.19 has a very very very
> very well known memory leak. You need to set
> request.registerRequests="false" in this case. Either that, or upgrade :).
hello,
I have a similar problem, and similar structure aplication too (MVC). I use
DAOs for data access and a Oracle database, jakarta-struts and JSP with JSTL
tags for the view layer. I use some profilers, and I obtain similar results.
I realized that the char[] and byte[] variables are config and validation
struts files and jsp page too.
I don't know in what configuration file I have to activate this property:
request.registerRequests="false" , in jk.properties? server.xml?
Is there another ajp version that I can use with ssl?
I'm using jakarta-tomcat 50.19 too. The lastest version is 5.5, but I'm not
sure that all memory leaks problems had been solved in it. What is your
opinion for solved this problem? upgrade to 5.5 or upgrade to 5.0.28 or....?
For your information, I use Suse Linux Enterprise Server 9 and I install
tomcat rpms included in this distritution:
$ rpm -qa | grep -i tomcat
jakarta-tomcat-5.0.19-29.1
jakarta-tomcat-doc-5.0.19-29.1
apache2-jakarta-tomcat-connectors-5.0.19-29.1
jakarta-tomcat-examples-5.0.19-29.1
$
Thanks and regards,
Rocío
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat Memory Leak
Posted by Bill Barker <wb...@wilshire.com>.
If you are using the AJP/1.3 Connector, then 5.0.19 has a very very very
very well known memory leak. You need to set
request.registerRequests="false" in this case. Either that, or upgrade :).
"Petkov, Rossen" <Ro...@tmag.com> wrote in message
news:56291E4E22B58B4C8F722E1EB620586307C2BE@uscaramex01.am.adsint.biz...
Hello,
I am having a problem with Tomcat 5.0.19 on windows with JDK
1.4.2_03.The memory that java.exe is using keeps growing till the point
that tomcat
Runs out of memory.
Using a profiler, doesn't seem to help me much. I can see the memory
being used by certain classes go up (mainly char[] and byte[] and some
tomcat classes, please see the tables below) and even reach all the way
to the point that used java heap equals to the java heap, then GC
probably kicks but, while running Tomcat throws an OutOfMemory
exception. I have allocated -Xmx896M. I'm now forcing a GC when the
free memory drops to 15%. With every GC, the freed memory is less and
less, which to me is an indication of memory leak.
I can't figure out where all those char[] objects are coming
from or why they aren't being reclaimed by the garbage collector. I
know that something is holding memory and isn't letting it go, and I
know that the leaked memory consists of char[] and byte[] objects (see
below tables). What I can't figure out is how to determine what's doing
the leaking.
After several hours of heavy usage, the GC runs and frees less
memory than the previous run. This gives me on day of normal operation
and I have to restart Tomcat after hours to be ready for the next day,
not a really acceptable solution.
I noticed the 3 tomcat classes:
org.apache.tomcat.util.buf.MessageBytes,
org.apache.tomcat.util.buf.ByteChunk and
org.apache.tomcat.util.buf.CharChunk. The memory occupied my these seems
to never be released. Can they be the cause of the multiple byte[] and
char[]?
Some info about the application/environment:
- Tomcat 5.0.19 on windows with JDK 1.4.2_03.
- MVC type web application
- front Controller dispathing requests to business classes and
forwards to appropriate JSP, passing necessary data objects in the
request object
- heavy JDBC use and DAO/DTO components, mainly using
PreparedStatement
- Oracle stored procedures and functions acccessed thru
CallableStatement
- Oracle database
I am doing the usual for closing all jdbc database related objects like
ResultSet, PreparedStatement and connections.
Here are some thoughts that I have, that could be the reason for the
leak, these are more questions:
1. DTO objects are being passed from the data layer to the
business layer and finnaly to the JSP. After using the DTOs on the JSP,
they are not explicitly set to null in the JSP. I see that all DTO
declarations are in the "service" method of the compiled JSPs. Can this
be a problem?
2. HashMaps, HashTables and LinkedHashMaps are being passed the
same way thru the layers and end up in the JSPs. These are not set to
null either. Can this be a problem?
3. PreparedStatement and CallableStatement are always closed,
but not always set to null.
Can any of these be the cause?
Below are some metrics from my environemnt:
After a several hours of heavy usage, BEFORE GC:
Name Instance count Size
char[ ] 2,200,184 425,721
kB
byte[ ] 199,003 178,902
kB
java.lang.String 1,825,003 42,773
kB
java.lang.StringBuffer 925,351 21,687
kB
<class>[ ] 679,935 19,181
kB
org.apache.naming.resources.FileDirContext$FileResourceAttributes
122,254 8,595 kB
org.apache.tomcat.util.buf.MessageBytes 117,876 5,525
kB
org.apache.tomcat.util.buf.ByteChunk 135,061 5,275
kB
org.apache.tomcat.util.buf.CharChunk 132,558 5,178
kB
java.util.HashMap$ValueIterator 97,551 3,04
...more
AFTER GC:
This is the top of the list, sorted by size:
Name Instance count Size
byte[ ] 47,866 167,877
kB
char[ ] 69,387 151,906
kB
org.apache.tomcat.util.buf.MessageBytes 117,928 5,527
kB
org.apache.tomcat.util.buf.ByteChunk 135,120 5,278
kB
org.apache.tomcat.util.buf.CharChunk 132,616 5,180
kB
<class>[ ] 71,550 4,711
kB
int[ ] 22,195 1,408
kB
java.text.DecimalFormat 7,351 804 kB
java.lang.String 32,828 769 kB
org.apache.tomcat.util.http.MimeHeaderField 28,098 658 kB
java.util.HashMap 15,598 609 kB
java.util.GregorianCalendar 7,351 516 kB
long[ ] 4,927 498 kB
java.text.DecimalFormatSymbols 7,351 402 kB
...more
As you can see, one third of the char[] and almost all of the byte[]
remain after the GC. As for the three tomcat classes, they remain almost
unchanged.
All your input will be much appreciated!
Regards,
Rossen Petkov
rossen.petkov@tmag.com
TMaG Carlsbad
1.760.918.6228
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat Memory Leak
Posted by David Kerber <dc...@verizon.net>.
I had a leak of that kind when I wasn't closing inputstream and
outputstream objects. It's one thing to check anyway.
Petkov, Rossen wrote:
...
> Using a profiler, doesn't seem to help me much. I can see the memory
>being used by certain classes go up (mainly char[] and byte[] and some
>tomcat classes, please see the tables below) and even reach all the way
>to the point that used java heap equals to the java heap, then GC
>probably kicks but, while running Tomcat throws an OutOfMemory
>exception. I have allocated -Xmx896M. I'm now forcing a GC when the
>free memory drops to 15%. With every GC, the freed memory is less and
>less, which to me is an indication of memory leak.
>
>
...
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat Memory Leak
Posted by Sameer Acharya <ac...@yahoo.com>.
Did you try explicitly setting all those Hashmaps/Hashtables references to null.
Since you already mentioned that your are taking care of all your Resultsets etc that doesent sound like an issue.
I tried a small jsp example where I created a hashtable but never explicitly dereference it and the freememory seems to reduce continuosly.
When I do a gc run though the memory seems to get freed.
Hope this helps.
-Sameer
"Petkov, Rossen" <Ro...@tmag.com> wrote: Hello,
I am having a problem with Tomcat 5.0.19 on windows with JDK
1.4.2_03.The memory that java.exe is using keeps growing till the point
that tomcat
Runs out of memory.
Using a profiler, doesn't seem to help me much. I can see the memory
being used by certain classes go up (mainly char[] and byte[] and some
tomcat classes, please see the tables below) and even reach all the way
to the point that used java heap equals to the java heap, then GC
probably kicks but, while running Tomcat throws an OutOfMemory
exception. I have allocated -Xmx896M. I'm now forcing a GC when the
free memory drops to 15%. With every GC, the freed memory is less and
less, which to me is an indication of memory leak.
I can't figure out where all those char[] objects are coming
from or why they aren't being reclaimed by the garbage collector. I
know that something is holding memory and isn't letting it go, and I
know that the leaked memory consists of char[] and byte[] objects (see
below tables). What I can't figure out is how to determine what's doing
the leaking.
After several hours of heavy usage, the GC runs and frees less
memory than the previous run. This gives me on day of normal operation
and I have to restart Tomcat after hours to be ready for the next day,
not a really acceptable solution.
I noticed the 3 tomcat classes:
org.apache.tomcat.util.buf.MessageBytes,
org.apache.tomcat.util.buf.ByteChunk and
org.apache.tomcat.util.buf.CharChunk. The memory occupied my these seems
to never be released. Can they be the cause of the multiple byte[] and
char[]?
Some info about the application/environment:
- Tomcat 5.0.19 on windows with JDK 1.4.2_03.
- MVC type web application
- front Controller dispathing requests to business classes and
forwards to appropriate JSP, passing necessary data objects in the
request object
- heavy JDBC use and DAO/DTO components, mainly using
PreparedStatement
- Oracle stored procedures and functions acccessed thru
CallableStatement
- Oracle database
I am doing the usual for closing all jdbc database related objects like
ResultSet, PreparedStatement and connections.
Here are some thoughts that I have, that could be the reason for the
leak, these are more questions:
1. DTO objects are being passed from the data layer to the
business layer and finnaly to the JSP. After using the DTOs on the JSP,
they are not explicitly set to null in the JSP. I see that all DTO
declarations are in the "service" method of the compiled JSPs. Can this
be a problem?
2. HashMaps, HashTables and LinkedHashMaps are being passed the
same way thru the layers and end up in the JSPs. These are not set to
null either. Can this be a problem?
3. PreparedStatement and CallableStatement are always closed,
but not always set to null.
Can any of these be the cause?
Below are some metrics from my environemnt:
After a several hours of heavy usage, BEFORE GC:
Name Instance count Size
char[ ] 2,200,184 425,721
kB
byte[ ] 199,003 178,902
kB
java.lang.String 1,825,003 42,773
kB
java.lang.StringBuffer 925,351 21,687
kB
[ ] 679,935 19,181
kB
org.apache.naming.resources.FileDirContext$FileResourceAttributes
122,254 8,595 kB
org.apache.tomcat.util.buf.MessageBytes 117,876 5,525
kB
org.apache.tomcat.util.buf.ByteChunk 135,061 5,275
kB
org.apache.tomcat.util.buf.CharChunk 132,558 5,178
kB
java.util.HashMap$ValueIterator 97,551 3,04
...more
AFTER GC:
This is the top of the list, sorted by size:
Name Instance count Size
byte[ ] 47,866 167,877
kB
char[ ] 69,387 151,906
kB
org.apache.tomcat.util.buf.MessageBytes 117,928 5,527
kB
org.apache.tomcat.util.buf.ByteChunk 135,120 5,278
kB
org.apache.tomcat.util.buf.CharChunk 132,616 5,180
kB
[ ] 71,550 4,711
kB
int[ ] 22,195 1,408
kB
java.text.DecimalFormat 7,351 804 kB
java.lang.String 32,828 769 kB
org.apache.tomcat.util.http.MimeHeaderField 28,098 658 kB
java.util.HashMap 15,598 609 kB
java.util.GregorianCalendar 7,351 516 kB
long[ ] 4,927 498 kB
java.text.DecimalFormatSymbols 7,351 402 kB
...more
As you can see, one third of the char[] and almost all of the byte[]
remain after the GC. As for the three tomcat classes, they remain almost
unchanged.
All your input will be much appreciated!
Regards,
Rossen Petkov
rossen.petkov@tmag.com
TMaG Carlsbad
1.760.918.6228
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail Beta.
Re: Tomcat Memory Leak
Posted by Wade Chandler <hw...@yahoo.com>.
--- "Petkov, Rossen" <Ro...@tmag.com> wrote:
> Hello,
> I am having a problem with Tomcat 5.0.19 on
> windows with JDK
> 1.4.2_03.The memory that java.exe is using keeps
> growing till the point
> that tomcat
> Runs out of memory.
> Using a profiler, doesn't seem to help me much.
> I can see the memory
> being used by certain classes go up (mainly char[]
> and byte[] and some
> tomcat classes, please see the tables below) and
> even reach all the way
> to the point that used java heap equals to the java
> heap, then GC
> probably kicks but, while running Tomcat throws an
> OutOfMemory
> exception. I have allocated -Xmx896M. I'm now
> forcing a GC when the
> free memory drops to 15%. With every GC, the freed
> memory is less and
> less, which to me is an indication of memory leak.
> I can't figure out where all those char[] objects
> are coming
> from or why they aren't being reclaimed by the
> garbage collector. I
> know that something is holding memory and isn't
> letting it go, and I
> know that the leaked memory consists of char[] and
> byte[] objects (see
> below tables). What I can't figure out is how to
> determine what's doing
> the leaking.
> After several hours of heavy usage, the GC runs and
> frees less
> memory than the previous run. This gives me on day
> of normal operation
> and I have to restart Tomcat after hours to be ready
> for the next day,
> not a really acceptable solution.
> I noticed the 3 tomcat classes:
> org.apache.tomcat.util.buf.MessageBytes,
> org.apache.tomcat.util.buf.ByteChunk and
> org.apache.tomcat.util.buf.CharChunk. The memory
> occupied my these seems
> to never be released. Can they be the cause of the
> multiple byte[] and
> char[]?
>
> Some info about the application/environment:
> - Tomcat 5.0.19 on windows with JDK 1.4.2_03.
> - MVC type web application
> - front Controller dispathing requests to
> business classes and
> forwards to appropriate JSP, passing necessary data
> objects in the
> request object
> - heavy JDBC use and DAO/DTO components, mainly
> using
> PreparedStatement
> - Oracle stored procedures and functions
> acccessed thru
> CallableStatement
> - Oracle database
>
> I am doing the usual for closing all jdbc database
> related objects like
> ResultSet, PreparedStatement and connections.
> Here are some thoughts that I have, that could be
> the reason for the
> leak, these are more questions:
> 1. DTO objects are being passed from the data layer
> to the
> business layer and finnaly to the JSP. After using
> the DTOs on the JSP,
> they are not explicitly set to null in the JSP. I
> see that all DTO
> declarations are in the "service" method of the
> compiled JSPs. Can this
> be a problem?
> 2. HashMaps, HashTables and LinkedHashMaps are
> being passed the
> same way thru the layers and end up in the JSPs.
> These are not set to
> null either. Can this be a problem?
> 3. PreparedStatement and CallableStatement are
> always closed,
> but not always set to null.
> Can any of these be the cause?
>
>
> Below are some metrics from my environemnt:
> After a several hours of heavy usage, BEFORE GC:
>
> Name
> Instance count Size
> char[ ]
> 2,200,184 425,721
> kB
> byte[ ]
> 199,003 178,902
> kB
> java.lang.String
> 1,825,003 42,773
> kB
> java.lang.StringBuffer
> 925,351 21,687
> kB
> <class>[ ]
> 679,935 19,181
> kB
>
org.apache.naming.resources.FileDirContext$FileResourceAttributes
> 122,254 8,595 kB
> org.apache.tomcat.util.buf.MessageBytes
> 117,876 5,525
> kB
> org.apache.tomcat.util.buf.ByteChunk
> 135,061 5,275
> kB
> org.apache.tomcat.util.buf.CharChunk
> 132,558 5,178
> kB
> java.util.HashMap$ValueIterator
> 97,551 3,04
> ...more
>
>
>
> AFTER GC:
> This is the top of the list, sorted by size:
>
> Name
> Instance count Size
> byte[ ]
> 47,866 167,877
> kB
> char[ ]
> 69,387 151,906
> kB
> org.apache.tomcat.util.buf.MessageBytes
> 117,928 5,527
> kB
> org.apache.tomcat.util.buf.ByteChunk
> 135,120 5,278
> kB
> org.apache.tomcat.util.buf.CharChunk
> 132,616 5,180
> kB
> <class>[ ]
> 71,550 4,711
> kB
> int[ ]
> 22,195 1,408
> kB
> java.text.DecimalFormat 7,351
> 804 kB
> java.lang.String
> 32,828 769 kB
> org.apache.tomcat.util.http.MimeHeaderField
> 28,098 658 kB
> java.util.HashMap
> 15,598 609 kB
> java.util.GregorianCalendar 7,351
> 516 kB
> long[ ] 4,927
> 498 kB
> java.text.DecimalFormatSymbols 7,351
> 402 kB
> ...more
>
> As you can see, one third of the char[] and almost
> all of the byte[]
> remain after the GC. As for the three tomcat
> classes, they remain almost
> unchanged.
>
> All your input will be much appreciated!
> Regards,
> Rossen Petkov
> rossen.petkov@tmag.com
> TMaG Carlsbad
> 1.760.918.6228
I would start with reading the fix lists for version
after yours. 5.0.19 is not new by any way of
reasoning, so I would search bugs fixed in that branch
after that version number for a starter. Next, are
you doing anything with StringBuffer, char[], Strings
where you are storing them off into a Map or List or
something similar? What are you doing with Session
objects? Are you able to test with a single page
which access some functionality? Does this occur with
every page or do you see memory really growing when
you are hitting certain ones? I think you'll need to
get better information or at least more than this
before you will be able to get useful information from
others without their hands on your environment,
application, and source. If you debug your
application do you see anything that is not cleaned up
during the life cycle of a user (look at any
containers of any kind maps, lists, vectors, arrays,
etc)?
Wade
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org