This week's book giveaway is in the Agile and other Processes forum. We're giving away four copies of The Mikado Method and have Ola Ellnestam and Daniel Brolund on-line! See this thread for details.
Personally, I have used an -Xmx as high as 300g (with the Azul JVM). This was restricted by the size of the hardware, of course.
Gagan Tiwari wrote:
Can I pass value as big as 35-40 GB?
Also, keep in mind of the garbage collector. It doesn't scale very well, and will, with all the current Sun implementations, pause for minutes, at that heap size. This will break most applications (database and other network timeouts).
So what is the parametr in the hardware by which we can actully come to a figure of maximum alloowed value in heap memory?
Gagan Tiwari
Ranch Hand
Joined: Jun 10, 2008
Posts: 68
posted
0
Just to add on top of the post..
I was using sun 1.6_16 which was 32 bit...and there I was not allowed to pass value greater than 4 GB I suppose..
When I upgraded it to 64 Bit then I am able tyo pass value as big as 8 GB..
now the application needs are such that it requires value as big as 40GB,.
So just wanted to know if at we can keep the heap memory as 40GB?
and if yes than what all things can go for a toss...like one point (as stated above in the post) stating that garbage collectioon will take some time and so oracle connection can be timed out
Gagan Tiwari wrote:
So what is the parametr in the hardware by which we can actully come to a figure of maximum alloowed value in heap memory?
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.
Again I forget the specifics, but I recall it was like 1.5gb for 32bit windows and 2.0gb for linux, but in our experience the actual value was slightly lower due to other restrictions.
This is why I said 1200Mb (on a 2Gb machine) earlier.
Henry Wong wrote:It may depend on the JVM, but I believe (if memory serves correctly) that the maximum heap size for a 32 bit JVM is 1.5 gb.
Actually it isn't the JVM that's imposing this limitation - it's Windows. 32-bit Windows simply doesn't (easily) allow processes to use more than 1.5GB. I encountered the same problem on a server, and installing a 64-bit Windows and 64-bit JVM on it allowed 3-4GB to be used. Well, it actually allowed several dozens of gigabytes in a little test program.
0
