You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Ing. Damiano Bolla" <da...@infotechsrl.it> on 2002/09/27 17:19:43 UTC
Re: AW: Tomcat 4.1.12 memory leak, resources leak, final call ?
Let me repeat, once more
I am reloading the DEFAULT installation page of tomcat.
I am NOT using my own page.
I am NOT testing a weird servlet.
Just the DEFAULT tomcat page. (the one that comes right after you have
installed tomcat)
----------------
Sorry for the capital letters above, I would like to say that
1) I understand the GC concept and heap, BUT there is something wrong if
reloading the same page eats all the ram.
2) Thanks to everybody that are tryng to help, BUT please read the mail
before posting a reply.
3) Is there one that does NOT have my same problem by doing EXACTLY what I
am doing ?
If there is one please send me your setup and I will adopt it.
Thanks.
At 17.04 27/09/2002 +0200, you wrote:
>- The memory that a vm uses is never decreasing (At least I don't
> know any that behave that way)
> To understand that you have to see two different things:
> - the memory that is used by the vm
> - the memory inside the vm
> All vm's that I know, don't return memory to the os. What
> happens during a gc is just that inside the vm the memory is
> marked as free. So the only save indicators for the question
> 'how many memory is currently in use' are the methods
> java.lang.Runtime.get*Memory.
>- To a certain degree it is normal that the memory is increasing.
> Reasons for that:
> - each session needs some memory, that is only released after
> the session has timed out. If you create sessions very fast
> this can consume quite some memory. (If you are creating
> the sessions faster as they dye tomcat will die with an out
> of memory error.)
> - Just because an object isn't used anymore , is dosn't mean
> that the memory that is consumed by it is freed. This just
> happens, when the garbage collector runs. When this will
> happen, is up to the VM. Until then the memory will grow.
> There is nothing you (or tomcat) can do about that from
> inside the application. The only action that has affect,
> is to play with the various parameters for the garbage
> collector as argument to the java process.
>
>So what can you do, to track the problem down:
>- Make shure that the request don't create new sessions.
> (There are several routes how to achieve that)
>- Strip the page that you test down to a minmal jsp.
> (I haven't seen in your previous posts that
> you say anything about the nature of this page)
>- Track the memory usage with java.lang.Runtime.get*Memory()
>- Use the java options to achieve a verbose gc
>- Set the maximal heap size to a lower bound, to see
> what happens when this value is reached.
>- Profile the application with OptimizeIt or jProbe
> or any other profiler.
>- show us your page, maybe it's the page that contains the
> memory leak
>
>Sun has some background and advice at:
>http://java.sun.com/docs/hotspot/gc/
>http://java.sun.com/products/hotspot/whitepaper.html
>
>Also javaworld:
>http://www.javaworld.com/javaworld/jw-01-2002/jw-0111-hotspotgc.html
>
>
>Ralph Einfeldt
>Uptime Internet Solution Center GmbH
>Hamburg, Germany
>Hosting, Content Management, Java Consulting
>http://www.uptime-isc.de
>
> > -----Ursprüngliche Nachricht-----
> > Von: Ing. Damiano Bolla [mailto:damiano@infotechsrl.it]
> > Gesendet: Freitag, 27. September 2002 16:13
> > An: Tomcat Users List
> > Betreff: RE: Tomcat 4.1.12 memory leak, resources leak, what to do ?
> >
> >
> > Yes, I did let it run and it keeps eating.
> >
> > As far as I see this IS a problem.
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: AW: Tomcat 4.1.12 memory leak, resources leak, final call ?
Posted by Ricky Leung <ri...@booksense.com>.
> My recommendation is to stop trying to make sense of the output from top
> and ps, and go to an unambiguous source. Take a look at the contents of
> /proc/<pid>/status, where <pid> is the process ID. This will, at
> any instant
> you examine it, give you (among other things) total current VM usage and
> RSS.
The files under <pid> doesn't seem to be readable, how should I read it? My
OS is Solaris.
Thanks.
Ricky
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AW: Tomcat 4.1.12 memory leak, resources leak, final call ?
Posted by Luciano Kiniti Issoe <mi...@hotmail.com>.
Hi,
don't worry about that. It's just that top doesn't show exactly what's going
on inside the VM. It WON'T crash your machine. When tomcat hits the limit of
the amount of memory allocatted to it, it'll stop increase. It's not a bug.
If you want to know how much memory Java is using, Nathan Meyers
<nm...@javalinux.net> suggests this approach:
My recommendation is to stop trying to make sense of the output from top
and ps, and go to an unambiguous source. Take a look at the contents of
/proc/<pid>/status, where <pid> is the process ID. This will, at any instant
you examine it, give you (among other things) total current VM usage and
RSS.
Regards
miagi
----- Original Message -----
From: "Ing. Damiano Bolla" <da...@infotechsrl.it>
To: "Tomcat Users List" <to...@jakarta.apache.org>
Sent: Friday, September 27, 2002 12:19 PM
Subject: Re: AW: Tomcat 4.1.12 memory leak, resources leak, final call ?
Let me repeat, once more
I am reloading the DEFAULT installation page of tomcat.
I am NOT using my own page.
I am NOT testing a weird servlet.
Just the DEFAULT tomcat page. (the one that comes right after you have
installed tomcat)
----------------
Sorry for the capital letters above, I would like to say that
1) I understand the GC concept and heap, BUT there is something wrong if
reloading the same page eats all the ram.
2) Thanks to everybody that are tryng to help, BUT please read the mail
before posting a reply.
3) Is there one that does NOT have my same problem by doing EXACTLY what I
am doing ?
If there is one please send me your setup and I will adopt it.
Thanks.
At 17.04 27/09/2002 +0200, you wrote:
>- The memory that a vm uses is never decreasing (At least I don't
> know any that behave that way)
> To understand that you have to see two different things:
> - the memory that is used by the vm
> - the memory inside the vm
> All vm's that I know, don't return memory to the os. What
> happens during a gc is just that inside the vm the memory is
> marked as free. So the only save indicators for the question
> 'how many memory is currently in use' are the methods
> java.lang.Runtime.get*Memory.
>- To a certain degree it is normal that the memory is increasing.
> Reasons for that:
> - each session needs some memory, that is only released after
> the session has timed out. If you create sessions very fast
> this can consume quite some memory. (If you are creating
> the sessions faster as they dye tomcat will die with an out
> of memory error.)
> - Just because an object isn't used anymore , is dosn't mean
> that the memory that is consumed by it is freed. This just
> happens, when the garbage collector runs. When this will
> happen, is up to the VM. Until then the memory will grow.
> There is nothing you (or tomcat) can do about that from
> inside the application. The only action that has affect,
> is to play with the various parameters for the garbage
> collector as argument to the java process.
>
>So what can you do, to track the problem down:
>- Make shure that the request don't create new sessions.
> (There are several routes how to achieve that)
>- Strip the page that you test down to a minmal jsp.
> (I haven't seen in your previous posts that
> you say anything about the nature of this page)
>- Track the memory usage with java.lang.Runtime.get*Memory()
>- Use the java options to achieve a verbose gc
>- Set the maximal heap size to a lower bound, to see
> what happens when this value is reached.
>- Profile the application with OptimizeIt or jProbe
> or any other profiler.
>- show us your page, maybe it's the page that contains the
> memory leak
>
>Sun has some background and advice at:
>http://java.sun.com/docs/hotspot/gc/
>http://java.sun.com/products/hotspot/whitepaper.html
>
>Also javaworld:
>http://www.javaworld.com/javaworld/jw-01-2002/jw-0111-hotspotgc.html
>
>
>Ralph Einfeldt
>Uptime Internet Solution Center GmbH
>Hamburg, Germany
>Hosting, Content Management, Java Consulting
>http://www.uptime-isc.de
>
> > -----Ursprüngliche Nachricht-----
> > Von: Ing. Damiano Bolla [mailto:damiano@infotechsrl.it]
> > Gesendet: Freitag, 27. September 2002 16:13
> > An: Tomcat Users List
> > Betreff: RE: Tomcat 4.1.12 memory leak, resources leak, what to do ?
> >
> >
> > Yes, I did let it run and it keeps eating.
> >
> > As far as I see this IS a problem.
>
>--
>To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
>For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>