Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4F3E6C52.5030001@christopherschultz.net>
Date: Fri, 17 Feb 2012 10:03:46 -0500
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Free Memory vs. Total Memory vs. Max Memory
References: <768FEA3F936926468F594E3CA7741FE803BD6031@ipa-vault.nvipa.com>
 <4F3E0FAF.60309@ice-sa.com>
In-Reply-To: <4F3E0FAF.60309@ice-sa.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eric,

On 2/17/12 3:28 AM, André Warnier wrote:
> Robinson, Eric wrote:
>> What are the possible downsides of setting a low initial memory
>> pool and a high max pool? If a tomcat app usually needs
>> approximately 64MB of heap space, but sometimes as much as
>> 300-400MB, would it cause any problems to set the initial pool to
>> 16M and the max pool to 512M?
>> 
> It depends... ;-)
> 
> If you set different values to -Xms (at start) and -Xmx (maximum),
> then the JVM will spend some amount of time allocating and
> de-allocating Heap memory dynamically as needed, to stay within
> these boundaries. If they are equal, then the JVM allocates it at
> start, and never has to worry about it later. If your application
> needs 64MB of Heap space and you allocate only -Xms16M, then right
> at the start the JVM will have to increase the Heap to 64MB
> (minimum); so why would you do that ?

I'll add a bit to André's comments:

I can see the lure of "only taking what you need" and allowing the JVM
to automatically re-size the memory space: that way, you only take up
a huge chunk of memory during peak load and not all the time.

But why?

If you are going to need, say, 512MiB at peak load, you're going to
need that memory available whether or not it is allocated to the JVM
itself at any given time. If that's the case, why not let the JVM have
that memory all the time? Freeing the memory manager from having to
re-size the heap (and that means re-sizing the various pools within
the entire heap as well) will definitely improve your performance.

Remember that "giving back" memory to the OS isn't as simple as just
drawing a line at the top of the heap and chopping-off the empty top:
each pool must be re-sized to its new size, moving objects around all
over the place so that the top of the heap is empty and *then*
releasing the memory.

It used to be that the JVM would never release memory it had claimed,
so if you have -Xmx512M and you hit that limit at peak load, then your
heap would never go smaller than that. I don't know if it's the case
any longer because I always set Xms=Xmx so that I don't have the
memory manager wasting all that time.

Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8+bFIACgkQ9CaO5/Lv0PBcegCgmE1OHDV2djU0MXY3vRggaNnZ
YhMAn2prZeN9RjC5MTUfDC+KKS2aGCSz
=EGpQ
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org