[prev in list] [next in list] [prev in thread] [next in thread]
List: tomcat-user
Subject: Re: Question about memory
From: Wade Chandler <wchandler () redesetgrow ! com>
Date: 2004-05-06 22:34:02
Message-ID: 409ABD5A.6070703 () redesetgrow ! com
[Download RAW message or body]
Yang Xiao wrote:
>
>>-----Original Message-----
>>From: Wade Chandler [mailto:wchandler@redesetgrow.com]
>>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:rsvancara@adaweb.net]
>>>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:yxiao@ohpp.com]
>>>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: tomcat-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>>
>>>
>>>
>>
>>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: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>
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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic