NewGen can sometimes be a problem. The temptation with 64 bit is setting a
large initial heap size -Xms4096m. This can be quite fine however can lead to
problems in JVM performance since the JVM is not making good decisions how to
size the New Generation (which is made up of Eden and two survivor spaces).
What is the problem? Sometimes the NewGen starts out so large that a minor
Garbage Collection will try move large size objects in the Survivor Space and
the OldGen can not fit it right away.
Just to simplfy that a bit to draw a mental picture, say the OldGen is 4Gb in
size currently and 3.xGb used. A NewGen that is not well configured can have a
1Gb survivor space. The minor GC tries to tenure the 1Gb however it does not
fit in the <1Gb free space. Well what can happen some more of the heap could be
virtually committed or a major GC can run to try clear the OldGen. I am over
simplifying there however I hope you can see that can have an impact on your
performance.
The same situation can also apply on 32 bit where values like âXms1024m
âXmx1024m are set in JVM args that is a relatively large tenure of objects in
survivor space may not fit in to uncommitted OldGen space. Usually JVM will end
up making better decisions about the NewGen however till then there are some
performance hits.
So how to overcome that? Well JVM logging is one way another might be to use
JDK tools like jconsole or jvisualvm to see if JVM NewGen is making poor
decisions about sizing. Perhaps donât want to LOG or run JDK tools OK. Some
say use XX:NewRatio switches I like to use âXmn (some Java sources say not to
use Xmn). So that would make your JVM.CONFIG look this following. The Xmn value
may depend sometimes somewhere 96m to 348m or more would really need some
logging / JDK tools to be sure.
JVM.args=-server -Xms4096m -Xmx8192m -Dsun.io.useCanonCaches=false âXmn148m
-XX:PermSize=1024m -XX:MaxPermSize=1024m etc
HTH, Carl.
> Hi everyone,
>
> thanks for all the good feedback.
>
> Let me first tell you WHY I think its a JVM issue, then show you what
> results I have had.
>
> We took the exact same code, and connected it to the exact same DB
> (and DB
> server) and ran the exact same code in isolation. The comparison was
> outstanding about 2s on the old machine and 10s as you have seen on
> the new.
>
>
> The connection between the SQL and both web machines pinged at <1ms
>
> We tried the connection from various locations and ruled out network
> issues
> (although there could be ). We looked at execution times and logged
> the
> information pretty heavily in the intensive parts of the app and saw
> that,
> on comparison between machines the differences. Given that, and the
> isolation tests, the only thing we could see that was different was
> the JVM
> settings, thus the conclusion we came too.
>
> so having taken some of the suggestions into account I have ended up
> with
> this setting:
>
> java.args=-server -Xms4096m -Xmx8192m -Dsun.io.useCanonCaches=false
> -XX:PermSize=1024m -XX:MaxPermSize=1024m
> -Dsun.rmi.dgc.client.gcInterval=150000
> -Dsun.rmi.dgc.server.gcInterval=150000 -XX:+UseParallelGC -Xbatch
> -Dcoldfusion.rootDir={application.home}/
> -Djava.security.policy={application.
home}/> servers/cfusion/cfusion-ear/cfusion-war/WEB-INF/cfusion/lib/coldfusion.
> policy
> -Djava.security.auth.policy={application.
home> }/servers/cfusion/cfusion-ear/cfusion-war/WEB-INF/cfusion/lib/neo_jaas.
> policy
>
> This puts us at an execution time parallel to the old 32 bit machine,
> down
> at 1.5-2 seconds. while this is a vast improvement I would hope that
> more
> gains could be had out of tuning the JVM some more. I will tweak the
> GCinterval and the permSize tomorrow night and see if there is an
> incremental gain to be had.
>
> Any other suggestions would be great!
>
> Thanks.
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Order the Adobe Coldfusion Anthology now!
http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion
Archive:
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:342362
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
