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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
