– Aim to set as low as possible
– Setting too high can cause wasted memory and long GC cycles
I don’t really have a simple answer for you, but here are some things to keep in mind…
1. Never use swap for the JVM…. I repeat. NEVER use swap for the JVM. The garbage collector is the worst case scenario for swap. It touches all memory, and specifically targets the least recently used memory. The garbage collector will take hundreds, perhaps thousands, times longer to do it’s job.
2. Don’t go over 4 gb of heap for the Sun JVM. I have actually seen it as high as 9 gb, but that had dozens of gc related -XX flags, tuning it for the exact application. And even then, it would sometimes fall over during the day. The garbage collector just doesn’t behave very well at high heap sizes.
3. You can have higher heap sizes if you use the JVMs with better GC implementations — such as the newer JRockit, IBM version (whose name escapes me), the new Sun JVM (which I don’t think is out yet). These JVMs could probably give you better performance, and hence, bigger heap sizes. And of course, if you use the Azul JVM (with its pauseless GC), you can have a heap a big as you have the memory for.
As for sizing…
4. In general, the JVM will size the stack memory area to be about 1/4 the size of heap. This means, with a 4GB heap, you will need an additional 1GB for the stack area, and whatever memory needed for the JVM itself. With some JVMs, it is possible to size the stack space too.
Personally, I think it is best (if you want to use all the memory), is to simply try it, using this as an estimate. If it works, great. If it doesn’t, try a smaller heap size.
また、http://www.oracle.com/technetwork/jp/ondemand/application-grid/wls11g-pt-201107-otn-sc-439533-ja.pdfによると、xmxとxmsの値は、Long Lived Objectsのサイズの3倍程度に設定することがベストプラクティスだそうだ。