> -----Original Message-----
> From: Wade Chandler [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 06, 2004 2:55 PM
> To: Tomcat Users List
> Subject: Re: Question about memory
>
> Yang Xiao wrote:
>
> > Hi,
> > I have development set to false and fork to true, tomcat still doesn't
> > release the memory, any ideas?
> >
> > Thanks,
> > Yang
> >
> > -----Original Message-----
> > From: Randall Svancara [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, May 06, 2004 11:32 AM
> > To: Tomcat Users List
> > Subject: RE: Question about memory
> >
> > Just a silly question, but don't you also need to perform some
> additional
> > production configuration in your web.xml by setting fork equal to true
> and
> > developement equal to false. It explains it on this page here:
> >
> > http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jasper-
> howto.html#Production
> > %20Configuration
> >
> > I made some similar modifications and I noticed that tomcat started to
> > release the memory when the server was not as busy.
> >
> > Randall
> >
> >
> >
> > -----Original Message-----
> > From: Yang Xiao [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, May 06, 2004 9:07 AM
> > To: Tomcat Users List
> > Subject: Question about memory
> >
> >
> > Hi list,
> >
> > I have 3 Tomcat 5.0.19 instances running with Apache 2.019 and JK2.
> >
> > I did a simple load testing with JMeter last night and stopped it just
> > before I went home, so right now there's no incoming request whatsoever,
> but
> > TOP still shows heavy memory usage and swapping, it looks like even
> though
> > the load has subsided, Tomcat has not released the memory, what can I do
> > except restart the Tomcat instances to release the memory?
> >
> > I'm not sure if this is a valid question, so I apologize if I seem to be
> > lack of some basic understanding of how things work.
> >
> > Thanks in advance.
> >
> > Also the tomcats are started with -Xms64 -Xmx256
> >
> >
> >
> > Yang
> >
> >
> >
> > Here's the top output
> >
> >
> >
> > 11:01:35 up 2 days, 15:28, 2 users, load average: 0.65, 0.20, 0.07
> >
> > 381 processes: 379 sleeping, 2 running, 0 zombie, 0 stopped
> >
> > CPU states: cpu user nice system irq softirq iowait idle
> >
> > total 1.0% 0.0% 56.1% 0.0% 0.0% 0.0% 42.7%
> >
> > Mem: 513292k av, 505136k used, 8156k free, 0k shrd, 64872k
> > buff
> >
> > 280548k active, 208500k inactive
> >
> > Swap: 1044216k av, 528888k used, 515328k free 7388k
> > cached
> >
> >
> >
> > PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU
> COMMAND
> >
> > 8333 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:02 0 jsvc
> >
> > 8335 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:03 0 jsvc
> >
> > 8337 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:02 0 jsvc
> >
> > 8338 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:00 0 jsvc
> >
> > 8340 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:00 0 jsvc
> >
> > 8570 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8571 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8572 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8573 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8589 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8596 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8601 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8604 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:02 0 jsvc
> >
> > 8607 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:02 0 jsvc
> >
> > 8610 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8612 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8616 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8624 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8631 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8633 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8646 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8684 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:02 0 jsvc
> >
> > 8689 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8692 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:02 0 jsvc
> >
> > 8695 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8697 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8699 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8700 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8703 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8705 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:00 0 jsvc
> >
> > 8707 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8709 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8714 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8717 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8720 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8721 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:00 0 jsvc
> >
> > 8726 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8729 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8731 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8734 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8739 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8741 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8744 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8747 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8751 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8755 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:00 0 jsvc
> >
> > 8758 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:02 0 jsvc
> >
> > 8761 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8764 tomcat 16 0 203M 158M 80744 S 0.0 31.5 0:01 0 jsvc
> >
> > 8926 tomcat 15 0 203M 158M 80744 S 0.0 31.5 0:00 0 jsvc
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
> As far as system memory aquired by the java process goes, this memory
> will not be released, so you want noticed anything different about top
> if your system will actually increase the memory to that value. The VM
> will hold onto this memory for performance reasons. A real indicator if
> tomcat is using all of the allocated memory can be obtained from the
> java call:
> Runtime.getRuntime().freeMemory()
> contrast the long value to the value from
> Runtime.getRuntime().totalMemory()
>
> The JVM max heap option -Xmx=nMB is a function of increasing the maximum
> heap size allowed by the executable. The heap will not be returned to
> the OS, but will be kept by the C runtime. This is a standard C/C++
> memory issue. One can a memory allocation scheme of some type of shared
> memory pool in a C application to perform different tricks for newly
> allocated objects, but the norm is to use the heap (performance is the
> man reason to use the heap). So, as your application creates more and
> more objects the memory will increase and the memory created in that way
> will not be released to the system, thought it may be resuable by the VM
> after it has been garbage collected.
>
> The point is that you can use something like top to try to measure java
> memory performance (necessarily). I haven't used JMeter, but if it can
> give you stats on the internal VM memory usage based on freeMemory and
> totalMemory then that is the best resource.
>
> In java you create an array of chars
> char [] somechars = new char[1000];
>
> this memory is global app memory now and allocated on the heap.
>
> In C one could do something like
> char somechars[1000];
>
> This is not heap allocated memory and will be freed back to the os, and
> will be noticeable in something like top.
>
> I hope that is clear enough for understanding. The main idea is that
> the VM's system memory isn't necessarily the amount of memory being used
> by the java program running inside of it. It is however the amount of
> system memory being used by the JVM. You need to profile your
> application and see how much memory it is having to allocated at
> different times. If you can use more local variables and help get them
> to the garbage collector fast enough then you'll be able to help your
> system memory utilization. The longer the memory is used the more
> likely another thread will have to allocate more heap memory.
>
> Wade
>
Hi,
I'm only doing the load test with a simple jsp page that displays the
session info. So it's not really an application that requires any kind of
memory for processing, however. Here's the manager/status page output for
all 3 tomcat instances after I have stopped the Jmeter test for about 90
minutes:
Tomcat 1
Free memory: 39.15 MB Total memory: 233.49 MB Max memory: 256.00 MB
Tomcat 2
Free memory: 50.17 MB Total memory: 120.99 MB Max memory: 256.00 MB
Tomcat 3
Free memory: 42.38 MB Total memory: 234.49 MB Max memory: 256.00 MB
And output from free -m
Every 2s: free -m Thu May 6
15:41:51 2004
total used free shared buffers cached
Mem: 501 492 8 0 2 9
-/+ buffers/cache: 480 20
Swap: 1019 415 604
My concern is why is tomcat not releasing all these memory and am I doing
something wrong in the configuration that's causing this?
Thanks,
Yang
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
