> -----Original Message----- > From: Wade Chandler [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 06, 2004 6:34 PM > To: Tomcat Users List > Subject: Re: Question about memory > > Yang Xiao wrote: > > > > >>-----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] [Yang Xiao]
Hi, Many thanks for the info! I will read the article and see if I can put all these together. Yang --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
