1 of 1 people found this helpful
There is no recommended heap size because the heap size that is best for you depends entirely on your application, now it behaves, and what its needs are. JBoss AS itself can work with a very small heap - I recall helping one customer try to force an OOME with a SOAP web service deployed, we had to get the max heap size down to 32MB before we got the error. But generally a 1GB to 2GB heap seems to work well for most applications. But some applications require even a larger heap. As, which GC algorithm you use will determine what heap sizes are usable. The CMS and G1 collectors thrive on very large heaps, the default collector can have issues (huge GC delays) if your heap is too large.
The only way to properly size your heap is to turn on GC logging and do a load test simulating production workloads. If you cannot do that, then turn on GC logging in the production environment. Once you have the logs (a busy days worth in production should do it) you can analyze the logs and from there determine the optimal heap size.
For suggestions on how to gather GC data and analyze it, see these white papers:
Java Garbage Collection Statistical Analysis 101
Java Garbage Collection Performance Analysis 201
Java Garbage Collection Analysis using R
Thanks! I will try the papers.
If you really have 24 GB RAM, and Jboss AS is the only application running , it better you install vm-ware on top of the physical m/c and divide it into 2 to 4 nodes and enjoy clustered/HA environment, rather than increasing the heap size to a ridiculous size.
"GC pause" is the term you may be interested to google.
Thanks for the additional information; in my case, the machine is already part of a clustered ha configuration. I really don't know yet how much memory jboss will need, but on the same machine we have also a web server, so I thougth I might start allocating 10GB to jboss and leave the rest for the web server. But I still have to gather a better understanding of this matter. I have already found several places where it is suggested not to use too much memory, but none of them provided an explanation. In fact, you too seem to have the same idea...is there a boundary somewhere over which the heap size can be considered 'ridiculous'?
1 of 1 people found this helpful
as I already said, please look at "GC Pause" and its side-effects. If your needs are ok with it allocate as much as you want, there is no technical restriction.
The reason you didn't find any thumb-rule value is b'coz there is none.
Few things you should consider:
1. Max concurrent requests to be handled
2. Use j-console to see the use of the Survivor space in PS Young & then the old gen + perm gen [Practically this becomes the -Xms mostly]
3. What is your classloading footprint? [If your footprint is very large drop of subsystems which you do not use] [JBoss AS7 Tuning and slimming subsystems]
4. The applications that will run on jboss, does they require session management.
and the list goes on....
Any heap size larger than what you need is excessive. Do this: give your app a really large heap, say 10GB, and monitor the GC activity as indicated in my white papers. Take particular note of the heap size after the major collections - at some point your app will achieve a "steady state" where the heap size after a major GC will be fairly constant. Take that value, multiply it by 4, and use that value for your heap size. For example, you notice that after several; hours that the heap after major GC is around 500MB; set your heap to 2GB.
Also, with a really large heap, consider using the CMS or G1 collector. But only if you have at least 4 cores, which on a machine of this size I suspect you have. Those collectors will reduce the dreaded GC pause time. Also, those collectors will require a larger heap - I'd multiple the steady state by about 6 or more, thus I'd use 3GB or perhaps 4GB in my example.
Thanks a lot Peter! I will need some time to read the papers; I will follow your suggestions and see what I come up with.