Jul 3 2008

64bit Is Here And Significant, But

Posted by Mike Brunt at 12:29 PM
9 comments - Categories: ColdFusion | JRun-J2EE

I am currently in Manhattan and the weather here is brilliant.  Dan Wilson and myself took lunch today and we chatted about a good number of things; well in reality I was pontificating but that’s another story.  We eventually got talking about High Availability (HA) which is a pet subject of mine along with all things tuning-troubleshooting etc.  We were discussing the dramatic increase in the amount of memory we have available to us in 64 bit environments, as opposed to 32 bit.  Sean Corfield and I did some load testing of 32 bit and 64 bit environments with the same application and the 64 bit was significantly superior in terms of performance.  However, as we will typically want to allocate more memory to the JVM Heap this could create a challenge. 

Dan posed the question as to whether a dramatic increase in the size of the heap would not mean more work for the Garbage Collector in the JVM as there will be more objects to inspect.  I thought about this and in essence I believe he is right.  These are early days for 64 bit although I have already assisted one client with some judicious tuning of the JVM where they had allocated 6GB of Heap Memory. 

Is anyone out there using 64 bit and if so what sort of memory allocation arguments are you passing?

Comments

Sami Hoda

Sami Hoda wrote on 07/03/08 2:34 PM

This is an important question. Hoping to find out more myself.
Mike Brunt

Mike Brunt wrote on 07/03/08 4:07 PM

@Sami thanks for your comment. The other discussion point which is mildly related is the issue of using the Sun Java 5 or 6 JVM. I have been combing through blogs related to J2EE and JavaEE and all data I have seen points to the Sun Java 6 JVM as being much better performance wise.
Marc Esher

Marc Esher wrote on 07/03/08 4:10 PM

Mike,
I wonder how much it matters. After all, your load testing showed significant performance improvements, and that's the bottom line I'd think. In addition, if I remember correctly from your HA presentations, if the VM is spending lots of time in full GC as a result of too much stuff making it to "old", doesn't that point to potential applications problems and not so much just a "more memory = more gc problems" problem?

I'd think this would be pretty easy to demonstrate, though: just hook up seefusion or even have CF talk to jconsole and look at the time spent in GC. My suspicion is that even if it is measurably increased over the course of a full day, it probably isn't so much increased that it's degrading the app to the point that one would need to decrease memory, especially if all other signs indicate performance improvements.

I'm looking forward to hearing others' real experiences with this. Thanks to Dan for bringing it up and you for posting about it.

--marc
Mike Brunt

Mike Brunt wrote on 07/04/08 7:40 AM

@Marc, thanks for your comments and your question is valid and the points you raise are spot on. The Sun 5 and particularly 6 JVM's took aim at trying to roll out a "pre-tuned" JVM with the aim of needing less tuning, argument passing etc. I am not certain of this but I think from how long they have been out, that a lot of the formative work was done on 32 bit architecture. You are right that as Full GC's are a stop the world event too many lasting too long is not good and often that is code related. However it is not easy to directly control "references" to objects in heap memory from ColdFusion code. It is those references which largely affects the JVM Garbage Control mechanism. We are in the throes of setting up a 64bit Server in our LA Lab, once done we will be testing extensively and publishing results. As a side-note one important item that got corrected in Java 5 and 6, we no longer have 60 second explicit Full GC's caused by RMI.
marc esher

marc esher wrote on 07/07/08 10:24 AM

hey mike, i wanted to tell you that i didn't get any comment emails from your comment to this post... is your mail server working ok?
Mike Brunt

Mike Brunt wrote on 07/07/08 12:11 PM

@Marc, thanks for letting me know I did not get notification of your comment either I will dig into this.
Wil Genovese

Wil Genovese wrote on 07/15/08 8:00 AM

Mike, We've been running CF7.x ENT for the past few years under very demanding load. This month we are planning the migration to CF 8.0.1 64bit and at the end of July or start of August we will actually do the migration. We have 5 CF servers running behind a load balancer. Three of those are dedicated to serving our Mlsfinder application. (The other two are dedicated to Real Estate Brokerage website hosting.) We see an average of 2.25 million page views per day on just the three Mlsfinder CF servers.

We will have to spend some time tuning our JVM for a larger memory heap, but we may not even need that option. Our app runs at 500mb of memory used with peaks of 800-900mb. We may want to run a little more in the heap to cover peaks, but for the most part we're good. Some testing of our app on CF8 shows that we actually use less memory with CF8 than with CF7. Later this week we are going to setup a server that will mirror what our exact production server setup will be and continue testing code and also do some load testing.

As we learn more about 64 bit CF I will post back here and report any useful findings.

Wil
Kevin Penny

Kevin Penny wrote on 07/24/08 8:15 AM

@Wil Genovese -

I've posted the 64 bit question to the yahoo group http://tech.groups.yahoo.com/group/colderfusion/message/3459 - but am very interested to know how your migration to 64 bit land went -

Thank you
Wil Genovese

Wil Genovese wrote on 08/05/08 1:28 PM

First report:

As of noon July 30th we have one of five servers on CF 8.0.1 64bit. We put it back in the load pool and it is handling load with almost no issues.

We're running RH5x 64bit on dual dual core cpu's with 4gb ram. Our sysadmin installed everything from scratch since we were upgrading from RH 4.x 32bit CF7ENT.

We run our main service application from 3 of those servers. (The other two have other clients.) Our normal web stats (for the 3) show we had an average of 2,243,623 page views per day for the month of June. (BTW: since this is all MLS property searching all page views are CF requests as well). This server is handling 1/3 of that load. So far the over all system "load" (cpu,memory,running threads) have all decreased while the CF server traffic loads are about the same as always. It does appear that CF is processing threads faster than ever before and thus we have few simultaneous threads running.

Also, our sysadmin configure it so each instance running uses it's own jvm.config.

Our JVM memory arguments for our Mlsfinder service are as follows:
java.args=
-server
-Xms1536m
-Xmx1536m
-Dsun.io.useCanonCaches=false
-XX:MaxPermSize=256m
-XX:+UseParallelGC
-Xbatch
-Dsun.rmi.dgc.client.gcInterval=600000
-Dsun.rmi.dgc.server.gcInterval=600000

So far we have not had any issues with the GC at all.

I'll report back as we get more data and more servers migrated.

Wil Genovese
Sr. Web Application Developer
Wolfnet Technologies, LLC
http://www.mlsfinder.com
http://www.wolfnet.com

Write your comment



(it will not be displayed)







Categories

Monthly Archives

Search Archives

Favorite Links