Is there such a thing as too much memory?

[kjkoster]

Dear All,

Remember when you first opened a command line on a machine with a full gigabyte of RAM? Whoa, sooo much memory. We were talking about ditching swap space in those days. :-) Of course, today multi-gigabyte RAM systems are being sold to grandmothers for surfing and e-mail.

The older versions of Java had a default memory limit of 64MB, which is not a whole lot. I almost always use jconsole to find the typical memory usage of my application and then use the -Xmx command line option (http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp) to give it the memory it needs, plus a reasonable margin. Sometimes I even go in and tune the individual memory pools (scroll down to memory pools) (http://www.kjkoster.org/zapcat/Zabbix_Java_Template.html).

I've always wondered: is it possible to give a JVM too much memory? Imagine I have several gigabytes of memory in a box that does nothing but host a Tomcat instance on a single vm. Why would I not assign 2GB of memory to the JVM?

For development machines I prefer to keep memory tight, so that I get alerted to memory leaks early in the game. But for production machines I don't know.

I have some second-hand anecdotes that claim that too much memory causes longer garbage collector pauses, but that was in the Java 1.3.1 days. How is that for Java 1.5 and Java 1.6? Was it even true for those older VM's?

What is your experience?

Kees Jan

PS. Oh, and as you storm in with an answer, please remember to provide some reliable sources and figures (http://xkcd.com/285/). ;-)

[Barry]

Hi Kees Jan,

It depends on the GC being used, but there is such a thing as too much memory.
Concurrent GC sounds nice until you figure out that it sucks CPU on single core systems, especially when lots of memory is being allocated and collected (webservers fit in this group). In such cases you use the old GC which will stop your system for a longer time (which is fun to watch in a loadbalanced environment as there is always one machine doing it's GC thing while load piles up on other machines :D )

Best thing is to assign what is likely to be enough and monitor memory usage in JConsole, VisualVM or any other JMX/VM monitoring tool and see how the heap behaves.
Are you hitting limits? Also keep in mind that some memory is used outside of the heap and leave enough space for that (for example, Direct bytebuffers are off heap, I believe socket buffers may be too) and the OS will need space as well.
As with everything, YMMV

[sippykup]

Also, don't forget to leave enough room for the native heap. On 32-bit RHEL with 4 GB of RAM, I was never able to go above about -Xmx2300. Although you can push Sun's JVM a bit higher than that, if you're spawning lots of threads, opening lots of file descriptors, or other operations that use the native heap, you'll run out.

[kjkoster]

With native heap, do you mean the kernel heap or the userland process heap in which the Java heap is allocated?

[sippykup]

The latter.

[Tobias]

You can limit the usage of native heap for threads through -Xss.
It's hard to find reliable documentation on this. There is the -XX:ThreadStackSize switch also.
And some say on linux that stack memory is not "taken" until used because it is lazily allocated.

Any pointer to good documentation welcomed.