there isn't one configuration which fits all applications- you have to investigate with a profiler (or any shell utility) how much memory is required by the JBoss process. This is the easiest part because you have to find what's the peak of memory of your application when it's stressed- then add a raw 20%-30% extra as -Xmx parameter.
When you're done with this you can futher investigate on the optimal Young/tenured generation and other in-depth settings.
Hope it helps
Sorry, the machine is 64 bit.
Yes, your info helps.
But if the machine is just 32 bit, do you think is it meaningful to set the -Xmx more than 2GB? Bcz the server and the os will take some memory.
Btw, do you know good references about configue or optimate the Young/tenured generation and other in-depth settings?
To add in one more comment - for production systems I always recommend that the heap min and max are set to the same size. The reason is that in a production environment, if you set the min and max to different sizes, you will find that over the course of time the heap will grow to the maximum size and stay there, so why not just set the heap size up front?
In a development environment your should set the min and max to different amounts, This way the JVM will not be taking more memory than it needs because on a dev machine your are running a lot of things other than just JBoss AS.
time ago I've read about a benchmark where setting -Xms and -Xmx (in production) is not considered any more a best practice. Unfortunately I haven't bookmarked it. I think that shorter collection frequency and sizes was the determinant factor in this benchmark. I'd like to check this affirmation with the new G1 Collector available since Java SE 6 Update 14. Should I find any useful info I'll post if here.
The link is very useful. Many thanks to all.
I could see where the G1 collector would benefit from having min and max not being the same, but then it operates very differently from other collectors - it actually concerns itself with garbage while all of the other collectors ignore garbage.
But note that I couched by recommendation in terms of observed JVM behavior - if the JVM spents the first 10 or 15 minutes of the run slowly increasing the heap to the maximum size and then leaves it there for the rest of the run (and app servers have long run time, usually in days, weeks or months), setting min to less than max seems like a waste of effort because for all intents and purposes the JVM is running at max heap size for the vast majority of the run.
Besides, anyone can come up with a benchmark that shows having min and max set to different sizes is a benefit. And I have seen many such benchmarks with such claims. The big question is: how long does that benchmark run?