- Strings are allocated to decode the request. - Writers/OutputStreams are created to print to. - Sockets are created - .. other under the covers stuff I'd prefer not to know
All of these allocations occur on EVERY request. But they are not immediately garbage collected (gc'd) on every request. The GC only runs when it feels like it. Unless you REALLY know what your doing - tweaking the behavior of the garbage collector is not a good idea. There is no way to fix it because that is how the JVM works. If you need to restrict the size of your JVM - look into the startup parameters. java -X will give you the available parameters. Ing. Damiano Bolla wrote: > Good explanation but it does not solve the problem. > Let me try to be clear. > > - What I am doing is reloading always the same page. > - What I see is an ever increasing consumption of memory. > > Really why should the JVM want more and more ram ? > > In any case if you keep reloading, this ever increasing consumption > eventually will eat all your ram. > Whatever is the explanation it does not seem right to me, is there a way > to fix it ? > > Damiano > > > > > > At 09.29 26/09/2002 -0400, you wrote: > >> Each request allocates memory. (And relinquishes accordingly) The >> garbage collector runs when "it feels like it should". The JVM will >> continually suck up memory until it reaches its startup parameters. >> (-mx ...) >> >> Once a JVM takes memory from the OS - it does not release it to the OS >> - it only releases it to its own memory heap. >> >> Ing. Damiano Bolla wrote: >> >>> System: Linux redhat 7.2 >>> Java: /usr/local/j2sdk1.3.1 >>> Tomcat 4.1.12 >>> To reproduce the behaviour you install the 4.1.12 distribution, set >>> the JAVA_HOME run startup.sh and then keep refreshing the homepage >>> http://localhost:8080/ >>> If you monitor the memory usage using top and switching it into >>> display memory usage (Capital M) you sull see tipically something like >>> 22824 >>> 22832 >>> 22840 >>> 23576 >>> 23676 >>> 23684 >>> 23904 >>> 23908 >>> 23934 >>> 23938 >>> ..... >>> This is the SIZE field of the top command. >>> The point is that it never goes down and eventually you run very slowly. >>> Any idea ? >>> Ah, the same behaviour is with jdk 1.4.1 >>> Damiano >>> >>> -- >>> To unsubscribe, e-mail: >>> <mailto:[EMAIL PROTECTED]> >>> For additional commands, e-mail: >>> <mailto:[EMAIL PROTECTED]> >>> >> >> >> -- >> To unsubscribe, e-mail: >> <mailto:[EMAIL PROTECTED]> >> For additional commands, e-mail: >> <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
