Hussein Badakhchani’s Blog October 7, 2005 3:24 AM
Before I get a flurry of comments about how the idea of having a single set of GC settings that is optimal for all Java applications is nonsense and farcical let me clarify what I mean by placing some limitations on this statement.
Firstly I will narrow the range of applications that I am talking about to J2EE applications built with a combination of JSPs, Servlets and EJBs, ok so I haven’t narrowed the range much.
Second I am not saying that these settings will be 100% optimal, but that they will probably be good enough. To quantify what I mean I would estimate that the number of major garbage collects over a say a 12 hour period while the application is under moderate to heavy load will be low and more importantly the percent of time spent by the JVM on this activilty will be a around 1% of the time it spends on all the other activity it is engaged in.
Finally these settings have been tested successfully in the field by a number of people and I have tested these setting myself against eight applications in the last year, all with very differernt memory footprints during volume and performance tuning phases. The results have always been very consistent, only today a couple of my colleagues independently came to settings that were very close to these “one size fits all” settngs.
Here they are:
-XX:NewRatio=4
Don’t specify the new size area using XX:NewSize as if you do change your heap size you will also have to remember to change this to keep the proportions allocated in your heap consistant. Specify a ratio instead, 4 is about right 2 it pointless as you will end up doing full GCs all the time.
-XX:SurvivorRatio=4 -XX:TargetSurvivorRatio=80
You can play around with these but settings in order to find an optimum for your JVM. Make sure you use jvmstat to monitor the imapct of your experiments, the visualgc is useful for this purpose.
-XX:PermSize=128m -XX:MaxPermSize=128m
Unless your getting memory errors or your application is being profiled by a tools that rely on bytecode analysers you probably won’t need more than 128m of perm space. Use jvmstat to capture your applications total memory footprint.
-Xnoclassgc -XX:+DisableExplicitGC
You knows it makes sence to stop WLS or application code trying to incite unnecessary GC by calling GC directly. Leave GC it to the JVM!
I leave it up to the reader to find applications that make a mockery of these settings!
#1 by admin on November 28, 2009 - 11:26 am
A collegue sitting opposite me has just pointed out that in general a heap size larger than 1.5GB is counter productive, this should be mentioned.
Posted by: hoos on October 7, 2005 at 3:56 AM
#2 by admin on November 28, 2009 - 11:26 am
This is a great article. You will have to update this when the new deterministic GC features come out.
Posted by: wgroth2 on October 7, 2005 at 6:50 AM
#3 by admin on November 28, 2009 - 11:27 am
Thanks Bill, as soon as I get a chance to test out the new features I publish the results here.
Posted by: hoos on October 7, 2005 at 11:13 AM
#4 by admin on November 28, 2009 - 11:27 am
Is that 1.5 limit really real? I heard that ages ago – does it still apply?
Posted by: jonmountjoy on October 7, 2005 at 11:39 AM
#5 by admin on November 28, 2009 - 11:27 am
Hello Jon,
I think in most cases it’s wise to avoid larger heap sizes even if new GC implementations can handle them for two reasons.
1. A large heap full of small objects that have short life spans (probably the most common scenario) will mean that it takes a longer for the GC thread(s) to determine which objects to mark for GC. As a result any gains you may have from less collections due to your large heap may be lost. I’m sure that there are some GC algorithms and implementations that this rule does not apply to (it would be great if someone could comment on this with a few links) but in most cases it holds true.
2. Instead of having a large heap why not have a second instance of WLS running instead. In the majority of cases this appraoch will be more beneficial. I think I read that in the BEA administrators documentation and from my own experience it makes sense.
Posted by: hoos on October 7, 2005 at 1:53 PM
#6 by admin on November 28, 2009 - 11:27 am
I am trying to setup visualgc to connect to weblogic (8.12). How can i dtermine the prot and JVMid?
Posted by: haseebtoor001 on August 30, 2006 at 1:40 AM
#7 by admin on November 28, 2009 - 11:27 am
I am attempting to have Sun Application Server run on top of JRockit and have the following issue:
In the Domain.xml I have:
-server
-Xms1g
-Xmx1g
-XX:NewRatio=4
-XX:PermSize=128m
-XX:MaxPermSize=128m
But in the Server.log I get:
[WARN ] ‘-XX:NewRatio=4′ is not a valid VM option. Ignoring.
[WARN ] ‘-XX:PermSize=128m’ is not a valid VM option. Ignoring.
[WARN ] ‘-XX:MaxPermSize=128m’ is not a valid VM option. Ignoring.
Any thoughts as to why the options are not valid?
Thanks,
Brad
Posted by: BBakerAtNGC on September 26, 2006 at 11:59 AM
#8 by admin on November 28, 2009 - 11:28 am
Brad, you should really be posting this question to the newsgroups, see my latest blog entry!
Anyway the options I have provide don’t all apply to JRocket VM. My understanding is that JRocket stores class related data on the heap and thus the does not have any need for perm memory. Just drop the perm memory options for JRocket.
Posted by: hoos on September 26, 2006 at 1:50 PM