-----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]
Maybe I wasn't very clear. I should have said...
Java unlike C++ always allocates objects on the heap (though many C++ developers allocate a lot on the heap as well). So, the memory the java VM is using is heap memory. The heap is never given back to the OS unless explicit steps are taken.
I didn't want to get into this necessarily because it may or may not help you. Performance and memory play hand in hand, so you may find an option that resizes your heap, but affects other performance measures......with that said
You can use some things from this page to play with memory and see if it helps you out. If you are going to have many users however, it is best to let the heap keep a size it reaches. That way the VM isn't allocating memory from the OS and it is able to perform as best as it can.....this is of course for 1.4.2 I think 1.4.1 as well...not sure how tomcat acts with these settings though
http://java.sun.com/docs/hotspot/gc1.4.2/
You want to look at
-Xms
-Xmx
-XX:MinHeapFreeRatio
-XX:MaxHeapFreeRatio
However....about your system...
Notice that the free memory (java related free memory) is low in your processes, so that is fine. Tomcat is using a normal amount of memory for the tomcat server in those cases. The JVM is almost using it's max heap which you have it set which is 256MB. Tomcat will use roughly 40MB+-5 (this has been my observation, and is observed in your free memory stats as well). The heap allocation is a function of the JVM.
I don't know what types of tests JMeter does or does not perform, and I'm not sure what type of JSP tests you are running, nor what types of manager applications come with JMeter. I notice you mention the simple JSP tests with sessions, but what types of objects are you allocating?
Tomcat also allocates objects for a request. You have session objects, request objects, and things like this. You have memory taken by the query string and any post data. These all use memory. These objects don't stay in memory after they are no longer referenced and have been collected, but the heap memory that may have been allocated for them is kept by the process and not given back to the OS.
This is normal. This is what you are seeing in your free dump. I like to use top and then do SHIFT-M when it starts. Notice field RSS which is the memory used per process in descending order. That's a preference of course.
But, as far as your memory goes this seems normal. Are you using -Xms (initial heap size) flag in your catalina.sh file in your JAVA_OPTS variable? If so what is it set to? Is your test hitting the server very hard....like you keep hitting a jsp page making it create Request, Session, Response, and other instances of objects over and over again very quickly?
These are just some questions relating to why your heap is growing to the size that it is. As far as tomcat goes....it's only using the normal amounts of memory on your machine around 40MB.
I hope that is a little clearer. The heap has to be growing for one reason or another usually utilization, but the settings from the URL I gave you should sum it up a bit. If you have your
-XX:MinHeapFreeRatio=70
-XX:MaxHeapFreeRatio=40
You will notice some resizing to which you are asking for I think, but the performance may be worse than you would expect because the VM will be doing some things that take up resources and keep it from doing what it needs to do. If you don't think you are going to be using that much memory in your server you could set -Xmx128m but again...if you use more than this in one instance it will bomb with out of memory errors unless a GC will free up it's memory. The vm will attempt to collect before breaking.
The best thing to do is to read up on the java heap and memory in that article. If you don't understand it I would recommend not changing it. If you understand it and think you have a solution that is what you want to do then you should be good to go.
Anyways,
hope that helps you out some.
Wade
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
