tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Caldarale, Charles R" <Chuck.Caldar...@unisys.com>
Subject RE: Setting the Right Amount of Memory
Date Thu, 24 Jun 2010 19:26:40 GMT
> From: Mark Thomas [mailto:markt@apache.org]
> Subject: Re: Setting the Right Amount of Memory
> 
> So what is the impact say (picking some random numbers of the air) if
> you have an app that is quite happy with 256MB of heap space but has
> 1024MB allocated?

Probably unmeasurable, assuming the larger heap has not pushed the OS into paging.

> I understand from what you have written that for the
> young gen there isn't much impact

Zero impact, actually.

> but what about the old gen when there is a full GC?

Since a full GC is a relatively rare event, and having a significant number of unreachable
objects in the tenured generation is even rarer, the effect is negligible.

> Does the fact that there is (roughly) 700MB of additional
> dead objects slow down the full GC

There aren't really 700 MB of dead objects when a full GC kicks in.  That occurs when a survivor
space is full, and there's no more room to copy objects to it from the eden space.  At that
point, the scan of the tenured generation space occurs, which will normally encounter only
a few dead objects.  (Note that it's the number of dead objects, not the size, that's of any
interest here.)  The eden space, where nearly all the dead objects are, does not have to be
scanned for empty areas.

> and if so, is it significant?

Probably not, unless you've got a really strange app.  Doing some testing with a fairly trivial
program to create lots of short-lived objects and a fixed number of cycled long-term ones
shows that a larger heap improves the "throughput" of iterations, but does plateau after a
bit.

Let's see if a .java attachment makes it through... (if it doesn't and you want a look at
it, let me know and I'll e-mail it directly).

Sample output from running on my 2 GHz, dual-core, 4 GB laptop:

C:\JavaUtil>java -Xms32m -Xmx32m TestGC 100000000
total objects: 100000000, objects to keep: 1000, keep interval: 1000, object size: 1000
14:07:56.203 -> 14:08:58.869
1595761.657 objects per second

C:\JavaUtil>java -Xms32m -Xmx32m TestGC 100000000
total objects: 100000000, objects to keep: 1000, keep interval: 1000, object size: 1000
14:09:06.209 -> 14:10:09.995
1567742.137 objects per second

C:\JavaUtil>java -Xms512m -Xmx512m TestGC 100000000
total objects: 100000000, objects to keep: 1000, keep interval: 1000, object size: 1000
14:10:27.605 -> 14:11:25.914
1715001.114 objects per second

C:\JavaUtil>java -Xms512m -Xmx512m TestGC 100000000
total objects: 100000000, objects to keep: 1000, keep interval: 1000, object size: 1000
14:11:35.517 -> 14:12:33.195
1733763.306 objects per second

C:\JavaUtil>java -Xms2g -Xmx2g TestGC 100000000
total objects: 100000000, objects to keep: 1000, keep interval: 1000, object size: 1000
14:12:57.895 -> 14:13:55.462
1737106.328 objects per second

C:\JavaUtil>java -Xms2g -Xmx2g TestGC 100000000
total objects: 100000000, objects to keep: 1000, keep interval: 1000, object size: 1000
14:14:01.601 -> 14:14:58.758
1749566.982 objects per second

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus
for use only by the intended recipient. If you received this in error, please contact the
sender and delete the e-mail and its attachments from all computers.

Mime
View raw message