Chris,

We have 100+ application servers in a loadbalancing (application based, not tomcat) setup. If servers are removed from the load balancing pool the others need to be able to pick up the load. So the number of concurrent users is highly dynamic. You can imagine the problem if we keep the heapsize to a minimum on every server. I'm talking about a fixed size here ofcourse.

I also don't think the relationship between number of objects and young gc duration is a linear one.

Increasing the young generation leads to longer gc's. Increasing young to 682M on a 4G heap from its default size increased gc time approx. 3-4 x (47ms average to 154ms average on one server), but it also decreased the number of gc's performed by 15-20x. So eventually, a larger heapsize saved cycles, and subsequently increased throughput. At least for us.

I think it also gives short-lived objects (for example short sessions) a longer time to 'die out', so they won't be moved to tenure because survivor space is increased and gc frequency is decreased (can anyone confirm this?).

Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Taylan,

On 3/5/2009 5:11 AM, Taylan Develioglu wrote:
I always hold this as a ground rule:

Increase heapsize as much as possible as long as:

My rule has always been to run with the smallest heap you can get away
with. We ran our main production app in 64MB of heap (the default for
our platform) for 4 years before we got our first OOME. Now we run it
with a 192MB heap.

A smaller heap means that you'll catch even small memory leaks faster.
At least, that's my position.

Surprisingly, Chuck hasn't responded (he usually has something to say
about GC/heap myths), but I suspect he'd say something like "heap size
itself has little effect on the GC's performance... it's really the
number of objects that affect the performance. Granted, a larger heap
invites more objects into it, but generational garbage collection is
decent enough that the generations rarely grow to such a size that the
app stalls while the GC runs."

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkm2fBAACgkQ9CaO5/Lv0PCPngCfRfClYEVoDAI57VBbqoBUaAC8
RDAAn0fztUgMY0d0K0FAdV0uxYzSjDxN
=EbMZ
-----END PGP SIGNATURE-----

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



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

Reply via email to